Talk Description
As a profession we are constantly striving to move away from the stereotype of QA with success defined as zero bugs in production. Instead we strive for our companies and teams to understand that testing should be considered throughout and within the ideas brainstorming, design review and coding activities rather than purely at the end of the development process when a build becomes available. Then, if a bug is found in released software we aim to look at how that bug escaped detection and improve the team’s testing, coding and design processes going forward.
However, hearing the phrase “there’s a bug in production” still drives a lightning bolt of self-doubt and blame through my very core. I start questioning internally whether I’m being blamed for the failure and kick 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. But, when these situations occur on a frequent basis, or in batches without sufficient recovery time then the blame and self-doubt can take hold.
Even in the best projects with collaborative teams experiencing minimal production issues – It can be hard to maintain a healthy and happy sense of self whilst also being the ‘bad guy’ pointing out the problems.
There’s no perfect solution to this situation but I have a few ideas to share, drawn from my own personal experience. Hopefully this talk will inspire other testers to share stories, share experiences and (potentially grudgingly) admit that testers, like their team mates, are human too.
By the end of this session, you'll be able to:
- TBA
Suggested Content
