![]() 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. ;)
0 Comments
Remember that previous blog? Specialist or Jack-of-all-trades? Given the current zeitgeist, I thought it was time for a fresh perspective. As a software tester, are you someone who believes in conspiracy theories, or are you more of a realist? Let’s weigh some pros and cons... If you say: "Someone who believes in conspiracy theories," that aligns with traits like looking beyond the obvious and thinking outside the box. How often are you searching for the root cause, the true source of a problem? In those moments, you need to think creatively — with cork, string, or whatever else comes to mind. If you say: "A tester must be an absolute realist," there’s merit to that too. After all, you’re often dealing with schedules, deadlines, and limited time. What’s the point of diving into areas that might not even be relevant? There are solid arguments for this approach as well. Personally, I think the conspiracy thinker — as long as they don’t go overboard — tends to have the upper hand. This mindset is more aligned with finding alternative paths and trying different approaches that might lead to discovering bugs. If you never think deeper — even if some ideas seem a bit “far-fetched” or “strange” — then perhaps this might not be the right profession for you. But what’s your opinion? I’m curious to hear your thoughts! Ik zou zeggen: zet de ondertiteling even handmatig op Engels, ik heb een .srt bestand geupload. |
Categories :
All
AuthorMotto: Archives
February 2025
This website uses marketing and tracking technologies. Opting out of this will opt you out of all cookies, except for those needed to run the website. Note that some products may not work as well without tracking cookies. Opt Out of Cookies |