Tuesday, January 29, 2008

Product Maps (M. Bolton)

>1) How do you empirically or quanitatively measure "dept of coverage", doyou have an alogorithm or formula ?

I empirically and heuristically (but not quantitatively) assess (but notmeasure) depth of coverage, thus I have no algorithm or formula. Somepeople claim to have reliable algorithms or formulae, but I've never seenone that, on its own, stands up to critical scrutiny. Code coverage toolsare wonderful examples: someone can show me that they've exercised everyline of code in the product, but that doesn't really tell me anything usefulabout what they observed and evaluated.

2) Would you please provide me with a real example of what is being referredto as a "Map of the product" - and how do you build one? And how is "Mapcompleteness measured?"
To me, a map is anything that models some space such that it links ideas andreality. A map may exist only in the mind; it might not even hit paper orpixels, but a representation of it might in some form. For me, those formscan include diagrams, lists, mind maps, tables, narratives, checklists,flowcharts, matrices (all of which I have used effectively), cause andeffect diagrams (which I haven't)--you name it. These are all typicallysupplemented by description, often in the form of conversation. I'm usuallybiased towards maps and lists that are fast and frugal and that developretrospectively--that is, maps that I fill in through testing--rather thanmaps that attempt to be comprehensive from the get-go, since we can bepretty sure they won't be.

Examples abound:

Test coverage outlines and risk lists:http://www.satisfice.com/rst-appendices.pdf has several, in several forms.See pages 59-94, especially, for examples of this in list and tabularformats.Mind maps: Rob Sabourin's feature article in StickyMinds from November2006.

Test matrices: http://www.developsense.com/testing/TestMatrices.htmlAnnotated structural diagrams: Older versions of Rapid Software--and we mayrestore them in the future; plus an upcoming presentation at STAR East.

Checklists: Elisabeth Hendrickson's Test Heuristics Cheat Sheet; MichaelHunter's You Are Not Done Yet list.

Guideword heuristics:
a) James Bach's Heuristic Test Strategy Model(http://www.satisfice.com). Cem has a very interesting way of using this toanalyze a requirements document; use exactly one of the guidewords to tageach statement in a requirements document, then assess which areas areover-represented (and thereby, which ones are underrepresented).

b) the list of heuristics that NASA used for geological surveys for the Apollomissions, also in http://www.satisfice.com/rst-appendices.pdf.

---Michael B.

No comments: