2019 It's been a while since this blog was created. testenvansoftware.weebly.com/software-testen---blogs/how-to-cope-with-difficulties-in-testing Sometimes for things of quality it takes time, like a fine wine. I was driving in my car and suddenly it hit me, there's something utterly wrong with this metaphor. If you see it like this: the horse is the test environment and the goal is to shoot the moving bug... then everybody understands that shooting from something that is moving aiming at something that is moving as well is the hardest scenario. Right? Bug unclear/moving = 'What exactly triggered the dysfunctioning? was it button1, button2, or.... we need root-cause analysis. It seems to be flaky.' Environment unstable; example: someone is pushing/merging code while I'm in a test steps procedure of a test case. So what is so utterly wrong about the above methaphore? Well I realized that almost never the tester is a lonesome cowboy like lucky luke. Onwards to 2025: How to Cope with Difficulties in Testing: A Wild West Perspective
It’s been a while since this blog first galloped onto the scene--testenvansoftware.weebly.com—and like a fine wine (or a stubborn bug that only surfaces at 4:45 PM on a Friday), again, some things take time to mature. But recently, while driving, it hit me: the wine metaphor doesn’t quite fit testing. Let’s holster that analogy and ride into something more fitting: the cowboy way. The Wild West of Testing: Shooting Bugs from a Galloping HorsePicture this:
Communication: The Saloon Talk of TestingA tester doesn’t ride alone. There’s a whole posse involved: developers, PMs, other testers. And just like in a spaghetti Western, miscommunication can lead to unintended showdowns. Example:
The Takeaway: Embrace the RideTesting is less like sipping wine and more like staying atop that galloping horse:
Now, who’s got the drinks? We’ve got bugs to hunt.
0 Comments
![]() 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. ;) 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! |
Categories :
All
AuthorMotto: Archives
June 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 |