Should Developers Own Quality? The Pros and Cons of Developer Testing
Edward Paulet, Software Engineer at Rainforest, recently sat down with Robert Miller, Success Engineer at Guru, to discuss a trending topic in the agile development and quality world: Should Developers Own Quality? Here a few takeaways from their discussion along with two case studies of what developer testing looks like in organizational practice.
A New Model for QA Ownership: Developer-Driven QA
Quality assurance is the gateway to successful continuous delivery. Traditionally, a dedicated testing team owns quality. But as QA cycles grow shorter alongside the industry’s shift to continuous integration and delivery models, QA teams are shifting too. In today’s landscape we’re seeing two types of quality ownership:
Quality Owner: QA Team
Quality Owner: Dev Team
But what does developer-owned quality look like in practice, and how does a software development team do QA without a QA team? Here’s how Rainforest and Guru uniquely approach developer testing:
Rainforest Case Study 1: Quality at Rainforest – Multiple Developer Quality Owners
Test writing is a natural extension of development.
-Edward Paulet, Software Developer at Rainforest QA
Every Rainforest software developer is a quality owner, meaning they write, execute, and maintain tests for the code they produce. This multi-owner approach to developer-owned QA serves Rainforest’s release goals and encourages everyone on the team to be engaged in delivering high-quality products to customer quickly.
The QA process at Rainforest is a collaborative effort between frontend and backend development teams: Frontend developers own testing the user flows using Rainforest, while backend developers own testing the API and maintaining pre-seeded test data.
Without a dedicated QA team, there’s no dedicated QA step in the development process, so quality testing is integrated into the workflow. Developers are responsible for writing tests and maintaining them with the support of the product team. By collaborating on quality at every stage of the development process, Rainforest’s product and engineering teams work together to ensure features meet team and customer requirements.
Rainforest Case Study 2: Quality at Guru – Single Designated Developer-Quality Owner
QA can be the bane of development teams who don’t have a dedicated QA team. That’s not the case with Guru, where Success Engineer Rob Miller has optimized Rainforest for efficient developer-owned testing. In the webinar, Rob discussed how he developed a process to integrate Rainforest as directly as possible into his team’s workflow:
– Rob Miller, Success Engineer at Guru
By using RFML files and Rainforest’s CLI Rob avoids repeating steps in different areas that require the same action. This reduces the amount of time he spends writing and maintaining Rainforest tests and increases his capacity to work on production support and feature development.
The biggest benefit of using RFML files with Rainforest’s CLI is having the ability to search all text in every Rainforest test, making it quick and easy to find the location of the broken code to fix it. The Guru team also gets version control and pull request benefits by having these files in GitHub.
DevX: RFML File Generated for the Test
Ensuring stellar code quality is a priority for Rob. But achieve this goal while maintaining a small, focused development team is also critical for Guru. As a result of using Rainforest’s developer features to build a more efficient QA workflow, Guru has recovered over 100 hours of developer time each month from manual testing.
Learn About the Pros and Cons of Developer-Owned Quality
Rob and Edward agree that developer-owned testing saves an enormous amount of time in the workflow. But, developer resources are overextended and expensive. Time spent on developer-owned QA is time taken from developing new product features. To learn more about the pros and cons of developer-owned quality listen on-demand to Should Developers Own Quality? Pros and Cons of Developer Testing.