An agile tester’s work life is intriguing, busy and challenging. A typical day is filled with varied activities like design discussions, test planning, strategizing for upcoming sprints, collaborating with developers on current user stories, peer reviews for teammates, test execution, working with business analysts for requirement analysis and planning automation strategies.
Let’s sneak a peek into a day in the life of an agile tester.
Get TestRail FREE for 30 days!
A Typical Day of an Agile Tester
Venus is a passionate tester, and being a part of a Scrum team means her days are full of discussions, plans and re-plans, and lots of communication across the team.
Today is a typical day in her work life. After getting to work, the first thing she does is check her desk’s board, where she keeps note of the user stories for the sprint and their test schedules. Realizing that today is the day she has to begin testing a user story, she goes to the developer’s desk to ask about the build drop. He informs her that he has begun the build in Jenkins and the drop will be ready and shared soon.
Venus then goes back to her desk and begins looking at her tests for the user story. She had already designed the test scenarios for this feature last week and shared them within the team to gather their opinions and feedback. This is their mode of peer review for test scenarios. Venus had received a couple of suggestions on test cases, which she quickly adds to the test list. She then prepares her system for deploying the new build by uninstalling the old version and creating new folders for keeping her test execution results and screenshots.
Meanwhile, the product owner, Ted, approaches Venus to discuss a couple of issues she had raised yesterday pertaining to another user story. He talks about their criticality and implications, and Venus convinces him that they need to be fixed before the sprint ends. Ted also tells her that the drop being shared today has a number of bug fixes for the previous drop that will need to be retested.
Venus gets back to her build test plan to add this bug retesting. She goes to their defect management system, Jira, and filters out the defects with fix versions of the current sprint drop number, saves the filter and compiles an email to her two tester colleagues for performing these retests. They usually divide all retesting and regression tasks among the three of them, based on their dedicated areas.
By now her colleagues have also arrived at the office, and they have a quick discussion among themselves about their strategy and plan of action for the day, which is mostly to test the two new user stories as per their allotted tasks, retest the list of fixed issues and perform regression on some test areas from the master regression list — the list of regression areas that they have to cover at least once within the sprint. A colleague informs Venus that he will run one automated test script for regression and perform some tests manually to check out the impact areas.
Time for Testing
The build drop has now arrived, and test execution begins. With headphones on, her cup of coffee at hand and a “Do not disturb” sign on her chat window, Venus jumps headfirst into testing.
First she performs her own scripted tests she put on her list, checking through the basic flows, functionality and validations on the feature. Then she jumps into exploration mode and runs around the feature, looking at its interactions with previously existing functionalities and observing the behavior of the application overall with the use of the new feature. Venus jots down her observations and adds some of them as a part of her test cases. These tests are then uploaded into her test management portal, along with their results showing whether they passed or failed. By now she needs a break, and thankfully it is time for lunch.
Venus enjoys lunchtime chats with her friends from the team, and they happen to talk about a couple of upcoming features that may need some kind of performance tests. She makes a mental note to find out some open source performance test tool, explore it and talk to the test manager beforehand to strategize this new type of testing.
Venus managed to find a couple of defects during her tests, and after lunch she goes over to the developer to discuss them. After that she logs them in Jira with relevant details, screenshots and an application log. Her fellow tester, who is testing the second user story, seems to be stuck at some point, so Venus helps him out with testing the story and runs a few buddy tests for this feature to give her perspective.
She then remembers to talk to the IT person about her pending ticket raised for a new test environment virtual machine she will need in the next sprint. He is working on it, so she spends some time guiding him on all she would need to be set up in that environment.
It is now time for her scheduled meeting with Ted, the PO, about analyzing the upcoming user stories of the next sprint. Venus is joined by fellow developers and testers from the team. They sit and discuss the features, ask questions about them, and request more details or information wherever needed. This helps the PO be prepared with all the answers before the next sprint planning meeting, and it also helps the team know about upcoming features and how to estimate them better at the onset of the next sprint.
At the end of the meeting, they also discuss the backlog of unresolved defects, which seems to be piling up and needs to be checked. One developer volunteers to spend a couple of hours tomorrow fixing as many defects as he can, and Venus then volunteers to retest them, as she thinks her test execution is mostly done for her current user story.
Back from the meeting, Venus checks up with her tester colleague who has been running the regression and finds that the scripts have passed and there are no issues there. She hands him a list of test cases to automate for the current sprint’s user stories that have been working fine. They discuss and plan the automation strategy for these user stories and work awhile on creating the basic structure of test classes.
The Days at an End
It is time for their daily stand up scrum. The entire team gathers around the dedicated task board wall to discuss their work done for the day and move the sticky notes with their tasks along the task board columns. They also discuss their tasks planned for tomorrow and the possible risk areas, and the Scrum Master helps out those at risk. The team suggests ways they can collaborate and help others out, per their available bandwidth. After the meeting they also discuss ideas for good lunch places for their next team outing to celebrate their successes!
The day now at a close, Venus leaves the office cheerful, looking forward to a similar exciting day at work tomorrow.
Nishi is a consulting Testing and Agile trainer with hands-on experience in all stages of software testing life cycle since 2008. She works with Agile Testing Alliance(ATA) to conduct various courses, trainings and organising testing community events and meetups, and also has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.
Test Automation – Anywhere, Anytime
- TestRail Again a Leader in the G2 Grid for Software Testing
- Announcing TestRail 5.7 with Enterprise Features, new API Endpoints and Edit Result Permissions