In most projects, testers are the keepers of quality. Sharing the vision of quality with the entire team helps everyone involved in a project play a more active role in determining the state of quality in a product. In this column, Jeff Patton shares several innovative ideas he's seen in practice lately that have helped an entire team own up to the quality of its software.
Testers in software development generally have it rough. Testing software is often the last major effort completed before shipping software. Since the terms "software" and "late" have almost become synonymous, it's the testers who often draw the scrutiny of the entire company as they work to test the software at the eleventh hour. It's the testers who get the pressure to work faster and then to declare the software "releasable" often before they've had enough time really to be confident that it is. Then, to add insult to injury, if issues are found with the software after it ships, everyone looks back to the testers and asks, "Why didn't you find those bugs?" It wasn't the testers who created the bugs, but, unfortunately, they have to saddle some of the blame for the released bugs.
I've been working in agile development for many years now, and, to some degree, testers there have it even rougher. Agile development divides the construction of software into short development cycles—one to four weeks is common. At the end of each cycle, the software built in this cycle should be tested and be at a quality high enough to ship, although it usually doesn't ship. This means that a tester in an agile context may feel the end-of-project pressure not every few months but every few weeks. It's out of that agile pressure cooker that I've recently seen some interesting and innovative practices emerge.
The first realization the enlightened team needs to understand is that the whole team is responsible for the quality of the software. Secondly, for the whole team to begin to take responsibility for the quality, they need to understand quality. It's often the testers who have the best idea of what quality is for the product and who are in a good position to keep the team informed about quality.
Will, the senior tester on an agile team I'm currently working with, has taken to heart the responsibility of keeping quality visible and has come up with some innovative and useful ways to do so. Will arrived at these strategies partly on his own and as a result of working with James Bach when he visited the company recently. (Learn more about James Bach and his teachings.) Using the strategies Will has arrived at, we might end up with something like the figure below. Will's actual work is considerably higher quality.
Report Test Depth and Subjective Quality
Will knows that it's not as simple as saying the quality is high or low. For example, if his team only had time to do a shallow first pass at testing a particular product area and found no bugs, was the quality high or low? Of course it's impossible to say. What Will and his team have chosen to report is both pieces of information: the "depth" of testing they've been able to complete and their subjective quality assessment.
To report depth of testing, try using a number between one and five—one meaning a shallow first pass and five meaning thorough testing of all aspects of the software including boundaries and extreme failure conditions. If you're testing in a team, ask each of your team members to think of a number between one and five to represent how deeply he feels the software has been tested. Then, when everyone has a number, ask everyone to show the number at the same time by raising that number of fingers on a hand. This feels a bit like playing rock-paper-scissors, but no one loses.