Designation of Priority and Severity

Rule #16 of the Break Software Testing Methodology states: There may be absolutely NO ambiguity of any kind in the designation of Priority and Severity of items.

But what does this really mean? Let's take a closer look.
As software testers, we’re all familiar with Jira, right? We often encounter terms like Highest, High, Medium, Low, and Lowest. But here’s the problem: these terms are sometimes used for both Priority and Severity, which can be confusing.
​
When a bug is found, you’re typically required to fill in the fields for Priority and Severity before you can save the page. But who decides whether the severity is High, Medium, or Low? And who determines the priority level?
Usually, it’s based on the current insights of the person logging the bug. In other words, it’s often a personal judgment. Many times, people simply leave the default value, which tends to be Medium. That’s not very productive or wise, is it?
Now, let’s bring Agile Scrum into the conversation. What determines what we work on first? The things that provide the most value to the Product Owner, right? So, does filling in the Priority and Severity fields actually have any meaningful effect?

Without clear rules in your test policy about the chronological order of working on items, things can quickly get messy and chaotic.

---

Tip! Make sure that the same terms are not used for both Severity and Priority. For example, instead of using High, Medium, and Low for both, you could use High, Medium, and Low for Priority, while using terms like Critical, Major, and Minor for Severity.

Additionally, clarify who sets these values. Is it a person? A team? At what point are these values considered final?
And most importantly—actually use this in your process! Describe how it works and ensure the team follows it.
Afterall there is no "state when found set by Marc" vs "state after stand-up set by Team" or something similar. There's just a state of Priority and state of Severity. Right?

Otherwise, you might find yourself unable to continue testing because certain items were initially taken for granted but later turned out to block the entire process.

Here’s a simple scenario to test your decision-making:
There’s one day left in the Sprint, but a major bug remains unfixed and untested, requiring two full days of work. On top of that, a software tester reports a new bug with the highest severity but assigns it the lowest priority — a decision some team members find highly questionable.
How does your Scrum team handle this situation? Is this approach aligned with your testing process? Does your test policy provide any guidance on this?
The reality, however, is often far more complex than this simple scenario:
The newly raised bug has dependencies on the existing bug. Is fixing these bugs less important than completing the new functionality? If they all have the same priority and severity, it becomes even harder to determine the best course of action. But if we finish the new functionality first and fix the bugs afterward, who will test whether the new functionality still works after the bug fixes?
Do you see how complex it can get? Software testing can be mind-boggling at times.

Realistic testers know, in practice it's sometimes even waiting till the moment someone says:
Ohw I see something... there is a comment in the ticket... I guess the requirements just changed and we need to re-test... ...again. ;)