Making mistakes at work happens to everyone. It’s an inevitability of professional life, right along with coworker conflicts, management issues and heavy workloads. Mistakes vary in severity and impact, but they often leave you feeling horrible, guilty and maybe even fearful about losing your job.
No matter your experience level or rank as a software tester, there are ample opportunities for mistakes to happen. It doesn’t help when the organization places the entire burden of quality on software testers. Even when organizations claim that quality is everyone’s responsibility, when a bug is found in production, the spotlight is on the tester.
So, how can testers move on from a mistake and recover their confidence and credibility? This blog discusses some of the common mistakes made in software testing, the ramifications the tester might face, and some ways to recover and move forward.
Types of software testing mistakes
The role of a software tester is to learn the functionality of an application, explore it thoroughly and identify defects. Testers also track defects, reproduce them, and take steps to prevent a recurrence of issues. There is no such thing as a defect-free application, but testers work hard to prevent defects from reaching customers.
Still, mistakes will happen in software testing, which can unfortunately undermine all of this effort, especially if it’s a customer-facing defect.
Types of mistakes software testers typically make include:
Missing a defect during testing that customers experience after release
Writing inaccurate or invalid defect descriptions and steps to reproduce
Rushing test execution due to time constraints or pressure
Deleting test data
Misunderstanding user story descriptions or requirements
Failing to ask questions or clarify test case steps or functionality
Mistakes generally come from inexperience, poorcommunication or collaboration, rushing through testing, and failing to follow procedures. Defect escapes to the live system are typically considered the worst software testing mistakes. However, misunderstanding requirements and failing to ask questions also contribute to defects that affect the customer experience. Deleting test data on a development, test or staging server is embarrassing but often easy to fix with proper data backups and recovery plans.
Ramifications and examples of software testing mistakes
The typical ramifications of software testing mistakes are all over the spectrum. Software testing mistakes might only result in individual embarrassment, or they might cause customer backlash and a loss of business. No tester enjoys that sinking feeling when a customer finds a serious defect in the application function you’re responsible for testing. High-profile software testing mistakes ultimately affect your credibility. However, mistakes are also a chance to learn and make changes that improve your abilities as a tester.
Below, I’ll share three instances of mistakes I’ve made throughout my career. Let’s start with the most critical one, another that was simply embarrassing, and finally one where I was unjustly scolded — and without justification.
In each instance, once I discovered the mistake or was alerted to the problem, I felt embarrassed and horrified — and I was sure I’d be looking for a new job soon.
Example 1
I was the sole tester for a large development partner organization and an important client. The client received special release builds and custom-developed features by a small team, including myself and four developers. The application allowed physicians to enter medication orders for patients within an extensive, integrated healthcare system. I had been testing for them for over two years, and I knew the functionality inside and out.
However, timelines were short. On one build, I hurried through my test execution, and I missed an obvious and critical defect. When the physician entered a medication on a neonatal patient, the application failed to adjust the dosage to the correct amount. Fortunately, the client had a nine-member QA team who found the defect during acceptance testing.
Example 2
In most of my QA work, I’ve used SQL to manipulate test data for negative testing. Whether it’s data within a message ortransferred by an API, it’s important to confirm data errors are properly handled.
One time, I was setting up a user acceptance testing (UAT) environment so the customer could test an upcoming feature enhancement. My developer spent time loading test data specific to the customer. The customer started testing, and I conducted UAT along with them, using SQL to view different databases as testing progressed. Then, I got heavily involved in tracking a defect. Forgetting that the customer was also testing, I ran a test where I deleted a row of data to check for an error response. However, I failed to double-check my SQL query and accidentally deleted all the data in the UAT environment.
Example 3
In my opinion, this was not a mistake on my part, but management disagreed loudly and aggressively. Four years earlier, I entered a defect against a configuration setting that failed to function as intended. When this configuration setting was on, it would disallow a physician from entering and saving medication on a patient with a recorded allergy to that medication. Here’s the problem: It did not stop the medication from being ordered and saved. The defect sat in a defect backlog and never made it past review to get fixed. Every time a new product manager arrived, I brought that defect to their attention.
Four years later, I was finally able to convince the team to address the defect. However, it brought negative attention back to me. I did my job. I entered the defect, and I repeatedly attempted to get it fixed. The management team jumped all over the oversight, and I spent hours defending my actions in meetings. I had to produce all sorts of documents that proved the defect existed and what had been done to prevent it from happening again.
Making mistakes is a learning experience, even if you disagree about where the mistake occurred. The important thing is to approach it with a sense of honesty — respond to it, address it, and take steps to prevent it from occurring again.
Responsibility, accountability and growth
The path to professional growth includes embracing your software testing mistakes. Being responsible and accountable requires honesty and integrity. Fight the urge to avoid, deflect or blame others for mistakes. No matter how badly it feels at the time, that dread will pass — even more quickly when you focus on prevention and recovery.
Two of my three examples of software testing mistakes were my issues. I believe the third one was a failure of management and the defect review board to recognize the necessity offixing a reported defect, exacerbated in part by the organization’s massive technical debt. Part of the challenge of testing revolved around an excessive amount of reported, but unfixed defects. If the organization had taken the time to address or fix the 50,000-plus defects in the backlog, the issue might never have occurred.
Mistakes are full of life lessons that will guide your career and your actions as a tester. For me, my mistakes made me stop responding to time pressures. I work productively and efficiently, but I refuse to rush through testing. I focus on my testing wholeheartedly until I’m done. No multitasking.
