Testing Excuses, Blame and Fear

Last week I published a blog post on work place culture. I look at some excuses a tester might make when confronted with a bug that went unnoticed. I then explain how these excuses might indicate an issue with the work culture, where fear and blame are encouraged, instead of the tester.

This post was inspired by another blog post by the thinking tester who discussed common excuses that a tester might make. This included ones I addressed in my own blog post and some others.

Here is the list:

I don’t know how the feature works
There’s no way to test the feature
The developer coded it wrong
The other tester on my team missed the bug
There wasn’t enough time to test
If I log the bug I found in Production, I’ll be asked why I didn’t find it sooner
I don’t know how to code

What other excuses have you heard other testers make? How did you respond to these excuses? Are they an indication of the testers incompetence, negative workplace culture or something different?

Here are the 2 blog posts:

1 Like

I don’t know about testers, but the “best” excuse I ever heard from devs was “It’s not a bug, it’s just something that’s failed far earlier than we expected”.


So clearly the bug wouldn’t be that it failed, but that it failed at the wrong time.

What did the developers do to make the ‘expected failure’ happen at the right time?

They fixed the bug that I raised. :grinning:

Here’s one I used myself in a post-incident review meeting:

“Well, if the testing had been done on that pre-production environment we’ve been asking to be fixed for the last eighteen months then the bug would have manifested itself straight away.”

The workplace culture was well and truly broken…

“It passed the automated test”

The scenario wasn’t automated. :man_facepalming:

It all comes down to the fact they were thrown onto a new project in the last minute and believed everyone around them instead of looking for themselves. You live and learn I guess.

When I started in testing, I heard these phrases were stated by team members on other teams. Over the course of a handful of project, I heard these statements but usually in jest.

However, knowing that these statements may occur, I started establishing rapport with the project team (developers, testers, analysts). More recently, I collaborated with the lead developer to establish a team approach to quality; quality is a team sport. We had better unit tests and a lot fewer defects.


“Why did you miss this bug?” is itself indicative of bad culture.

  1. It’s putting the responsibility of quality on a single person. Why didn’t the designer catch it? Why didn’t a developer catch it?
  2. It’s not productive pointing fingers. Ask instead "what can we do to ensure that this type of issue doesn’t make it through again? What processes can we fix? Can we add some automated test coverage? Can we write some manual test cases?

I think project retrospectives are really important and they’re extremely important for ongoing improvement!