Helping With The Feeling Of Guilt

(Heather) #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?

(Paul) #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.

(Elise) #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!

(ernie) #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.

(Andrea) #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!!

(Heather) #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.

(Gavin) #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.

(Andrew) #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.

(Kim) #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.

(Andrew) #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”

(Jacqueline Baker ) #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.

(prakriti) #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.