Skip to main content


I came across this post recently here: I guess its a little like i have been feeling recently! Have a read...

Software testing can be stressful.

Causes can vary from deadlines, lack of communication, or internal pressure. It is also the relentless nature of the job. As much as we love our job, here are some of the struggles that only a tester will understand.

1. We are Undervalued

“Our developers can check their own code.”

Some companies use this reason to justify why they don’t need testers. This is especially common when the company doesn’t have a large budget.

You’ll always need testers. Cutting software testing expenses is not the way to go. Having a dedicated testing team will save you a lot more time and resources in the long run. If you release a buggy product, you’ll lose a huge amount of users. You’ll lose your developers’ time to fix the product, which increases your costs.

Your developers can write a bug-free program. Your developers can type in elegant lines of code in a blink. Your developers can detect the most subtle edge cases. But that’s not enough.

You’ll still need a good software testing team.

Testers do not only hunt for bugs. They also improve your product’s functionality for business purposes per requirement. A complete product isn’t enough. Your company will have to deliver a product that users love.

Then there’s this:

“Testers are inferior to developers.” Sadly, a lot of people still have this mindset.

It’s wrong.

A good developer may not be a good tester, a good tester may also not be a good developer. Being a tester requires a specific skill set. This includes overall knowledge of systems, databases, and effective communication. Maintaining good communication is often a significant challenge.

2. Time constraints

Testers are usually put in at the tail end of a project. And it can always be worse:

“Hey so we’re planning to launch this product next week, can you try to speed it up? “, said product manager of the year.

“Well yes, technically…”

We will then try to complete our tasks, but we won’t be able to mitigate as much risks.

Oftentimes, we’ll focus on finding trivial bugs rather than getting a deep understanding of the software. We’ll bypass subtle errors within the system, overlook code maintainability and quality. It’s the best we can put in considering the circumstances. No matter how hard one tries, it’s impossible to ensure real quality testing under an underestimated deadline.

Consider getting testers to test and collaborate with developers early in the process. We can guard potential failures out early and not be pushed by deadlines. This will make everybody happy, especially your users who will be using the product.

3. The One Where We’re Not Notified of Feature Changes

This is a testers’ worst nightmare. Imagine you spending days reading code and writing scripts. Then, you hand in that report saying there are 32 bugs only to receive this:

“Oh right, those are not bugs, we updated some new feature changes. Didn’t we tell you?”


Now you go back to your corner, rewrite all the test cases, repeat the whole process again.


Failure to communicate between different teams can result in a lot of unnecessary doing and redoing. This leads to wasting time and costs in the long run.

4. The Bearer of Bad News

Nobody likes to be told “Your child is ugly.”

Some developers don’t like to think that their work needs “fixing”. But it’s our job to report errors. It’s not a pleasant responsibility.

Tester:” Hey there’s a bug at x line”

Developer/ Manager: “Brace yourself. I’m gonna throw you a sh!t storm of explanations for why you’re completely wrong.”

This is when testers need to know their facts to prove why it is indeed a bug.

But what if we were wrong?

Our opinion won’t be heard the next time. Testers don’t have that much say in the whole process because it’s not “their product.”

Yet, testers have the formal right to block a product they deem unqualified. We hold the responsibility to decide when to stop testing. We judge whether a product is ready for the market. This can cause a lot of conflicts between testers and product managers. Testers are sometimes blamed for slowing down the process.

5. It’s Not Always Exciting

Don’t get me wrong, we love our job. This is just a common thing that everybody experiences at a point during their careers, whether you are an office employee or a construction worker.

Writing the same bug reports and executing the same test cases over and over again is not that exciting. No matter how creative, passionate or relentless a tester is, there will always be some degree of repetition. The thrill of bug hunting at first slowly fades away.

“What about automating the process?”

It’s one solution. However, we, as testers, will have to be really careful. We have to make sure that it covers all edge cases and do what we mean. One mistake can pull the whole team down. Automation is a double-edged sword, especially when a tester’s mission is to ensure quality.

But hey, we sleep, we brush our teeth, we shower, we work every day. We do repetitive tasks to meet basic needs so we can do things we love. It’s the same for testers. After doing the basics, we’ll break things. Breaking things IS exciting. We’ll explore software and seek for hidden patterns that yearn valuable information. Testing is now fun again.


6. It’s a thankless job

Being a tester is the same as being the backstage crew. We ensure things run smoothly. However, only the company, the manager, and the developers get the stage. Nobody remembers the testers when all is well. It is “our job” after all.

What if the company releases their product, and a bug crawls out? Of course it’s the testers’ fault!

Testing is the last process that a product goes through before getting to consumers. Therefore, blaming on testers would be the easiest and most obvious thing to do. Everything still needs to be perfect, even with an out-of-the-blue deadline and endless workarounds. Now we’re back to number 2 again.

Always be strong, testers.


Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:

As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …