Failure can be a tricky thing in the workplace. Improperly addressed, mismanaged failure can create a toxic workplace where employees are incentivized to ignore or hide failures rather than address them. This type of work environment is challenging regardless of industry, but can be downright destructive in a quality assurance or quality engineering team where failed tests and software bugs are an essential part of the role.
The best quality managers understand every failed test is an opportunity to learn and ultimately improve not just the product, but the entire product development process. Particularly as more quality teams turn to test automation and embrace a new role as quality advisors, expectations and reactions to failure need to be properly managed to promote learning and experimentation among testers and engineers alike. Regardless of how a team manages testing, promoting a culture of quality means that failure needs to be celebrated.
Shifting the testing conversation
Regardless of if it’s a failed test or failed software, the conversation around failure needs to change for quality engineering. Typically, a failure of either type means delays in product or feature delivery, potentially impacting the company’s overall performance in the market. But, failed tests are where quality teams uncover new opportunities to improve testing strategy, leading to improvements in quality for releases down the line. Bugs discovered before reaching the customers protect the user experience, an essential part of maintaining a competitive edge in the digital-first world.
Celebrate finding defects
Traditionally, the discovery of a software defect causes a collective groan across quality and development teams. Depending on when a bug is discovered, it risks causing delays in the delivery schedule or panicked late-night coding sessions in an attempt to repair the issue in time. These end-stage fixes have historically been a cause of tension between quality teams and developers, contributing to work silos that slow down production schedules and create unnecessary strain on DevOps.
The first step to changing the culture around failure is testing early and often in the development process. If a bug is discovered during the code stage or pull request stage, it’s far less likely to impact delivery schedules and much easier to fix. Plus, it encourages developers to become active participants in testing, making it easier for quality teams to advise them on best practices and build a high-impact testing strategy that improves quality for the long term.
Second is establishing incentives that encourage and reward the discovery of software defects. After all, every bug caught before code is deployed is a bug that will never impact customers. Quality teams need to develop tracking mechanisms to deliver insight into the number of bugs that reach customers, and the severity of those bugs. This encourages testers and developers alike to think about the positive impact of bug discovery, rather than focusing on the potential headaches they caused.
Goals over games
Once the initial stress around bug discovery is managed, quality leaders should stop playing the blame game and begin implementing long-term improvements. As mentioned above, customer success is a valuable - but often overlooked - partner for quality teams looking to understand and amplify the impact of testing. Customer support teams are the frontline when it comes to understanding customer challenges. By working with customer support, quality leaders can better understand how bugs impact users, and track those issues. By connecting developers and testers to the real-world results of their work, quality leaders shift the conversation from “checking the testing box” to “executing a purpose-driven strategy.”
When failure is accepted, it becomes easier to investigate what caused the failure in the first place, transforming failures in learning opportunities that can ultimately improve testing strategy. As bugs are investigated, quality teams should create a process for documenting the cause of each defect, how it was discovered, and at what development stage it was found. This helps identify recurring issues, such as a specific integration that breaks when new code is introduced. As software becomes more complex and more reliant on integrations like APIs, being able to flag frequent pain points saves the entire product team time energy down the line.
Failure is not the F-word
Failed tests have a long history of causing headaches and stress for developers and quality teams alike. By changing the culture around failure itself, quality leaders have the opportunity to make their teams more open, data-driven, and aligned around long-term goals. Effective failure response also lays the foundation for greater collaboration across the entire organization, from integrating developers into the testing process earlier to working with customer support teams to track what bugs impact customers and how often. This ultimately builds a data-driven, high-impact testing strategy.
Are you a quality leader transforming the culture of testing? Try mabl free for 14 days!
