My experiences as a QA in adopting AGILE

Here are my experiences as a test engineer in adopting the AGILE approach:

Initially when i was working in Waterfall model, our QA work for a feature completely depends on the functional specification written by developer. We used to consider that document as the main reference. Based on that, we used to write a detailed test plan and start testing the feature once the whole feature is available to us. Then write automation tests before the regression cycle begins for a release.

When our company, switched to AGILE model, the first question that raised in my mind is "How can QA engage effectively during a sprint before anything has been built?". Scrum is an Agile approach to software development, which focuses on delivering valuable business features in short development iterations of 2 to 4 weeks (In our case, it 3 weeks).  After working a few years as a QA in a Scrum team, I have learned that the role of QA in Scrum is much more than just writing test cases and reporting bugs to the team.

In initial days of scrum, I used to think daily stand-ups are nothing but wasting time and seriously, i used to see AGILE approach as A-JAIL. The concentration in scrum is on what to tell instead of the work being done. Also, the information being shared in scrum is well known by everyone. We know who is working on which feature, but why do we need a separate 15 min meet to just know a statement saying “working on so and so”. Yes, its more than the status. Team shares the detailed status where QA can know the details of the feature and the impediments being raised and what is stopping developers from continuing the work.

Here are few things i learned.

• In Waterfall model, QA involves at the end of development. But, in AGILE, QA will be involved right from the very beginning of a project. 
• Working together - Scrum team is a cross-functional team where development, QA, platforms and documentation teams work together as a team. 
• QA, the first and ever customer - I always used to think that QA is the first customer of the product and QA knows well about the product more-than development team who typically focuses on the “happy path” of the feature. Since, QA excels at identifying and capturing complex and negative test case scenarios. Including testers during Release and Iteration Planning, when user stories are estimated, QA can help the team think beyond the happy path. 
• Helping Product Owner - QA role provides feedback from their testing experience to the Product Owner and work closely with the Product Owner to help them develop detailed acceptance criteria for their user stories. QA can also help the Product Owner modify or enhance existing user stories to better reflect the true requirements. 
• Fast feedback – Developers can consult the QA about acceptance criteria or the expected behavior of any functionality from the user's perspective while working on the feature, which results in saved testing and bug fixing cycles.  
• Automation, QA’s best friend - In scrum (3 weeks), QA generally have less time to test the application. Also they are responsible for testing the feature implemented in current sprint as well as regression testing the feature implemented in last sprint. In such short cycles, automation is the best friend for QA (as alwaysJ). It helps to reduce the pressure QA feels. 
• Participation in Release readiness - With short sprint cycles, developers have less time to explore the complete functionality of their user stories on their own. As a result, developers typically consult with QA to better understand the user stories since they are the ones aware of the complete functionality and know each and every requirement and acceptance criteria. As a result, it is a good practice for QA to perform the demo at the Sprint Review meeting. 
• Preparing test strategies - Scrum believes in preparing only enough documentation to support the immediate needs of the team. As such, QA will prepare just enough high-level documentation for test strategies and plans to guide the team. 
• Sometimes it may not be possible to perform testing of non-functional aspects, such as system performance, within a sprint. This can taken once after the development sprints complete.

 

While QA still write tests and report bugs, they also support many other roles and responsibilities on the team. They are an important part of the team. 

Having worked as QA in AGILE team, i have learned many things, it has added many wonderful skills to my toolbox and has helped me learn how to play many different roles.