A few weeks ago, I posted a Very Short Blog Post on the bare-bones basics of testability. Today, I saw a very good post from Adam Knight talking about telling the testability story. Adam focused, as I did, on intrinsic testability—things in the product itself that it more testable. But testability isn’t just a product attribute. In Heuristics of Testability (material we developed in a session of Rapid Software Testing Intensive Online), James Bach shows that testability is a set of relationships between product (“intrinsic testability”); project (“project-related testability”); tester (“subjective testability”); what we want from the product (“value-related testability”); and how we know what we know and what we need to know (“epistemic testability”).
Be sure of this: anything that makes testing harder or slower gives bugs more time or more opportunities to hide. In telling an expert and compelling story of our testing, it’s essential to identify and address things that make it harder to understand the product we’ve got—things that help to increase the risk that it won’t be the product our clients want.
Want to know more? Learn about upcoming Rapid Software Testing classes here.
Michael,
Great succinct post with some excellent links. I personally like the revisions that have been made to the Testability Heuristics extending the scope of the testability conversation beyond that of just a product attribute and providing a useful framework for discussing testability. At the same time I do think that discretion will be needed when presenting the testability story to others in the business as to what elements to focus on. Focussing on intrinsic product behaviour does allow a directed conversation with management which could risk being diluted by the introduction of the other more relational elements. I would be inclined to split the message into separate, equally relevant, testing conversations.
Thanks,
Adam.
Michael replies: There’s an overall story to testing. From one moment to the next, we may choose emphasize one set of things over others, based on the audience, the nature of the project and the product, and their current state. The point here is that testability is multi-dimensional, and a network of relationships. How and when you talk about it is up to you.
Thanks for the comments. Cheers.