7 minutes to read
Main types of defects which can be found during software testing
Chief Executive Officer
Share
When you go to war against your enemies
and see horses and chariots
and an army greater than yours,
do not be afraid of them
Deuteronomy 20:1
If you are able to understand and classify your enemy you almost win. This is true not only about war. Enemies are everywhere. If you are a doctor - your enemies are illnesses. If you are a fireman - it is a flame. If you are a tester your enemies are Bugs.
So in order to wreck the bug you should inform devs about it and they will "cure" the application. In such case we usually use another program which is called bug tracking system or BTS. But how devs should understand what you have written and what is the bug itself? There are several categories of classification of bugs which allow to improve bug reporting, bug fixing and bug verifying.
#1 and #2
First of all we will talk about Severity and Priority
Severity is mostly used during reporting bugs and it indicates importance of some testing.
Types for Severity and Priority are the same:
Blocker
Critical
Major
Minor
Trivial
*Obviously Blocker is the highest significative and Trivial is the lowest.
Examples
#Severity
Web application which has a lot of functions and configurations. A lot of TCs were written to test it. Some tests are important and some are not, because they cover almost impossible configurations.
If a bug, that you've found blocks a step even in so called "unimportant TC" it gets severity "Blocker". If some result that you received does not block you but makes another step fail (pay attention to ability to perform step but with inappropriate results according to bug in previous step) - severity is "Critical". Those bugs despite of their "Blocker"/"Critical" severity could receive priority "Trivial" or even may be considered as "Won't fix" bugs.
#Priority
The same web application with a lot of functional. During tests you've spotted some spelling error and instead of "Hello" application shows "Helol". From tester's point of view it is "Trivial" and you set severity as trivial. From product person's it might be critical or blocker because this "Helol" will be seen by all users and will be sent in all emails that application sends to customers. You did not know that because you had tested only one separate case and saw this bug.
In other words "Severity" is tightly related to tests and testers and reflects how bug affects certain checks. "Priority" is for devs and reflects how certain bug is important for whole project.
#3 Bug statuses
Another mandatory indicator of bug is "Status". There is "life cycle" of every reported bug.
Assigning statuses to the bug is the Game Of Roles. Usually only testers could verify the bug and assign status "Closed" to it and only Devs can resolve the bug. It is done in order to measure responsibility. If bug hasn't been resolved yet, then it is dev's problem.
If bug hasn't been resolved yet, then it is dev's problem.
If bug is resolved but not closed, then tester has to verify and close it.
Here you may see the easiest and most complicated "life cycles" of bugs:
Case1:
Open - Resolved (Fixed) - Closed
Case2:
Open - Resolved (Fixed) - Reopened - Resolved (Fixed) (two new bugs were reported in addition) - Reopened - Resolved (Won't Fix) - Reopened - Resolved (By Design) - Closed
Statuses are not so relevant for Case1 but for Case2 it is impossible to understand what was fixed and when and what changes should be "unfix" since it occurred that it was not a bug at all and even cause that new bugs appearing.
Statuses are closely related to resolutions. Here is List of statuses with possible resolutions:
#4 Categories as bug specification
Another mandatory specification is "Category".
Main categories and subcategories are:
UI bugs
Functionality bugs
Category is very important indicator and usually a dev team lead is responsible for setting it up. Since every dev did some part of application the bug needs to be resolved by the same person because it is very easy to ruin the code by incorrect fixing.
There are a lot of types that haven't been mentioned but those are standard. Remember that you are able to create your own specifications which will be orientated on your specific project. For example, have you heard about "Friday" bugs type? Obviously it means that they were reported on Friday. Since Saturday and Sunday are day-offs usually there is weekly publishing and this publishing caused that several bugs occurred because there were some errors in process. Those bugs will be reported in usual way but they will not require any fixing except republishing some components.
So investigate your project and provide quality assurance for your quality assurance team. And use every possible improvement that fits your project.
Share