Now that we know who uses Taxonomies using this excellent paper: Bug Taxonomies: Use Them to Generate Better Tests [Vijayaraghavan, Kaner]. Let’s explore the properties of a good testing taxonomy. Many thanks to Marcel, who sublimed this great resource on his blog, That’s the buffet table.
Lough lists eighteen taxonomy properties:
Taxonomy must be used by the software testing community.
Aligned with the purpose. For example, a taxonomy for COVID contacts mobile application must be aligned with that application’s features
Based on the code, environment, or other technical details
Those are sources for test ideas.
Written in such language that newbies in the Taxonomy domain could understand it.
This is hard because of the infinitive number of inputs and outputs. Clearly state what taxonomy does not cover.
All Taxonomy actions must have a cause
In my opinion, this is redundant due to the completeness property
Internal versus external threats
Errors caused by application and application environment (hardware, software, other systems)
Taxonomy categories must not overlap
Taxonomy must not be biased and must be clearly observable.
Choices used to create Taxonomy categories must have simple yes/no answer.
Based on primitive choices, Taxonomy classification should be repeatable by another group
Similar errors classified similarly
Cluster similar errors in the same Taxonomy groups.
Should classify specific application domains, for example, Bluetooth protocol security
Terminology complying with established terminology
Well, in software testing, this is very hard. At least what you can do is to start with a paragraph that defines all used terminology.
Terms well defined
Still, some terms are well defined, so used those in your Taxonomy.
Taxonomy items and categories must mean exactly one thing.
Create a taxonomy that has practical usage.
Taxonomy has properties that define its quality.