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 but how and what to apply is the most important aspect too. 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 one release in 3 months of working. We followed the waterfall process where we had stages :

• Requirements gathering
• Design
• Development
• Testing

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 the concepts 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, and I still could not understand how the role of a tester would change in agile. We as a team decided we should try implementing the scrum process.

Our team decided to have a two week sprints, which meant that we would have features or bug fixes released to the production once in every 2 weeks. That meant we had to go from a once in 3 months release to a once in 2 weeks release. We went from deploying once in 3 months to once in two weeks. It didn’t sound very easy for me. It was a sprint attack!!!! I had all sorts of questions: When can I write test cases? When can I plan which type of testing should be run and 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 from the backlog. I was delighted to be part of the session as I could see which user story we would be picking and why and which bugs are being fixed and why. Not only that but I could also contribute and suggest which bugs/issues needs to be fixed based on severity and place it in 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

Collaboration

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

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

Decision Making

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 pretty 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 Product Owner), 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.

We also had Retrospectives at the end of each sprint. This was very interesting as this was the place where we as a team can give our inputs and feedback on what went very well and what could have been done better and also what went really worst. This helped us shape our process and sprint by giving considerations on each feedback.

Apart from all of these we had Wall of win. Towards the end of retrospective each team member could give the feedback on who’s contribution could go on wall of win and why. Following this during each sprint gave us motivation.

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!