Agile and Scrum Methodologies from a Testing/QA Perspective

Member Submitted
  1. and reports back"...QA folks are involved in the project from the start–along with their development counterparts–and they have access to the same information about product requirements and customer needs at the same time. This participation from the onset, combined with the fact that development and QA are part now of the same agile team, that they get together on a daily basis, and that they have full visibility into the tasks that each other is performing towards the overall success of the sprint, means better and more frequent communication among themselves. In addition, because the entire team meets everyday (development, QA, product management, etc) there are more opportunities for collaboration and more view points towards performing a particular task. Also the traditional "rivalry" that you may find among QA and development is eliminated because there is a single agile team now working to achieve a common goal.
  2. A new "peer to peer" relationship between development and QA personnel You should be prepared to "speak up" much more. Agile methodologies are all about building self-organized teams, and the voice of a QA engineer/tester carries the same weight than a developer. Think about it. In the daily scrum meeting each team member gets asked about their accomplishments (testing, developing, writing product documentation, etc), future plans, and obstacles, treating all of the members as equal partners. On an agile team the question of "how are we going to test it", is as important as "how are going to build it". In addition, because testers tend to be exceptionally good at clarifying requirements and identifying alternative scenarios, (especially when they have full visibility into product requirements and customer needs), they provide valuable input on design and architectural decisions throughout the project, right from the beginning. And these contributions translate into more respect and appreciation from their development counterparts.
  3. Looking for ways to optimize testing efforts will be a "must" You really need to think about automation, and planning and performing your testing efforts very efficiently. With shorter development cycles of typically no more than 6 weeks, and with builds being released all the time, testing efforts really need to be optimized as much as possible, because there is not separate test phase as such. One of the ways to achieve this is by leveraging both Exploratory Testing and Automated Testing throughout the project. Exploratory testing will come very handy when looking for bugs, opportunities to improve, and missing features. So you should plan on "exploring" the product at the beginning of each new sprint, or any time that there is a change done to a product feature within the sprint cycle. Similarly, you will need to plan and build your scripts to perform automated functional and regression testing within the sprint, because there is not enough time for performing thorough manual testing. One of the things to remember is that there are no really lengthy requirement document or specifications–other that the stories encapsulated on the backlog files–so the only way to make sure that each feature is fully developed, tested, and accepted by the product owner before counting it as "DONE!", is by using the sprint backlog as your own test plan (or writing a test case or script for every feature). Some teams are treating test case scenarios as entries that need to be added to the product/sprint backlog files for planning and tracking purposes. Another factor to consider is that development is much more heavily engaged in testing, so you should leverage this, and work very closely with them to plan and build more automated scripts that cover realistic scopes.

Summing up:

User Comments

Payilagam Chennai's picture

I have a question on Agile.  In the Planning meeting, if the Product Owner is absent all of a sudden, do we need to conduct the planning meeting without Product Owner or should wait for him.  Please answer

April 15, 2015 - 3:54am
sridhar bandha's picture

It depends actually. If your product owner has already prioritized all stories then all rest of team has to do is decide what all stories they can complete in that sprint. But then Product owner has to informed about the scope of the sprint (in terms of stories) and he should be fine with that. So my take if you have your stories prioritized then go ahead and decide based on priority and then later have a chat with Product owner get his feedback before actually starting the sprint.

May 4, 2015 - 9:48am
Sanat Sharma's picture

A real time scenario which I am facing now a days in Agile - Product owners are not interested in the product and wants to kill the products. But on the other side, there is a full fleshed Product backlog items list that can be implemented in the product.

There is a deadlock on this and Engineering team have spent 3 weeks (doing nothing) without even finalizing the release requirements to be implemented in the further release.

October 6, 2015 - 6:45am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.