Due to a number of reasons, bugs can be found even in the most experienced developer’s code. These are errors or inaccuracies that result in a site’s work not meeting your expectations. That’s what makes quality assurance so important — a QA engineer is the guard of your expectations! However, not all bugs are equally harmful. Some bugs’ bites can be just little pricks, almost unnoticed in your website’s work. Other bugs are capable of biting off and munching a large piece of your business success. Let’s take a closer look at how bugs are differentiated by their importance in quality assurance practices, why they are not always obvious, and what is usually done about them.
Bugs in web development: from big to small ones
Usually, bugs are classified by two aspects: their severity and the priority of their fixing. Severity is the degree of their negative effect on the website’s work. Priority is the order in which bugs need to be fixed. Let’s take a closer look.
Bugs by severity
This may vary in different organizations or project, but the most widely accepted severity gradation is from “Critical” to “Minor.” Many also use an additional “Blocker” degree, which means the testing is impossible.
- Critical bugs (S1): The bug blocks critical functionality or even causes a website’s failure. There are no ways to bypass this bug.
- Major bugs (S2): The bug hampers less critical but important functionality, and there are some ways to bypass it.
- Minor bugs (S3): The bug affects minor functionality, and it is easy to bypass.
- Trivial bugs (S4): The bug does not touch any functionality, just presents some inconvenience.
Bugs by priority
The priority of bug fixes varies in this way:
- High. The bug needs to be fixed ASAP.
- Medium. The bug fix can wait for a short while.
- Low. The bug fix can wait longer.
Many QA engineers use one more priority level as well — “Immediate”.
Bug severity vs. bug priority
At first glance, it looks severity equals priority. However, they are not interchangeable.
The severity is determined by a QA engineer, and it is a more objective factor. However, web developers sometimes do not think so :) Bug severity has clear technical explanations. It is guided by development standards and/or obvious aspects of website behavior.
The priority is up to the product owner or project manager to decide. It is highly subjective and is often related to current circumstances, project budget, customer requirements and expectations.
Let’s consider an example: a web page has a typo. Objectively, it is a minor bug. However, the customer is giving a presentation on the basis of the website the next day. In this case, a minor bug needs to be fixed ASAP. This vividly illustrates the difference between severity and priority.
An opposite example could be a critical bug in the payment functionality. It is severe, but it does not appear in developer’s schedules, simply because the payment features of this website are not in production yet.
Should small bugs always be fixed?
There is also another aspect of working with small bugs. It may happen that fixing a small one breaks some important functionality. So the opinion of the small bugs divides QA engineers into, let’s say, perfectionists and rationalists.
The former insist on fixing the tiniest bugs in any circumstances. The latter decides it is better not touch them at certain moments. In the end, the customer has the final say on it.
In any case, it is a known fact in quality assurance that “fighting evil” is more effective when it is small. The sooner a bug is fixed, the less harm it can cause and the less it may cost to fix it.
To recap
The intricacies of bugs and their influence on the project are the lifetime focus of QA engineers. Experience and professional intuition helps them decide on the bug severity, as well as advise managers and customers on the bug priority.
Hire expert QA engineers at InternetDevels assurance testing services company, and they will help you make your website, as well as your reputation, crystal clear!