Laying Off Testers? Think Twice Before You Act!

We are experiencing layoffs in tech left and right. Software testers are usually some of the first people to be let go: they don't have visible deliverables, they don't write code, the bugs they find "only slow down development," and so on. So why keep them in the organization? 

The thing is, testers do a lot of invisible, important work. They are the glue between engineering and product development, and they actually help speed up the delivery of a quality product to customers. 

How Testers Are Usually Seen  

Testers are often perceived ONLY as the people who receive the code when a feature is developed and execute test cases on it. Or, if we speak about test automation, a tester is somebody who writes automated tests and maintains them, reports discovered issues, and that's it. 

When I started my career as a quality engineer seven years ago, my understanding was similarly narrow. My working routine was creating test cases, based on the requirements written by the product owner and when development was done, executing tests, documenting found bugs, and verifying defect fixes. 

I didn't realize that testing is so much more than that. But then I changed jobs, joined various testing communities across the globe, and talked with people from all over the industry. This opened my eyes: testers play much broader roles across a software development group than what I’ve described above. And the new information I learned shaped my vision and ways of working. 

Changing Perceptions of Testers… And Testing 

In modern companies, testers are active members of the team from the very start of the development cycle. In the definition phase, we help with risk analysis. We look at the requirements, highlight gaps and uncertainties, identify risks that could threaten the product, and foster discussion with product development and engineering. Testers learn about a product from both technical and business standpoints, which allows us to bring new perspectives to the table. We often ask out-of-the-box questions which might not be asked by anybody else. Sometimes, such questions can invoke a discussion whose results bring benefits to the company. 

Testers help during requirements gathering and design. I remember one day when a product owner came up with an idea for new functionality. He initiated a kick-off meeting with the team. Developers liked the idea and started to jump to a solution. Fortunately, the testers on the team advocated looking before leaping. The testers, who worked with different teams across the company and had a good overview of what had already been done, pointed out that similar functionality already existed in one of our products and that it might be useful to consult with the responsible team and reuse the implementation. And that is, in fact, what happened.

This way, we reduced costs significantly. The new feature required no new design or coding, and we managed to keep consistency in user experience across our SaaS solutions. 

How Testing Can Expedite Deployment

People might think that testing slows down development. Testing means more work to be done during implementation, and it must be very annoying when developers say, "We are done; let's deploy to production!" and instead hear that there are issues to be fixed before release takes place. Testers execute their scripts and do their checks, find more and more issues, and advocate for them to be fixed. And then, developers need to invest time and effort to resolve the issues found instead of "just releasing." 

Contrary to popular belief, testing drives the process forward. As they do different activities — from exploratory testing to running automated scripts — testers identify the problems and communicate them promptly to stakeholders. Testers not only raise the awareness of the state of product development, but they also advocate for fixing the issues found and often accelerate the development process. 

Even though the release of new features can feel more worthwhile than anything else, in reality, if a bug is released, and customers complain about errors in the new feature, the mental cost of context switching for developers (moving back and forth between defects found in released features and work on new features) actually slows down progress on new projects. 

Product Release: An End And A Beginning

Finally, there is the release. Development and test execution are completed, and the feature becomes available to clients. Yay! People would say that the tester's job is done here, and it's time to focus on the new feature. However, this is not the case.

 After the release of a new feature, we analyze metrics around it: how fast and reliable it is and how the new functionality affects overall product performance and stability. This is important for identifying critical parts of the software and prioritizing work in the future. We also look at the adoption of the new feature: how clients are using it, which questions they raise, and where their main struggles lie. 

Last year at a conference, I shared how knowledge of customer usage data can help us shape testing strategy and explained that we testers need this knowledge to do our job efficiently. If we know that clients are suffering or stuck in a certain place, we will voice it aloud so that our engineering team can address it and will advocate solving those issues with high priority. And in another common case, if a feature is not widely used, there is probably not much sense in investing time and effort in fixing small defects in it which were found internally. 

A Tester’s Work Is Never Done

Our work never ends. We are the glue holding the team together, we accumulate knowledge from developers, product managers, designers, customer support engineers and other stakeholders, and we see the big picture. All of these points of view on a product are important in the tester's work, and you can hardly find any other role in the company that has this knowledge. 

This unique mixture of skills and knowledge allows us to be the go-to people in case of any questions about "how it works now." We know the current state and can assist in bridging the gap between vision and reality, significantly easing development. 

Now that you know what your testers REALLY do, think twice about letting them go. 

More Resources

• When Testers Deal With Process Debt: Ideas To Manage It And Get Back To Testing Faster, Melissa Eaden
• Ten Reasons The Whole Team Owns Defects, Kate Paulk