They’re not mistakes; they’re opportunities to learn
Have you ever bought something in a shop and only realized that when you go to use it, that you learn you’ve made another one of your mistakes and bought the wrong item?
Being on a vegan diet, I can not begin to count the number of times that I’ve done this with food items.
Blindly picking something off the shelf because it has ‘dairy-free’ on the label. But if I had taken the time to read the ingredients list in the shop. Rather than when I’m half-way through cooking a delightful pasta dish that evening. I would have discovered that the sauce contains eggs.
Not a good feeling.
But even though I dislike it when something like that happens. It’s a good opportunity to reevaluate my strategy for the situation and try to mitigate similar issues from occurring in the future.
So in this case, it would be “Don’t go by what is on the front of the label and read the ingredients before buying food.”
We can make mistakes in a wide variety of situations as well as occupations. They are inevitable if we ever want to get better at our craft.
For mistakes made in software testing, they can originate from a variety of different sources. Not limited to, communication issues, documentation problems, resourcing conflicts or just plain mistakes.
But whatever the source of the issue is. It is imperative that as software testers do we not only own the problems that are made to build trust in our teams. But to also learn from them and realize the lessons that they provide.
Ownership
Depending on the issue that has made it into the production environment and the hands of their users. Mistakes can have serious effects on the image of your company.
When an issue is first reported, some people may have the initial reaction to point fingers and try to find someone to blame the problem on. Even though this might seem like the right course of action at the time. Blaming people won’t get issues solved and creates a negative atmosphere within teams. It can often be toxic and gives life to a culture in which people don’t enjoy working in.
What everyone will appreciate is when a tester steps forward and owns the problem. Admits their part that contributed to the issue getting its way into the client’s code.
Now it may not be 100% your fault and there could be other reasons that contributed to the issue being present. But as testers, the least we can do is own our contribution to the process.
Mistakes can be compared to a tiny spark which has the potential to grow into a great burning fire that engulfs everything you know. Ignoring the problem, or not recognising your part that contributed to the spark existing in the first place, only feeds the fire further.
I know from my personal experience that admitting when i’ve made my own mistakes, either by missing something, or another error of my own. Can be I’velike admitting not only a personal failure. But also my inadequacy as a tester.
But we only need to remind ourselves that everyone has made mistakes. Every single person that we can think of.
So don’t beat yourself up about it and be honest with yourself and others.
Lessons to be learned
After owning the mistake that has already been made. Attention should now be turned towards ensuring that it doesn’t occur in the future.
First of all, you need to understand the problem and investigate all the contributing factors.
I find it useful at this point in the investigation to compile a timeline of the events from start, to finish. This enables me to look up a step which is responsible and either make amendments to my test steps if needed. Or make suggestions to other teams.
Again, this shouldn’t be a finger-pointing blame game. We are all part of the same team and responsible for delivering quality software to our end users. That should always be at the forefront of our intentions.
Once you present the evidence of a potential weak point in a process to another team. How they act on the information is beyond your control and you should instead focus on the things you can change. Like your documentation, training processes or test scripts.
Followup
It’s always a good idea to hold a follow-up session to not only talk to stakeholders about any changes to your test scripts. Or any steps taken to mitigate the mistake from occurring in the future. This also allows you to inform your team about the changes so that they are aware of anything they need to do.
It’s possible of course that no-changes need to be made to any of your test cases or test scripts.
Given the example of a step getting missed in a test-case. You may need to highlight that fact and be honest with everyone about it.
Conclusion
I read a quote a while ago that read “You’re only as good as your last haircut.“
I think that can be interpreted differently.
The way we react to mistakes that we have made or contributed to speaks volumes to others.
So when you make a mistake, choose to be honest about it and responsible for the follow-up actions.
