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:

• The Horse = Your test environment (unpredictable, occasionally spooked by a rogue database or a misbehaving server).
• The Cowboys = Testers, balancing precariously while trying to take aim.
• The Eagle = That elusive, flapping-in-the-wind bug you’re trying to shoot.

Now, imagine trying to hit a moving target while riding something that’s also moving. That, my friends, is the essence of testing. The environment shifts, the code evolves, and yet--yeehaw!—you’re expected to land the perfect shot.
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:

• Dev says: “The concert is in the park tomorrow.”
• Tester hears: “Tomorrow, concert… or park? Wait, is the park closed? Is the concert canceled? Did we just pivot to a rodeo?”

Distilling clarity from chaos is a tester’s superpower. But it’s not just about parsing words—it’s about recognizing that every link in the chain (code, env, data, human whispers) introduces its own turbulence.
The Takeaway: Embrace the RideTesting is less like sipping wine and more like staying atop that galloping horse:

1. Expect the horse to buck (envs will break).
2. Aim ahead of the eagle (anticipate edge cases).
3. Yell loud at your posse (communicate relentlessly).

So saddle up, partner. The frontier of quality is vast, unpredictable, and occasionally ridiculous. But that’s what makes it fun.
Now, who’s got the drinks? We’ve got bugs to hunt.

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.

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!