Prototype theory in software testing

This is a topic I have been thinking about for quite a while. Every now and then I stumble about things related to software testing (e.g. in my last post) that remind me about something called prototype theory.

What is prototype theory then?

Prototype theory is a theory (who would have guessed?) about mental representation of meaning or categorization. Early approaches in linguistics took meaning as something that could be described by binary features. While it is helpful, this cannot deal with quite a lot of things. Let’s define a bird: has feathers, grows from an egg, can fly, makes sounds and so on. Biologists may not totally agree, but you get the point. According to this, admittedly rather crude, definition an ostrich would not be a bird (can’t fly), while some strange flying dinosaur with feathers would be. Therefore Ludwig Wittgenstein and especially Eleanore Rosch came up with different theory of knowledge representation.

Think of a bird. Depending on your location, you will probably have thought of a robin, sparrow, maybe an eagle. All of these are representatives of the category bird. And they all fit the crude definition given above. If I asked you now, if an ostrich or a penguin is bird, chances are high, that you would say yes, while they don’t fit the definition. And this is where prototypes come into play: “[…] Prototypes serve as reference points for the categorization of not-so-clear instances” (Taylor: Linguistic Categorization. OUP, 2009:45).

Or to visualize it:

Mancing, 2000: http://www.cervantesvirtual.com/obra-visor/cervantes-bulletin-of-the-cervantes-society-of-america–39/html/0279312e-82b2-11df-acc7-002185ce6064_20.html

What we are dealing with is a gradual categorization of meaning within an instance of representation. And there is no hard border, but fuzzy edges. Sticking to the bird-dinosaur example, the archaeopteryx (how much would that score when playing scrabble?) would be totally within the fuzzy edge of both instances, birds and dinosaurs.

So, how come prototypes are prototypes then? On a very rough level: it’s the principle of familiarity on the one hand and a mixture of frequency and relevance on the other hand. If something is more alike to other representatives, it will probably be more to the center. And if something is very seen/used/thought of very often it will probably at the center as well.

I will not dip into further detail here and certainly not take part in the discussions if prototypes need a real-world reference or not.

So how can this whole idea be useful in software testing?

Something I hadn’t thought of was the choice of hardware in mobile testing. But the idea comes in very handy in here. You can’t test on the bazillion of devices around, but have to limit that somehow. So it is advised to form categories along the lines of choosing your OS and hardware capability. According to this your category might be a high end android 4.2 phone. And it would be advisable to test on a phone (or set of phones) that is available in your area (no need of testing some Chinese phone not for sale in Europe), that is sold often and does not exhibit some strange features (remember that old Nokia phone with a dial plate representation?). So we are having relevance, frequency and familiarity here.

But what I was really thinking of was the categorization of test cases. Especially when you have to reduce the number of those to be really tested. You could define different categories of tests and sketch some circles and put every test case into the sketch taking familiarity, relevance and frequency into account. While relevance and frequency are usually part of risk analysis, familiarity is the odd one out. You could take familiarity as usability here and it would make perfect sense. Of course this approach works for smaller samples best and it is a nice way of visualization if you have to negotiate your numbers with a customer.

Something I want to give this a try in is session based testing. On the one hand you could give a sketch like this in your test charter to help testers focus and it might be an asset to debriefing as well, especially to new tester in the way of visualizing where they might have drifted away from the session topic.

To sum it up: I think it is always interesting to see how theories, ideas or approaches from other subject areas are resembled in others and might prove handy if you keep an open mind.

Taylor: Linguistic Categorization. OUP, 2009.