A Typical Day of a Tester in an Agile Pod
What is an Agile Pod?
Agile Pod is a small, custom agile team with about four to eight members, responsible for a single task, path, or area of the product backlog. This organizational system gives complete ownership and freedom to the team and is a step forward towards completely responsible, self-disciplined, and self-sufficient teams. Agile Pods aim to realize the full potential of the brilliant agile teams we have and set the stage for the best quality output.
A Typical Day of a Tester in an Agile Pod
A tester’s life in an agile pod can be slightly different, not only as compared to traditional software development teams, but even compared to other agile methodologies. Agile testers are part of the core team of an agile pod and hence crucial in every aspect of software delivery.
An agile pod is responsible for the end-to-end delivery of the software features/user stories assigned to it. They create their own timelines, prioritize their tasks, clarify the requirements from the product teams, feed the pipeline for upcoming iterations, and everything in between!
A major difference comes in the interactions between developers and testers. They are to work as closely as possible and quality is an inherent expectation of their outcomes. There is no tracking of useless metrics like the number of bugs or the number of test cases per feature. All that is needed is quality, and they have to work together to build that into their software.
Example of an Agile Pod
Let us experience day to day activities of software tester, Ted, in this kind of environment.
Ted comes into work knowing that today is an important day. He is going to work with the developer on one of the major features of this release. The first task he jumps to in the morning is creating the rough draft of test scenarios he would like to cover for this feature. He then adds this list to their shared folder so that the developer can access, review, and use these test scenarios to validate his work.
Next, he checks the list of defects from his automated JIRA dashboard and finds out that there are a few defects fixed awaiting his attention. He downloads the list and creates a task for retesting these in today’s build. As his developer mate Jamie arrives in the office, they work together to look at last night’s automation test reports, and then trigger a new build in Jenkins. They then go grab a coffee while the build is running.
When they are back, Ted works with Jamie on his desk to Buddy test a new feature. He spends about twenty minutes trying it out and showing him the places it is failing or where bugs could be found. He also shares his thoughts on key integration areas with other features. Jamie takes this information back and continues his work on this feature, sharing that this will arrive to Ted for actual tests by the next day.
Ted now shifts his focus to the Jenkins build that is ready. He prepares his test environment, sets up a Do Not Disturb on his chat, and dives in! He begins testing the major feature using the test scenarios he listed in the morning but also exploring other areas of the feature. He makes this into an exploratory session, noting down observations and recording his steps. He lists the issues he is finding and logs them into JIRA now. He also shows them to Jamie and shares his thoughts. Now, he can finalize the test scenarios and merge them to their test database, and regression test pack. It is now time for a much-needed break, so he decides to go for lunch with his teammates.
Ted now has a list of defects to retest. He looks through the list and shares the load with his fellow tester. They divide the defects to retest amongst themselves and leverage the test environment already set up.
The product manager Luo drops by his desk to discuss an upcoming feature in their backlog. Ted makes a mental note to list the information he received from Luo in the JIRA User Story to share with the team. Ted also takes this moment to showcase his latest build to Luo to get his quick feedback and thoughts on how the features are shaping up and if they are aligned with their vision. Luo appreciates their work and is excited to see the full demo their pod will be putting up next week in front of all the stakeholders!
Ted now calls the daily stand-up. You see, he is also the Pod Leader for this release. Agile pods have leaders assigned from within the team who help in all external communications and organizing the team. They decide on a leader on a rotation basis and this release was his turn. The Pod members gather for their daily stand-up, and one member who is working remotely is added virtually. They discuss their progress, plans, and risks; share knowledge and insights, and offer help where needed.
After the meeting, Ted works on providing resources to whoever needs them and sends some emails. He then wraps up for the day cheerful and energized for the next day!
