Home
Blog /
Main types of defects which can be found during software testing

7 minutes to read

Main types of defects which can be found during software testing

May 25, 2017

Oleg Sadikov

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:

Open (Unresolved) - When bug was just reported it's status is Open (Unresolved)

Resolved (Can not Reproduce) - When dev can not reproduce the bug

Resolved (Configuration Error) - When dev found configuration error due to which bug had occurred

Resolved (By Design) - When bug is not actually a bug

Resolved (Won't Fix) - When bug is the bug but it was decided to left it as it is without fixing

Resolved (Incomplete) - When bug will be resolved in future sprints and currently it was decided not to touch it.

Resolved (Obsolete) - When bug is not actual any more because such functional was removed

Resolved (Fixed) - When bug was fixed

In Development (Unresolved) - When dev currently working on the fixing it

Reopened (Unresolved) - When it occurred that bug is still actual after fixing or when tester is not agree with the resolutions as By Design.

Closed(Fixed/Won'tFix/ByDesign/Obsolete/Incomplete/Unresolved/Fixed) - When working on the bug was completed

#4 Categories as bug specification

Another mandatory specification is "Category".

Main categories and subcategories are:

UI bugs

Syntactic bugs - Bugs which are related to some syntactic errors. E.g. incorrect text in some error message which was shown to user

Error handling bugs - If we show some unclear error message. It is not OK when instead of "You entered incorrect name" we show "Failed to load resource: net::ERR_BLOCKED_BY_CLIENT" and in such case bug that should be reported is Error handling bug.

Visual bugs - When design of some table or button is incorrect or we show text in incorrect colour etc.

Functionality bugs

Missing command bugs - When some intended functional does not work at all. E.g. clicking on button does not cause anything.

Calculation bugs - When calculations of some variable are incorrect due to incorrect formulas, data type mismatch etc. For example our application is p.g. 18 and on starting screen we show calendar where user should enter his birth date. Our formula was incorrect and validation rule was to compare date that was entered with current date. It caused that no matter what user enters we allow him to proceed.

Control flow bugs - If certain action should be done in specific conditions but it is not. For example when user tries to add new records to his contacts and there is button Save+Create Another. When he clicks on this button previous contact is saved but empty pop-up for new contact does not appear.

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.