What makes us human is that we make mistakes. When I hear from a programmer that he does not use TDD because his code is bulletproof, this is bad practice to handle our errors. Here is the recipe on how to learn to fail. The post is based on a remarkable book written by Chad Fowler, The Passionate Programmer.
As a software tester, we usually bring bad news. It is important to know to pass that information. You must not blame specific team members for found issues. The report must be neutral: I found in this part of the application the following behavior that is a bug for the following reasons.
Software tester also makes mistakes. We can miss a bug because we make a wrong judgment about application risks. This is a software tester mistake. When we made a mistake, here is how we should proceed:
- Raise the issue immediately, do not hide it!
- Take the blame! Here we use the founder’s keepers approach. When the issue has a blame face, a team can concentrate on issue mitigation. You would not be fired if you take the blame. Or if you would get fired, you do not want to work for that employer in the first place. This is a bad employer. You have the opportunity to find a new job. Trust me, there are a lot more employers that like when software testers use this approach.
- Offer a solution. Sometimes solutions are obvious. If not, you should propose a plan on how to attack this issue. In both cases, you would be identified as someone who has a solution.
- Ask for help. The basic mistake is to be a lone wolf. The goal is to resolve the issue as soon as possible, not to take recognition for solving it by ourselves!