Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Agile software development in practice - The testability perspective

When I was teaching a team new to agile about the importance of testability of each individual product backlog item, I discovered that focusing on testability not only increases software quality, but also helps improve multidisciplinary collaboration.

The team I was coaching had just started using Scrum and the people in the team were not used to working together with people outside of their own discipline. The team didn’t really feel as one team, but was more like a collection of people, each doing their individual tasks. The team was not delivering working software at the end of each iteration. The scrum board was always full of test tasks that were not progressing at all. The designers and developers were unable to understand why the testers took so long and the testers were unable to explain. 

During a Product Backlog refinement session of this team I introduced the INVEST principle. The INVEST principle was introduced in 2003 by Bill Wake ( It states that each Product Backlog item should be independent, negotiable, valuable, estimable, small and testable. These properties ensure that a Product Backlog item can be implemented within the timespan of one sprint and can lead to a potentially shippable product.

The team was looking at a big change that was coming up and needed to break the work down in user stories that were implementable in two weeks. Usually they would start to break it down per technical component that needed to be changed, but now with the INVEST principle in mind they started by asking: what is the smallest part of the change that can be delivered that is testable and delivers value? This led to the testers explaining how they would go about defining test scenarios. The team found out that even the smallest scenario they could define would affect multiple technical components. The developers in the team now understood that the testers could not start their tests before all components were changed. And the designers understood that a decision to change something in one component could affect multiple test scenarios.

In the next sprint the team decided to implement the scenarios one by one, each time making all necessary design decisions and updating all components affecting that scenario. To keep the focus on these scenarios the team used activity diagrams as a basis for each conversation about the product to be developed. This change in focus made it possible for the testers to start testing much earlier in sprint. Also, the rest of the team understood the test work better and could help the tester, for example by automating part of the tests.

The work atmosphere in this team changed from blaming each other for the lack of progress to helping each other reach their common goal. Besides that the team could now deliver working, tested software. The first step towards this was just looking at their work from a different perspective: testability.

About the author

Marieke Bode
Marieke Bode
I help my clients to create high value software by making them succeed in agile software development.

Leave a comment

Your email address will not be published. Required fields are marked *.