Test Community Spotlight: A Tester’s Survival Guide for Agile Transition
This post is our Test Community Spotlight Program, where we highlight personal experiences from testers and QA professionals around the world. To participate, apply here.
Agile transformation is challenging, especially for testers who are accustomed to working in a silo. As a lone tester on a team, it’s difficult to find the time to learn new methodologies and adapt to be able to incorporate them as part of your process. While it’s apparent that an agile approach can bring forth several benefits such as the faster delivery of new features, it’s not always obvious what a tester should do to be a part of this change.
Let me share my story as a tester for Agile Transition. When working in agile we don’t have to only learn about what agile is. How and where to apply is the most important aspect. Your mindset needs to change entirely.
How we started Agile!
We were a small team, working on a product where we were developing new features and fixing issues. We had releases once in 3 months. We followed the waterfall process where the stages were:
- Requirements gathering
One day one of our team members suggested we should start working in agile. It sounded interesting as it was the new buzzword but no one was ready for the sudden change.
We all decided we should do some reading about agile and try to understand so we can start working on it. I had no clue what agile was when I started, so read a series of articles and blogs about it. After all that reading and research, I did understand the concepts but they were all theoretical for me, meaning I still could not understand how the role of QA would change in Agile. We decided we should try implementing the process.
Our team decided to have a sprint every 2 weeks, which meant we would have features or bug fixes to the production once in every 2 weeks. We went from deploying once in 3 months to once in two weeks. It didn't sound very easy for me. I had all sorts of questions: How can I complete testing in just 2 weeks? When can I write test cases? When can I plan which type of testing should be run when? How can I make sure of the quality in this short time?
We started our first sprint planning session, where we discussed user stories/features and bug fixes to be included in that sprint. I had to estimate how long it would take for me to test so we can prioritize what we could include and what can be moved to backlog.
After the first few sprints, I figured out the three keys to making this work: Collaboration, Planning and Decision Making
We had daily scrums, which gave us transparency and the direction of the entire team. All team members were aware of what everyone else was working on, which gave the team a chance to discuss any related changes into the current sprint. This also meant that team members where more synchronized and remained focused on the goal for that particular sprint.
During these scrums I gained trust from developers and the rest of the team that I’m working with. They know what I’m doing, and I can inform the team if there were any issues that need urgent attention. It also allowed me to plan and prioritize my testing accordingly. Scrum increased collaboration on the entire team due to more visibility, transparency and working toward a common sprint goal.
Planning is the key to a successful sprint. I never conducted as much planning before our agile transition. After I worked on 3 to 4 sprints, I started to know when to plan for writing test cases, when to plan executing tests, and when to plan on doing exploratory testing.
I had to plan for different activities performed as a tester by me during the entire sprint cycle.
- Reviewing requirements
- Providing estimations for user story/features and bug fixes which are part of sprint
- Writing test cases
- Performing Functional testing
- Exploratory sessions
- Contingency time for retesting of raised Issues
- Regression Testing
- Smoke Testing in Production
While working in Waterfall, I never came across scenarios where you need to make quick decisions based on which stage of testing or situation you are in. I did face issues, but they were completely different.
I was scared when I had to face a situation where there was a show stopper issue towards the end of regression testing. It was almost end of day and UAT by stakeholders was planned for the next day. I informed my team members (front-end and back-end developers and BA), and we had a meeting about the issue. We made a decision to fix the issue as it was high severity, and I had to estimate my testing effort. After developers fixed the issue, I had to retest it. Situations like this showed that being agile is not only about making decisions at any stage of sprint, but also about maintaining transparency with team members. With agile, testers face different situations where they need to wear their thinking hats and make decision quickly.
There are also situations where you have to decide to drop issues which cannot be tested in the sprint. The more sprints I started to work on, the more confidence I had in planning and achieving the quality in given time. Completing each sprint gives me the feeling of crossing off a task from my list and the feeling of accomplishment.
The role of tester changes drastically in agile. You are not left to work in a silo. Instead, you are involved in every part of development, which makes you feel more valued.
These are my own personal experiences and situations faced during an agile transition, and how I have tried to solve them.
Thanks for reading my story. Happy Testing!
By Parveen Khan
Parveen Khan is a Senior Test Engineer at Progressive Content, who has worked on various number of websites and Apps and a Product. She is very passionate about testing and always tries to learn something new to improve her skills and spread knowledge in the form of stories. Apart from work, Parveen is a Super Mom of 2 lovely kids.