Helping With The Feeling Of Guilt

Archive
1

The feeling of guilt in testing about not doing enough came up a couple of times in discussions at TestBash Manchester. These talks ranged from not being able to do more, bugs being found after testing had taken a crack at the application and feeling guilty about not being able to do exhaustive testing (even though we all agreed we know this isn’t possible).

It got me thinking about this blog post I saw a while ago The guilt of not testing everything. I also wondered how other people deal with the varying guilt feelings we all have as testers? We tell ourselves over and over again that we can’t test everything and quality is a whole team responsibility but we still beat ourselves up when feelings of guilt surface. What have you found to be the best way around this in your own experience?

6 Likes
2

It happens to me when some defect gets through testing and is found by someone else or a user at UAT phase. I still tear myself up about it.

There isn’t an easy way to deal with it in my opinion. As I have been working longer as a tester on various projects, the key consolations I have taken from this are that -

  1. As you say it is impossible to find every bug and test every scenario.
  2. A few bugs reaching production are in most cases not the end of the world.
5 Likes
3

I think what helps me not get too upset about bugs I missed is to see it as a learning experience. I think about what I can do differently the next time, to try to prevent that flavor of bug from being missed again. Progress not perfection!

4 Likes
4

I think this is a good canary as to whether the whole team owns quality or if individuals/subsets own quality. If one individual (or some subset of individuals) are the ones that feel guilty, that to me seems like a clear indication that not everyone is owning quality.

One of the lessons I’ve tried to take away from when bugs make it to production is that the Swiss cheese model failed, i.e. everyone missed it. Just because quality was one of the final layers of the Swiss cheese doesn’t mean they’re the one to ultimately blame.

5

Lesson 41 in “Lessons Learned in Software Testing” helped me here: “When you miss a bug, check whether the miss is surprising or jsut the natural outcome of your strategy”. It advises to find out about your test strategy, if it is sound enough and you just happened to miss the bug, or if you missed it because the strategy was not good enough.
Helped me to improve my testing effort. Yet still, if I miss one, I am still feeling bad about it!!

5 Likes
6

I think this is an interesting point but I’ve also come across people who will briefly feel guilty about it and move on. I don’t think they’re not owning quality, they just seem to have better ways (than me) for dealing with the guilt felt it seems.

7

If a bug gets past my testing I first look at the bug and try to recreate it. If it was created in a way that it was being used at the time it was found and not as per requirements (I work in embedded software in a very controlled indstry)then I don’t worry about it and speak to the system engineers to see if the requiremets need updated/changed to cope with how its used.
If it was found in a away that I missed it then I use it as a learning experience update my tests and remember it for next time.

I generally don’t feel guilty about it. I apologise for missing it, fix it and ensure that for the other projects I am working on (I am working on multiply projects at once) I catch it if it is there as well.

“Don’t dwell, learn and move on” is what I was taught in 2000 when I started testing by my then manager.

1 Like
8

What has helped us is having the whole team own quality and work as a team to develop the test plan for a particular feature. This helps prevent the “how did test miss this!?!?” that sometimes happens and shows light that there was really not much more we could do.

We still feel bad that we missed something but at least we feel bad as a dev / test team and not an individual.

2 Likes
9

Totally understand where you are coming from concerning the strong feeling of responsibility and potential guilt if a bug gets through.

I have noticed the depth of my guilt feeling and my dealing with it is affected by how team lead/management reacts. In the past, I have worked in both a non-blaming & blaming team environment.

When a bug has got through, team lead dealt with the management response, and worked on a solution where the entire team solved it. We all then had a laugh about it and (remember we were very close, everyone had worked together for sometime & respected each other professionally) the team member who missed the mistake got to wear the laughing cone of shame for the morning. We were comfortable to say ‘Hey yip I missed that but we solved it’. Trust me everyone in that team had the cone at some point which meant we all recognised no matter who you were including the team lead you might miss something. Yes the team lead had the cone a couple of times too.

With a different team as soon as an issue was noticed in production the release manager would yell out in front of the entire office ‘You did test this didn’t you!!’ It was horrible and our entire team I think always felt guilty and tense.

Both times I felt a deep sense of responsibility (that is my fundamental nature) but the degree of guilt associated with it was definitely mitigated by the reaction of my team lead & team. The closeness of the team takes time and the right personality combination. It also starts from the top > down and I was very lucky to work with some amazing people.

1 Like
10

To quote Weinberg “First of all, recognise that any set of tests is a sampling strategy and then no matter how many or how few your resources, choose the best representative set of tests you can”

2 Likes
11

Document everything you can and record everything you can for your own improvement and the improvement of others. Adhere to the Test Strategy of your business and offer improvement suggestions.

Lessons learned at the end of projects and test closure activities in general will counteract any feelings of guilt for missing anything, as this is a what can we not miss/change next time exercise.

Bugs will get through we will not ever capture everything! We will make mistakes and we will grow from them.

Pesticide Paradox …popped into my head too we need keep changing our approach and tests to ensure that we capture new defects.

1 Like
12

In my early career there were some QA managers who personally made sure we were “guilty” everytime a bug was found in the system, this was around 7 years ago. But for years it me feel fearful and guilty before saying that something was production ready. It also gave me an impresssion that QAs are seen as second class citizens in the world of software.
It took me a while, but I see today that this was a problem with the working environment and the lack of understanding of a QA role and not really my fault.
Such managers and experiences have made me wiser though. Today when I join a team the first thing I do is talk to people on the team and discuss what they think about Quality and who they think is responsible for it. Which has helped me set an early expectation that we should be working as a team and we all equally responsible for quality.

I have also stopped trying to test everything.
The one thing I do religiously for production bugs is retrospecting “why did we not find it?” which leads us to have a better test strategies and really think about how the customers might be using a product / whats important to them instead of trying to test everything [which is impossible to define]
I don’t want be wasting time testing things that the customer doesn’t care about. That precious time can be used instead to explore/ see where I can provide “real” value in the team.

8 Likes
13

Hello,

the topic is a little old, but I fear that it is still a relevant one.

If you are a tester and feel guilty for some aspect of your work or somebody wants to blame you for not testing good enough, then be aware of the following things:

1. SW development, including the quality assurance is a team sport.
So if the user finds an issue, the whole team is responsible to analyse and fix.
There are a lot of reasons why defects occour: requirements incomplete, defect in source code (typo, loops: one to many or to less), user error, interferences with other systems running at the same hardware as the SUT and so many more.

2. The customer decides, what level of quality to achieve.
He/she pays for development and testing. If there is not enough budget to deliver a product which is tested well/long enough, it is the tester’s responsibility to inform the customer about the risks and what kind of mitigation the tester would propose.

3. Learning and continuous improvement is not up for discussion
Same with skills and knowledge - if their is no budget/time/willingness to support team members incl. testers to learn what they need to do their jobs well and better, there is a higher risk for defects.
Learning and continuous improvment is not up for discussion but a duty for everybody (and supervisors should push).

4. Be aware of humans
A former Scrum master told us: “Keep in mind, that everybody is doing his/her best at every time. If you have a good day, your “best” is just great. If you have a bad day, your “best” is not that great, maybe it’s ok or even not okay.”
He made me aware of differences beetween us humans: everybody has his/her talents - and weaknesses, me too.
Means: You create a test strategy and execute it - in all conscience. Why should you feel guilty for doing your best?

5. The concept of “guilt” doesn’t fit.
Guiltiness is not helpful.

  • If people feel guilty, they feel bad, too. Are they then able and motivated to do their very best?
  • Guiltiness means looking backwards. This also doesn’t help to avoid defects in future, does it?
  • Guiltiness and negativism are sibblings. And kids of that kind nobody wants to play with.

6. Feel uncomfortable instead of guilty and ask yourself “why”.
What are your reasons for feeling uncomfortable with the results of the teams work? What can you do to avoid the reasons?
Humans want to feel good. Feeling uncomfortable is a good motivation to change something :slight_smile:

Short:
I think there is only one reason, why a tester should feel uncomfortable (but not guilty): In case he/she knew better but did something else: e. g. executing a more simple test case instead the neccessary one to go home in time; not reporting risks, to not be the one who brings bad news (and will be blamed for). Reasons like this.

And this is completely ok - if you learn from it :wink:

Testers rock!

1 Like
14

A counsellor I saw once told me that guilt was an entirely useless feeling. I think anyone who has worked in waterfall (hawk… spit) will probably suffer it more. My last job, I was the sole arbiter of quality (and it wasn’t even really quality, so much as straight testing), so if anything got out, it was my fault and my fault alone, and damn, did they make me aware of the fact. My new company is much more aware of the fact that the whole team is responsible for quality, and any attempt to claim the blame is rebutted.

2 Likes