"Selecting the correct severity is a crucial indicator that your understanding of the testing environment and impact of the bug is high."
Motivation
Reporting functional bugs is not easy, and selecting their severity is even more challenging; however, in this article, you'll find 3 key questions to ask yourself while choosing the severity of a functional bug in context, which is an essential aspect of determining bugs.
These 3 fundamental questions are also exemplified to help you understand them and how to apply them in real testing scenarios.
What are functional bugs?
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. Whenever you perform an action, the website/app doesn't respond as expected. These flaws may or may not affect all end-users; if they do, they might not affect them equally.
On the other hand, depending on the state of the environment (production/live or staging/beta), the impact of a bug cannot be considered the same. Case in point: a bug found on a production website - a website that anyone can find 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 flaws mentioned above is more significant than others, or the way they impact users are relatively mild. Therefore, the urgency of fixing such bugs differs and, with this, the severity. This impact also varies depending on the environment we're testing.
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 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 bug's impact 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 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 required 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 somewhat 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 it provides decisive information on the issue to determine the correct severity of the bug.So, whenever you find a bug, you can find out 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 suppose you link this information to the importance of the product's functionality under testing or the feature within this product. In that case, the correct impact of the issue will become apparent to you.
As a rule of thumb, if you encounter a bug on a website that can be fixed by refreshing the page, then a functional bug's severity is 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.
If you keep 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 constantly creating content to help you understand the job on our Discord server Test IO Community or our Social Media channels, including a spreadsheet that shows scenarios with fixed severity.
You can consult this spreadsheet here, Bug Assessment Sheet! You can 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 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 see the 3 key questions in action!