Last year Dawie attend Janet Gregory’s course “Whole Team Approach to Testing” hosted by Growing Agile in October 2012. Here is his story.
How we fixed our testing backlog
The team at
FINWorks has been doing agile software development since 2005. We deliver hosted software solutions to our clients, mostly in the financial industry. Our development process grew out of extreme programming principles.
This story starts about 18 months ago.
Where we were
Our process looked something like this. The Product Owner would log and prioritise development items based on discussions with the client. Complex items would be planned and estimated in a team session. Simpler ones would be estimated by the developer before starting. One or two developers would work on a feature, writing production code and unit tests as needed.
Once an item was delivered by a developer, a tester would test it manually and create an automated test using a test recording tool. As the system grew it became apparent we had a problem. The developers were delivering functionality much faster than it could be tested. Some items would “ping-pong” between development and testing multiple times before they were accepted. The testing backlog kept growing.
The course
Looking for solutions, we came upon Growing Agile’s course with Janet Gregory: “The Whole Team Approach to Agile Testing” (based on Janet’s book
Agile Testing: A Practical Guide for Testers and Agile Teams with co-author Lisa Crispin). I attended the course in October 2012 in Johannesburg. Over the three days of the course Janet took us through most of what the book covers. With a lot of discussion and hands on exercises.
As you might imagine, the “whole team” idea is about closer collaboration among the different roles in the team. As opposed to taking a task through distinct phases – plan, then write code, then test. Involving everyone from the start provides early feedback and prevents rework. To quote Janet: “Testing is an activity, not a phase”
Everything we learned came together in the final group exercise. We assigned roles to team members – product owner, scrum master, developers, testers. Each team completed three iterations of planning, coding and testing a product.
What we did
Back at work I shared what I learned and we started applying it to our process.
The first change we made was to involve testers earlier. The testing perspective in planning sessions now helps us think through questions that might not have been asked in the past until after the coding was done. We now identify interesting test cases before coding starts.
We also introduced a step to the development process. Once a developer finishes an item, instead of “throwing it over the wall” for acceptance testing, the developer finds a tester and shows them the working unit tests. This conversation is another opportunity to confirm a common understanding of the problem and solution; and to make sure the necessary automated tests exist.
But we still had a huge testing backlog. We realized that it was next to impossible to work it off without losing productivity in other areas. So we reviewed the list of items, selected only the most important ones for testing; and ditched the rest.
Where we are now
It is now about 9 months later. Our testing backlog has never again grown to an unmanageable size. The number of items needing rework has reduced drastically. The whole team approach solved our testing backlog problem.
But this is not the end. There is always another area that needs improvement. And so our agile journey continues…
Dawie Strauss has been in software development for over 20 years. During that time he was everything from programmer to product manager. He’s been an agile proponent since he read “Extreme Programming Explained” in 1999. He cunningly finds a way to always make coding part of his job no matter what the job title.
