Let’s start with something we can all agree on – a defect is something not working as it should. Now, we like to think of defect-based testing as having radar for a certain kind of bug (or a specific flaw). Instead of using the standard requirements docs or the use cases, we use the defects to base test cases. This whole process is based on taxonomies.
What are taxonomies?
Nothing too complicated. They are hierarchical lists with root causes, failure signs, and other defect-related elements. Some find it easier to think of them as classifications.
They tend to vary in level of detail: from broad to specific (from incomplete or missing parameters to missing descriptions). Even though you might not know it, even your day-to-day software testing is influenced by some industry standard taxonomy. One of the most popular ones is Dr. Boris Bazier’s (if you’re curious consider this book.
Why use them?
They make our (software testing) lives easier. Having a defect taxonomy allows us to both classify failures and determine the type of bugs we should test for. We can focus on a specific element and constantly test for it. Also, taxonomies can be linked with risk scenarios that need to be addressed while testing.
Taxonomies present an advantage when it comes to teamwork. Less experienced testers can be given test cases based on them – this will give them less room for error.
Simply put, a tester with taxonomy at his disposal has higher chances of success.
Other aspects
We might think that the better/ larger the taxonomy the more effective the testing will be. Yet, as we mentioned in other articles (https://blog.euro-testing.ro/testing-errors/), we should always keep our eyes open for items that are not in the taxonomy. Watch out for invalid characters, “correct” error messages or check how the software handles error corrections (do I have to start the registration process from zero if I i entered something wrong at a certain point?). Experienced testers usually develop a “nose” for where things in software could break.
No taxonomy has a one-fits-all property – it’s likely to require some modifications to fit the product your testing for. Consider the defects you want to target and their level of detail. If you had a similar software testing project you can get additional inspiration from it. Usually, a decision has to be made between the level of detail and the redundancies in the list.
Defect taxonomies should be frequently updated. If they are used in similar circumstances, an additional benefit to having a taxonomy is that later on, test cases can be built on them.
Final considerations
Remember that for innovative software there may be few if any industry standard taxonomies available. Will you tweak an existing one or start from scratch? How many items should the taxonomy contain? Should there be 5 test cases for one item or 50? Always keep your eyes (and your instinct) open when it comes to adequate coverage. If you want to hear more about our approach on these matters let’s get in touch.
