At CAST 2011 Henrik Emilsson talked about how to create and craft our own models of software quality.

Henrik started his presentation on showing a German vendor who claimed to have a tool which is 100% quality. Taking on Jerry Weinberg’s description that quality is value to some person at some time that matters, what does this say? He raised the point that we need to come up with the criteria by which we measure the quality statements in order to communicate what we mean by quality.

Henrik said that they started the discussion in their company by challenging the Satisfice Heuristic Test Strategy Model. He told the story around the creation of The Test Eye. Rikard started to extend the Bach’s model on a piece of paper. Martin Jansson and Henrik joined later to that discussions. They ended up with a new model which helped them in their context.

Among the insights they got from that they learned that they should limit their model. From my experience it has been very worthwhile to focus the attention of a model as well. If you try to achieve everything, you might end up not achieving anything. Similarly, Rikard, Martin and Henrik ended up with limiting their model on a single page. When they felt they had discovered enough, they started to extend that model to a two page model.

The approach they took was to take the CRUSSPIC STMPL heuristics and exchange some of the different aspects. They exchanged Capability with Charisma for that purpose, but also Installability with IT-ability. That approached looked interesting to me, as they applied out-of-the-box thinking to their particular context. From my perspective that is exactly what context-driven testing is about. Challenge the models surrounding you, and coming up with more refined models.

They used their refined model, and started to extend this in two different ways. First they did some theoretical research looking for studies which could extend the model. But they also applied their model at a client, and refined the model based upon the empirical findings from applying it. Implementing something and reflecting over it, in order to improve what you are currently working on, is a pattern I found not only in applying a model like Henrik described it, but beyond that in methodologies like the Agile ones, or the stories which Gojko Adzic tells in his book Specification by Example.

On their journey they came up with an own mnemonic for charisma, and refined more and more letters of the original CRUSSPIC STMPL mnemonic. While doing that they found that they could continue on improving their model all the time. That way they became aware that a better is not necessarily more true than the previous version, but more useful applied in their context. In order to be more useful, you need to be generic but specific in wording it.

In the last year they felt that their model was good enough to have it released. They felt good enough to have it published, but asked James Bach to go through it before doing so. They learned from the experience that it was actually good that they decided to create their own model. Doing so they got rid of some of the legacy words that they hadn’t written and couldn’t rely to. Instead they came up with their own wordings which expressed better what they had in mind.

So far the result has been downloaded 100-600 times per month. They published it in November 2010, and even John Stevenson made Tom Gilb aware of it. Though he complained that there were no measurements involved, they found this to be an advantage of the model.

Henrik stated that they still continuously improve the model. He also applied it in the university in Sweden. They learned that having all these criteria in mind while testing, can and will make you a better tester. Also it is a good thing to not try to remember everything, but to know where to look it up. Like I once learned from a teacher, a professor doesn’t know everything, either, but he knows where to look it up.

You can find their quality characteristics on their blog here.

I personally found this a great experience report on how to create your own mnemonic for testing. They constantly strived for getting insights and refine their model based on that. In the past I have found great value taking one of the various mnemonics which you can find on the internet, and running a Testing Dojo on it in order to evaluate it as a tool. You can use for example Testing Dojos to refine the model, and get a first set of ideas on how to do that. The advantage in creating such a mnemonic on your own besides using on of the many around, is that you will resonate more to it.