Abstractions can put your testing in danger if you don’t handle them correctly. So some hints and tips on handling the abstraction known as an ’equivalence class’ may help.
I use the word ‘abstraction’ (wikipedia definition) a lot when I discuss Software Testing. ‘Abstraction’ underpins so much of my modelling approach.
I recently read Glanville Williams’ concise description of abstraction, as quoted in Hayakawa’s “Symbol, Status and Personality” [amazon.com][amazon.co.uk][books.google].
“Abstraction my be defined as the imaginative selection of some one characteristic of a complex situation so that it may be attended to in isolation.”
“..in short, the perception of similarity in spite of differences.”
Quoted from the ‘Law Quarterly Review’
When I read this, I thought of ’equivalence classes’, since I think of ’equivalence classes’ as ‘abstractions’ and this definition reminds me of my approach to equivalence classing.
When I model using equivalence classes I group ’things’ together based on a ‘perception of similarity’ in spite of differences.
Equivalence Class?
e.g. Instead of dealing with, a set of ‘ages’ from {0-140},
I could create a set of ‘male insurance rate calculation and application age’ equivalence classes of {young{0-12},teen{13-19},adult{20-35},mature{36-64},retired{65-140}}.
Warnings of danger
I particularly like Glanville Williams’ definition because the carefully chosen words help warn of the dangers of abstraction.
- …imaginative selection…
- …some one characteristic…
- …complex situation…
- …attended to in isolation…
- …perception of similarity…
- …in spite of differences…
I try to remain conscious of the differences. I don’t want to fool myself that I can always, under all situations, treat as equivalent, each of the ’things’ that I placed into these groupings. I need the awareness that I grouped them, for the situation which I currently “attend to”, and that I isolated them to aid my understanding.
I impose a grouping. I create an abstraction. I lose information (‘in spite of differences’) as a result of that abstraction because I want to work with a simpler model (‘complex situation’). When I forget this, I may fail to spot errors in the system.
Avoid this mistake:
I have in the past made the mistake of considering an equivalence class to ‘always’ retain equivalence throughout all functions of the system.
i.e. any value from the ‘young’ set can stand for any other value - no matter what functional area or process in the system I apply to it.
I have missed errors when I treated my abstractions as ‘real’ instead ‘imaginative’.
When I have had the error of my abstraction pointed out to me I have then made the mistake of trying to maintain a system wide equivalence class and partitioning the classes further e.g. teen{13-16}, driving age {17-19}. Rather than creating a new ‘contextualised’ equivalence class for the specific situation that I require the abstraction to help me with.
I have learned from these mistakes. But I will also remain mindful of Glanville Williams’ definition so that I do not repeat those mistakes again.
Hints and tips:
- I ’name’ my equivalence classes e.g. young, teen, adult etc.
- I also ‘contextualise’ them to avoid forgetting the ‘differences’
- I do this by ’naming’ the set, to associate it with the particular ‘complex situation’ which I consider the set contents will act as equivalent representatives under. e.g. ‘uk male insurance rate calculation and application age’.
Summary
I don’t really want to write a huge post explaining an elegant 5 line excerpt. So I will instead close by recommending that the next time you create an equivalence class; that you re-read Glanville Williams’ definition, and use it as a trigger for additional thought and reflection on your modelling process.
Related Reading
- Equivalence classes received some attention on various blogs late last year [Thinking Tester] [I.M.Testy (1)(2)(3)(4)].
- James Bach covers some similar ground in his blog post on model-based testing.
