FacebookInstagramLinkedInTwitterYouTubeFacebookInstagramLinkedInTwitterYouTube
skip to Main Content

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

Looks Like:

  • A team of dedicated testers manage and maintain all tests for code towards the end of the development workflow.
Looks Like:

  • Software developers write, execute, and maintain tests for all of their code in the development workflow.

Benefits:

  • Shifting left: Quality teams are testing earlier in the development cycle.  
  • More Collaboration: QA teams are increasing collaboration with developers and product at each stage of the development cycle.

Benefits:

  • Removing Workflow Bottlenecks: Since developers are responsible for testing their own software, the entire workflow is shortened.
  • More Collaboration: Developer-owned testing means development and product work closely together on quality and CD goals.

 

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 DevX:

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:

I came up with a way to write tests as JavaScript code, covert them to RFML files, then upload them to Rainforest using their CLI.

– 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: Writing Tests Using JavaScript

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.