In his last post Ewald wrote about evaluations, about starting late in the project and wasting your time and money as a test expert. He also asked of you are able to make the right business case and explain why starting early with testing activities will be beneficial. This post will give and answer at his final question or statement in the post: maybe Agile can help?

There are for sure very good principles that make Agile as it is and will help you in lowering the cost and raise the quality as a team of the product. Let’s discuss 5 reasons for Agile Testing.

#1. In control by delivering the software sprint by sprint
Are you familiar with the feeling that you have to jump on the train that is already going? That you are involved to late? That the amount of work of a project is too big for you, not knowing where to start? Since the software will be created sprint by sprint the amount of work is small, you can oversee the amount of work. More important you can address the right testing techniques for each of the features realized in a sprint. And yes there are the aspects of (automated) regression testing with the tool and coverage related issues, there are issues of working with stubs because interfaces are not finished. But each sprint is small project at it own so it is possible to come in control.

#2. In control by lowering the risk profile sprint by sprint
The image below is showing how the risk of failure will be lowered each sprint. Where in traditional waterfall the software will be deployed in production once per year or two times per year in Agile in can be deployed each 4 weeks when it is shippable. Not every organization will put it in production each 4 weeks. Since Agile is focussed on creating high risk user stories at the beginning the risk profile will lower during the release with several sprints. For sure interface testing, integration testing are mitigations in waterfall projects to reduce the risk. They still exist as long as the software is not in production. By moving to production sprint by sprint the risk profile will be lower.

#3. Regular feedback from the business at the product delivered
Late involvement from you as a test expert is not useful but late feedback from the business will cost a lot more. Where other businesses very often work with prototyping, models and end user involvement is the involvement of the business in waterfall projects not a common approach (I know it is possible, addressing waterfall approach in the right way will involve the business, but we all know in large organizations that is not the case).

For each definition of done, and definition of shippable the business is involved, that will give us feedback. If needed these things are processed in the Product Backlog.

Besides the feedback after delivering a piece of software is the business also involved at the beginning. They define via the Product Owner all the different features and user stories at the Product Backlog and in more detail at the Sprint Backlog. Because of the short cycles (average 3-4 weeks) the feedback can be given very often to the team.

#4. Regular feedback from the team and improvements each 4 weeks
If you really want to improve testing, that is what Ewald states in his blog, you should have a mechanism of continues learning. Agile is offering an excellent instrument for this. This is the retrospective at the end of each sprint. Working in a team and working as a close team creates the environment to give each other feedback.

A retrospective has two different goals: See what you did well and see what you didn’t really do well. The first group of lessons you should continue, the second group are the real improvements, the points that need attention from you as a team. It is always a team effort!

#5. Grip at testing by a staged risk analysis
The four different reasons for doing Agile as described before are related to the quality of the software not directly related to real test execution. But for the right test execution you should have the right test strategy. How do you determine what tests you should execute? How to find out what the high risk objects are in the application. In waterfall project the Product Risk Analysis is and instrument used by test managers. In my experience this is an instrument that can work but because we do not really know how the product will look like we are not able identify all different risks at the beginning. That is where Agile can help with is sprint by sprint approach. The risk analysis should consist of at least two different stages.

The first one is at the features that are described at the Product Backlog, these are often on a high level but can be classified on a high medium or low risk profile. High risk features will have more impact and from a testing perspective probably have more story points during the sprint. This can be part of the Definition of Ready. Until the items at the Product Backlog do not have a risk classification we are not ready to start a sprint.

The second one is at the user stories that are described at the Sprint Backlog. These have detail enough for building and testing the software. They have enough detail to derive test case and also to determine the test effort and approach that is needed. In and before the Poker Session together with the team all different risks can be identified. Great discussion will happen in the team by determining the story points. Because a user story can cost just a couple of story points from a developer. But if it is related to interfacing it will cost a lot more effort to test this.

However, there is much more to say about risk analysis and classification in Agile projects. This is a topic for the beginning of next year.

Conclusions
There are at least five different reasons to start Agile project from a testing perspective. If addressed in the right way it will lower the cost for testing and higher the added value of software testing.

Finally, last but not least: we wish you all the best for 2012.
Happy reading,
Andreas Prins.

1. Manish Ganesh Shivhare Says:
   January 11th, 2012 at 14:37

   Dear Andreas,

   You have covered the topic very well. Agile testing methodology is getting lot of traction from the industry these days. Enterprises are now moving from adhoc or waterfall testing model to agile model. Agile testing does not emphasize testing procedures and focuses on ongoing testing against newly developed code until quality software from an end customer’s perspective results. The reasons you have mentioned in your article are good enough to switch to agile testing.

   Regards,
   Manish

2. Andreas Says:
   January 23rd, 2012 at 13:34

   Manish,

   Thanks for your comment. However these reasons are valid, there are a lot of companies that think that Agile will solve all their problems. The fun is starting with Agile in these organisations shows a lot of impediments. Improving these will help organisations go forward!

3. Trackbacks Says:
   February 23rd, 2012 at 10:58
   • Agile is not the answer :: Software Testing and more