As an profession we are constantly striving to move away from the stereotypes that QA means no bugs in productions, that testing should be considered throughout the development process rather than just at the end. When a bug is found in released software we aim to look at how that bug escaped detection and improve the team's testing and coding processed going forward. However, the statement that "there's a bug in production" still drives a lightning bolt of self-doubt and blame through me. I start questioning internally whether I'm being blamed and kicking myself for missing the bug as I feel the adrenaline flow and my heart beat faster. Even in the best agile project team where blame is never mentioned - I still blame myself for letting the bug through (even though logically I know that I did no such thing). I'm sure I'm not alone.
The truth is that the adrenaline and self-doubt can be great drivers of understanding problems, finding or confirming fixes and staying alert until the situation is resolved. However, when these situations occur on a frequent basis, or in batches without sufficient recovery time then the blame and self-doubt can take hold.
It is hard to maintain a healthy and happy sense of self whilst also being the 'bad guy' pointing out the problems. Advice to deal with the situation by describing oneself as merely an "information provider" can exacerbate difficulties by separating the tester's personality and self from their role and the team that they work within. At the end of the day the information we provide is often bad news for one (or more) of our colleagues - let's acknowledge that fact.
I don't have a perfect solution but I have a few ideas to share from my own personal experience. Hopefully this talk will inspire others to share their stories and experiences about how we are all human and about how embracing our humanity can help us work better together.
Katja includes a summary and sketchnote of this presentation