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”.

2 Likes

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.

Joe

“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!

6 Likes

Some responses I heard were:

  • Our BA didn’t specify that - negative workplace culture
  • I’m the only tester here - testers incompetence
  • The test was too long - testers incompetence
  • The developer said there was no need to test - negative workplace culture
  • It’s s tiny I didn’t see the point - testers incompetence
  • Dev is going to ignore it anyways - negative workplace culture

Whether that’s down to incompetence is a matter of how much the lone tester is being asked - or told - to do and in what timescale.

And as for “It’s so tiny I didn’t see the point” - well, that may be down to incompetence, or it may just be the result of a negative workplace culture if small and apparently insignificant bugs have been rejected, ignored or belittled by devs in the past Obviously, such people have never had a small and apparently insignificant bug blow up in their faces.

2 Likes

These points could indicate something beyond what you said.
For example, “Our BA didn’t specify that” is something I’ve heard frequently in my testing-life. In fact, I’ve heard it so often that part of what I consider testing is to think about what wasn’t specified which should have been specified. So someone using that excuse could also be bias (blind to things which weren’t specifically mentioned), inexperience (haven’t been burned by this scenario enough yet), or a simple mistake (oops, we all missed this point).
Where it can become “negative workplace culture” is after the mistake is made, nothing is done process-wise to rectify it. Like if only blame is set and fingers are pointed and it’s “someone elses problem”.
Where it can become “tester incompetence” is if the tester doesn’t communicate the cause of the issue and accept a portion of the responsibility.

Consequently, one of the things I’m guaranteed to test is any functionality where someone else on the team says “There’s no need to test this.” Again, this comes from my own past experiences where there’s often a reason why someone would tell you that. In my experience, it can be that someone is masking a problem. There are valid reasons, such as "we’ve tested this so often in the past, that there’s little risk in skipping this portion of testing, which is different than saying “no need” in that I will still test it, but it will be on the lower end of my testing priorities, and the absence of testing that feature will still end up in the testing report as well as the reason why it wasn’t tested.

1 Like

You have a valid point, if the tester is being asked more than he can test and or in a tiny timescale. In this case I would recommend to hire more testers as well. But would it fall in testers incompetence if the workload was appropiate and the time as well?

As for the second one, definitely a negative workplace culture if you report bugs and no one fixes them. But if you work with a collaborative dev team, where does it fall?

I couldn’t have said it better :slight_smile:

I agree, context is definitely important in this case (“we’ve tested this so often in the past, that there’s little risk in skipping this portion of testing”) . “No need” just brings doubt to my test, I ask myself “Is there really no need? why?”.

The hiring of extra testers is rarely in the control of the tester, so we’re looking at a negative workplace culture there. Otherwise, if the workload and the allotted time are appropriate, there may be other reasons. Incompetence may be one of them; but don’t put all personal failings down to incompetence. There may be issues in or out of the workplace that may affect performance.

Even if a dev team is collaborative, they may choose not to fix bugs that seem insignificant. The trouble then arises when some insignificant bug blows up in people’s faces in unexpected ways. For example, I once raised a bug on an online teaching tool because of a (quite bad) typo which was in a large caption over the CEO’s introduction. The CEO was not pleased. Sometimes quite small bugs can have reputational impacts that are out of all proportion to how they look to other people.

1 Like

It’s clear now. So… don’t assume it’s tester’s incompetence if the rest of the process works. Again context is good. This makes me think of my boss, he used to say Hi to every single member of the team and ask how we were doing but with specific questions of our lives, I image that was him trying to see how we’d perform that day. :open_mouth: