Agile software development in practice – The testability perspective

Publish date:

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 […]

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 (http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/). 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.

Related Posts

agile

For Scrum and Agile experts, starting a new assignment with the right questions is the answer

Rik Pennartz
Date icon September 10, 2020

How a measured, practical questionnaire can help you hit the ground running – every time

ADMnext

Your path to Agile at Scale: avoiding common pitfalls

Robert Wegener
Date icon August 5, 2020

How a focus on people, change management, credibility, and honesty can form your foundation...

agile

Agile and architecture – lessons from the trenches

Ben Kooistra
Date icon April 28, 2020

Scaling agile teams is a necessity to stay agile and keeping up business value. The agile...