Quality Experience: The Importance of Making Mistakes

I remember the first time something I tested broke in production. I tested a functionality that affected three different integrations. The time to test one integration was painstakingly slow - 15 minutes per test, per variation. I was new to QA, naive, and timid about asking for help. I struggled between the balance of testing a larger feature paired with a looming deadline. In my immaturity, I tested what I thought to be sufficient and signed off on the release.

The results weren’t devastating. No one died. But, the consequences were swift. Two of the three integrations I was responsible for didn’t work and production was broken.

Support tickets started rolling in and I went straight to my manager. I told him it was my fault. I explained how long testing took and how I didn’t want to be late for the deadline. He was not angry. He listened to my fear/guilt/shame/confusion/despair and talked me through everything I was feeling and thinking. He taught me that mistakes aren’t something to be afraid of, but the power of a mistake is what we can learn from it and how we operate moving forward.

Here’s what I learned when it comes to making a mistake.

Ways to Prevent Mistakes

Be clear about what you can and cannot do

Sometimes mistakes are made when people shoulder more tasks than they can handle. When working in an organization, it’s important to have the psychological safety to say, “I don’t think I can take anything else on. I need to focus on what I have at present.” I talk more in-depth about time management in my post, “Time to QA: Thoughts on Time Management”.

Use Your Voice

Not all organizations welcome employees who speak up, but in my opinion, to the best of your ability, if you see something, say something. If the acceptance criteria aren’t clear, ask for clarification. If you are working on/testing a feature and the logic isn’t making sense, talk about it. When you find an issue, raise it to the team to figure out the next steps. If someone isn’t in a meeting who should be involved, ask for that person to be invited. Ask questions, speak your doubts, and be willing to speak up even after the meeting is over. The more we speak up for our work, the more refined it becomes.

Ask for help

One of my biggest mistakes was not knowing that I could ask for help when it came to my testing. After I spoke to my boss and talked with the developer, I learned that the time between tests could be reduced to 5 minutes instead of 15. Through this experience, I learned that if something is inhibiting my ability to test, I can bring it up, and we could probably find a solution. If you have a need, speak it! People will (and should) be willing to help you.

Be willing to inconvenience yourself

The time it took to test three integrations, even after the test time was reduced was tedious, and not fun. What made it worse was testing the integrations when I knew the support team was dealing with unhappy clients. When it comes to developing an application, the engineering team will always experience inconveniences:

When a defect is discovered before it hits production,

After a bug is released into production (known issue),

After a bug is released into production (unknown issue).

The majority of the time, in my opinion, we can catch many defects before they hit production if we are willing to inconvenience ourselves as a team and fix what’s broken. I’ll speak more about the third inconvenience in the next section.

Ways to Recover from Mistakes

Mistakes will happen. Bugs will be released. I test functionality to the best of my knowledge and then I speak openly when I get to the point where I don’t know how else to test it. Then the team can decide when and how it will be released. And, when we’ve done everything we can, sometimes the shit still hits the fan. Here is how I’ve seen great engineering teams own up to their mistakes.

Own your part

At another organization where I worked, a bug hit production and I found out I had missed a testing scenario. Mostly, it was due to the lack of education about the application, but I went to my manager and owned my part immediately. Speaking with the developer, he did not blame me but instead blamed himself for missing the same scenario. Another QA stepped forward and spoke about how he missed it as well. It almost sounds funny - like a tug of war of whose to blame, but the team itself was acknowledging they’d made a mistake. There was a group refusal to let one person take on the full blame for the issue. This made me feel safe as a team member, knowing we all would take responsibility for what was missed.

Use your experience

Mistakes are mistakes. While we can roll them back (hopefully!!!!) they are still fantastic learning opportunities. When issues show up, I discover more about the application and its current functionality. I find my gaps in testing knowledge, what I missed, and what needs to be documented for the future. And, I learn about my team, who they are, and what they need during this time.

Make it right

Drama does not help. Even bad feelings teams experience don’t get our users to a fix more quickly. What counts is working towards a resolution as fast as humanly possible. There will be plenty of time to assess the error and how to improve our processes afterward. Save the guilt and racking your brain for how things went wrong after the issue is resolved. Once our users are in a better place, create space for yourself and your teammates to calmly think about the issue. In a meeting with QA professionals, someone stated “Don't make decisions based on guilt." Separate the feelings from the scenario and build your remediation on self-respect and what makes sense for the organization.

Mistakes will happen. We assess the risk and we move forward. That’s what creating anything good is about. We are taking a risk. If we risk while respecting each other and being aware of our blind spots, we can learn so much and create far more than we thought possible.

Till next time…

Written with S O L A C E - Ethereal Meditative Ambient Music - Deep & Healing Soundscape playing in the background.