"Selecting the correct severity is a very important indicator that your understanding of the testing environment and impact of the bug is at a high level."
Table of contents
Reporting functional bugs is not an easy task and selecting their severity is even harder, however, in this article you'll find 3 key questions to ask yourself while selecting the severity of a functional bug in context, which is an important aspect of determining bugs.
These 3 key questions are also exemplified to help you understand them and how to apply them in real testing scenarios.
What functional bugs are?
Let’s think of functional bugs as flaws that affect the usage of an element or anything that makes it possible to interact with the website or app you are testing.
Functional bugs are related to the functionality of a piece of software. Examples: A button doesn’t submit the form; the search doesn’t react to the user input and the app crashes after interacting with an element on it. Every time you perform an action, and the website/app doesn’t respond as it was expected, it might be a functional issue. These flaws may or may not affect all end users and if they do, they might not affect them all equally.
On the other hand, depending on the state of the environment (production/live or stating/beta), the impact of a bug cannot be considered the same. Case in point: a bug found on a production website - a website that can be found by anyone on the Internet - will have a more negative impact on users and customers than bugs found on a staging environment that is not accessible to real users.
What the severity of a bug means?
Sometimes the negative impact of the aforementioned flaws is more significant than others or the way they impact users are rather mild. Therefore, the urgency of fixing such bugs differs and with this, the severity. Plus, this impact also varies depending on the environment that we’re testing.
This is the reason why we have three severity levels for functional bugs: Low, High and Critical. You can find the extensive explanation in our article, Functional Bugs | Test IO Academy
For exploratory testing, we can think of 3 key elements to differentiate these three severities and develop a more assertive classification.
Before selecting a severity ask yourself these 3 key questions
Bugs are contextual and for this reason, 3 questions (which we share below) on how to determine the correct severity of a bug need to be understood and answered in the context of the product that is being tested. Answer them before clicking on the “Submit” button.
What is the purpose of the functionality on the website or app under testing?
To illustrate, if you’re testing an e-commerce website finding items/products, putting them into the cart and initiating the checkout process are core processes on this particular website while if, on the contrary, you’re testing an entertainment app, the core functionalities are playing, watching and being able to interact with video player controls.
What is the impact of the bug on the end user and/or the company business?
If the test has only one or very few functionalities in scope, ask yourself, what functionality you are testing before anything else so you can visualize its role on the website or app.
Let’s say the feature in scope is the Sign-Up process. Is the flow of this functionality the same for an e-commerce website as for an entertainment app? The most likely answer is not.
Depending on the product, sometimes the information that is needed to enter is crucial to deliver specific content to users. For instance, while registering on an e-commerce website the most important question users need to provide might be just their age (e.g., older than 18) whether for an entertainment app other information is needed like confirming if the user is a parent or a child so adult content is not delivered to minors.
Are there any workarounds to use the compromised functionality? If the answer is yes, is it intuitive, straightforward or rather difficult to find or perform?
In other words, if there is any other way users can find how to use a functionality that is bugged or working in a way that is not expected, this is called a workaround. The workaround should be identified for the compromised functionality since provides decisive information on the issue to determine the correct severity of the bug.
Thus, whenever you find a bug try to find the different paths users need to take to accomplish the task the bugged functionality is not allowing. Understanding the amount of work and time spent on it is crucial to select the correct severity of the issue. And if you link this information to the importance of the functionality of the product under testing or the feature within this product, the correct impact of the issue will become clear to you.
As a rule of thumb, if you encounter a bug on a website that can be fixed by refreshing the page then the severity of a functional bug would most likely be low because refreshing the page is an intuitive and easy workaround. In other words, most end users would try to do the same, and fixing the issue is only one click away.
To do this properly, it’s fundamental to have understood the product (website/app) and its design so you can easily take educated guesses on the behaviour about to report.
Keeping asking these questions while testing will guide you through the right path of selecting the correct severity of the bugs.
Where to find some guidance on understanding severities better?
We’re always creating content to help you understand the job at hand on our Discord server Test IO Community or our Social Media channels, including a spreadsheet that shows scenarios that have fixed severity.
You can consult this spreadsheet here, Bug Assessment Sheet! Try to find the issues on this file on any test you join, in this way you'll understand their severity better.
On the other hand, we also use our Facebook and YouTube to help you out with testing like the episode ❝How to Select the Correct Severity of a Functional Bug❞ and find out some considerations Team Leaders need to take to address the severity of functional bugs. There are examples and you can follow the thinking process behind them and, better, you can see the 3 key questions presented in action!