Over time, the QA industry has developed many great processes and best practices that drive software and business success. These practices have become the playbook for how to do good QA.

However, some common QA practices are outdated and are in need of innovation, while others have even had a negative impact on product success. Industry expert and Rainforest QA Professional Services Manager, Melissa Tondi, recently sat down with TechWell for a webinar to discuss the Top 5 Don’ts of Software Testing.

Keep reading to learn what these five big “don’ts” are, and what to do instead:

1. Don’t Be the Enabler

We become the ‘Why didn’t you catch that?!” team… give it up

QA teams often do a large portion of their work at the end of the software development cycle. This may be perceived positively by the team because it feels like QEs are saving the day. But waiting to manage quality at the end of the development process slows down delivery and hinders QA teams from more strategic initiatives.

Instead: Adopt an ‘all-for-one and one-for-all’ mentality by using risk-based and context-driven approaches to software testing. By strategically managing the execution of high-priority tests first, your team can understand what gives, when the schedule won’t.

2. Don’t Automate Everything

Test automation makes humans more efficient, not less essential

QA practitioners are technologists and, as technologists, should leverage as many tools and technologies available in the most efficient way possible. Test automation is one of those tools, but being held to meaningless outcomes like, “automation everything,” is not a strategic way to manage QA.

Instead: Think carefully about your team’s approach to test automation and ensure it’s speeding up development. Have a qualification process in place to strategically determine which tests should be automated. To do this effectively, define selection criteria for your team to use to determine a test’s fit for automation. When done well, test automation can take development and QA teams to the next level.

3. Don’t Have “QA-Only” Sprint Cycles

From designing new features to shipping code to production, there are many places throughout the development cycle where problems can crop up. Yet QA teams often stand apart from development teams. The further along in the development process issues are uncovered, the harder (and more expensive) they are to resolve.

ABC: Always Be Coupled… with Dev

: QEs should always be coupled with developers. By shifting left, QA teams can have a much larger impact on enabling development teams to ship high-quality code, faster. Additionally, shifting QA left makes it easier for developers to solve any issues that arise in their code — it’s much easier to fix something you worked on two days ago, rather than something you worked on several sprints ago.

4. Don’t Own all Software Testing

Developers should, and often do, own a standard amount of unit and integration testing. Product teams should, and often do, manage products with quality in mind. Yet, it’s common for QA teams to carry the load of the blame when buggy software gets into the hands of customers.

Everyone owns quality

: Make quality everyone’s responsibility. Set the entire company up for success by building a quality-driven culture. From Product and Engineering, who manage and build the product, to Revenue and Customers Success, who put products in the hands of customers and ensure a delightful experience, to Recruiting and People Ops, who hire and maintain talent pivotal to quality success. Everyone owns quality in one way or another.

5. Don’t Hide Information

Meet the potatoes! Meet with every person who contributes to software quality

Communication about the good (and the bad) is key to building and shipping software that delights customers. However, it can be challenging for fast-moving teams to keep the feedback process flowing smoothly, resulting in important information being hidden.

Instead: Turn implicit information into explicit information by building channels of communication and writing implicit information down. To do this, Melissa suggests having a flow like this:

  • Meet the Team: QEs should meet with everyone who contributes to product quality. This will vary company-to-company, but key players often include Product, Engineering, Design, and fellow QA team members.
  • Create the Dev Plan: Developers should give an overview of their plan.
  • Iterate the Dev Plan: Product and Engineering should prepare to be able to answer questions regarding their plan and make edits where appropriate. Additionally, they should be able to add more contextual information while discussions are happening.
  • Share the Testing Plan: Lastly, QEs should provide key players with an overview of what they are going to test.

Learn More About the 5 Don’ts of Software Testing

The key to software quality success is to regularly evaluate and iterate your QA strategy. We challenge you to take these 5 don’ts of software testing and evaluate your QA process against them. To learn more about how to innovate QA, listen to The Top 5 Don’ts of Software Testing.