I hear a lot from testers who discover problems late in development, and who get grief for bringing them up.
On one level, the complaints are baseless, like holding an investigate journalist responsible for a corrupt government. On the other hand, there’s a way for testers to anticipate bad news and reduce the surprises. Try producing a product coverage outline and a risk list.
A product coverage outline is an artifact (a mind map, or list, or table) that identifies factors, dimensions, or elements of a product that might be relevant to testing it. Those factors might include the product’s structure, the functions it performs, the data it processes, the interfaces it provides, the platforms upon which it depends, the operations that people might perform with it, and the way the product is affected by time. (Look here for more detail.) Sketches or diagrams can help too.
As you learn more through deeper testing, add branches to the map, or create more detailed maps of particular areas. Highlight areas that have been tested so far. Use colour to indicate the testing effort that has been applied to each area—and where coverage is shallower.
A risk list is a list of bad things that might happen: Some person(s) will experience a problem with respect to something desirable that can be detected in some set of conditions because of a vulnerability in the system. Generate ideas on that, rank them, and list them.
At the beginning of the project or early as possible, post your coverage outline and risk list in places where people will see and read them. Update it daily. Invite questions and conversations. This can help you change “why didn’t you find that bug?” to “why didn’t we find that bug?”
Hi Michael,
I must fully agree with this.
Recently we’ve implemented sessions at our place of work called mind mapping session where testers would invite developers (even from other projects) as well as project managers and business analysts to view the mind maps we’ve created from the specification documents.
We then spend about an hour or so discussing the points raised and noting them down for future reference or notifying the developers of things to watch for when designing the system.
I also find that the mind mapping helps me think of links between different parts of the system and it helps me think of test cases which I can create. It doesn’t find everything but it certainly helps.
Not sure how it could work for bigger companies as I work in a relatively small company but if it is possible to implement I would highly recommend it for others as well.
Michael replies: Hi, Nathan. Thanks for the comment. See, readers: it can be done. 🙂
Inside every company, there are smaller groups. If developing a product is possible, then developing a shared understanding of it should be possible too. If someone suggests that developing a shared understanding is impossible, then they are literally suggesting that there’s no way for managers to know what the company is releasing—whereupon I would ask how people feel about that.
[…] outline’, inspired by the Heuristic Test Strategy Model of James Bach (Bach, 1996). The product coverage outline provides an overarching view of the product in which the functionality of the software is divided […]
[…] More reading: Product Coverage Outline by Michael Bolton […]