I have the luxury of actually reading and studying right now, and this morning’s reading of “Agile Adoption Patterns” included the practice of Self-Organizing Teams and Cross-Functional Teams. In both of these practices, Amr makes mention of the power of such teams to overcome obstacles because of the flexibility and diversity they have to go through or around the challenges they face. He also makes specific mention of all members of the team being willing to help with testing as needed so that the team is successful in achieving their goal.
This is a hot topic for me, so when I read these chapters I immediately knew I had more to say on the topic (I know, big surprise). My first contention is that once a team finds its rhythm in a reproducible process, almost every organization will them realize that it’s bottleneck is “testing”. I’m a little reluctant to use that phrase because a more accurate statement would be that the bottleneck is “product quality” with testing being one of the most visible manifestations of quality assurance.
My point of view on quality has been heavily influenced by studying quality assurance and statistical process control in the realm of manufacturing. While their are certainly importance areas where the analogy is flawed, there are many where the concepts are totally applicable. Let’s start with the concept advocated by Crosby in “Quality Is Free” – cost and effort spent improving the capability of your processes reduces the production rate for errors and pays off many-fold. He and others speak out against inspection as the least effective way of ensuring that a quality product is produced.
When a software organization decides to invest in “testing”, this usually takes the form of creating a quality assurance team. This is where they start because they are looking for some kind of verification that will give them the confidence they need that the product that they are about to ship is good. These teams may use automation, but usually their experience leads them to use manual testing. Their primary responsibility is to execute the regression tests, so this is usually where they majority of their time and energy goes.
When I encounter this structure, the first thing I usually do is to change the definition of what testing is. Passive involvement late in the development process as a final check before shipping to both frustrating to everyone involved and inefficient. You are forced to staff for the peak load created during regression. Testers that offer their opinions about how the product could be improved discover that the ship has already sailed – the team is up against a ship date and only the most egregious of problems get any attention. Their opinions go unrecognized and eventually they stop offering them. Or worse yet, a power struggle ensues as the testing organization pits themselves against the developers in an effort to influence quality.
North Shore - Two Harbors, MN
Instead, we pull the testers out of their department and into cross-functional teams. We break the cycle of laggard testing that prevents them from being involved in the concept and design phase for the next set of features. They test the features as they happen rather than late in the release cycle and a feature is not done until they say it is done.
In “The Goal”, Goldratt tells a great story about a scout troop on a hike that is given the goal of getting everyone to their final destination in the shortest time – success is only achieved when the last person arrives. At first the faster hikers move way ahead, but eventually they realize that unless they help the slowest hiker get there faster, their extra potential is wasted. They achieve this by tying the hikers together with a rope, and then over time they help offload work from the slowest hiker (the process bottleneck) until they are all moving together at the fastest possible speed.
All of these changes work great and this always revitalizes the test organization, but even when you shift from staffing for peak regression load to staffing for the average demand needed, you don’t really get the balance you are looking for unless you change what you regression test or how you test it. It also takes extra energy and resources to break the vicious cycle in which you are stuck. The testers by themselves may not have the vision or technical skills to fix these problems unassisted. Hiring more testers might help, but it also likely further embeds you in the current approach.
How do we fix this problem? As a team, and by this I mean a self-organized, cross-functional team that recognizes that unless you get this challenge mastered, your products will not have the quality or timeliness that you desire. Unless quality becomes the responsibility of all team members, you won’t break the code-test cycle that is at the root of the problem. Manual regression is the software equivalent of 100% manual inspection on an assembly line. In that world, they understand that investments in automated inspection and in earlier process measurement are the key. However, a product may need to be altered to be testable through automated means – this could be as dramatic as a change in architecture or development tools. Investment in developer tests can decrease reliance on manual inspection, but this means a change in working habits for the developers. And finally, developers may need to help create the framework of an automated test suite.
Hopefully by now my message is clear – quality is the responsbility of every team member, ESPECIALLY the developers. If the team has a quality issue or not enough test capacity, then not only is it appropriate for the developers to help, they should help. There is one thing I know – give a developer something they consider a mundane task and not only will they do it but they are very likely to apply their creativity to coming up with a way to avoid needing to do it again. Developers are the key to transforming how a team ensures quality – with sufficient investment in developer tests (to reduce the need for regression testing) and automation (to increase the efficiency of regression testing), you may even achieve the goal of 100% automation for regression testing.
So, if you are a developer in a feature team and you can see that your tester needs help, then roll up your sleeves and figure out how to either make the testing more efficient or reduce the need for testing in the first place. The reasons for doing to are entirely selfish – staffing is usually a zero sum game; once it is evident that the team needs more testers, they may only be able to afford this by having fewer developers. If you are not sure where to start because you really don’t understand how testing is done, then this is an even better reason to volunteer to help using the current methods. Instead, if you can change the technology and methods used to test, use your knowledge of the product and changes to influence what gets tested and when, and assume more responsibility for developer testing so that you create a more capable process, then in the longer run you get the best of both worlds.
