As more teams shift to continuous delivery, QA cycles are getting shorter and QA teams are getting smaller. For some organizations (including here at Rainforest), opting not to build a dedicated QA team at all is an option that’s been growing in popularity. But how do you do QA -- and keep quality high -- if there’s no QA team?
Rainforest CIO Derek Choy recently sat down with two members of his team, Senior Engineering Manager Jonathan Barber and Software Engineer Siobhan O’Donovan, to discuss how the Rainforest team approaches QA testing. During the session they discussed how quality factors into each of their day-to-day roles and professional goals, as well as the overall benefits of their streamlined approach to testing.
Here are three of the key takeaways from Derek, Siobhan and Jonathan’s conversation about how Rainforest does QA without a QA team.
In the absence of a dedicated testing team, the development team must work very closely with the product team to ensure that quality stays high. With no “safety net” of a QA within the organization to catch issues before they launch, ensuring that features meet both the team and customer standards requires continuous collaboration throughout development.
As the Rainforest team has grown, test writing responsibilities have shifted within the organization. “Test writing is somewhat divided at Rainforest. Traditionally we didn’t have a product team, so engineers were responsible for writing tests. At the moment, we’re working with the product team to define what flows they want tested, since they know what flows are the most important to test.”
With no dedicated QA stage, quality must be integrated into the development process. At Rainforest, the onus lies on the developer to fix any issues associated with their code, as well as the responsibility to maintain test cases. As a result, functional tests are treated much like unit tests, in that they are updated alongside code on an ongoing basis.
“Whether it’s a new feature or an addition to an existing feature, the developer is responsible for updating that specific part of the test, or writing a new test -- with consultation from the product team. That gives us the confidence that we have a targeted test that addresses exactly the change that we made,” says Siobhan O’Donovan.
The Rainforest team uses our own QA testing solution -- integrated with a CI server -- to execute these tests. By using the Rainforest platform, developers are able to own the management and results of testing, without spending time manually executing tests or managing automation scripts. The benefits offloading execution in this way impacts the overall efficiency and success of the organization. Developers can spend more time on feature development and improvement, bugs are shipped less frequently, and quality and speed become less of a tradeoff.
Siobhan noted that this streamlined approach helps the Rainforest team be more focused and attentive to customer requests and needs. Derek added, “That’s very important to building confidence with our customers. We want them to recognize that our application is something that they can depend on, and even if there is an issue we will fix it -- hopefully before they even notice.”
Derek, Siobhan, and Jonathan speak about much more than the points covered here. Listen to the webinar on-demand to hear their thoughts on how Rainforest’s approach differs from traditional organizations, how other teams can optimize their QA process to fit development workflows, and more.
A comprehensive overview of DOM-based automation's limitations, and why UI testing may be superior for most testing use cases.
The landscape of software testing is changing. Speed and quality are no longer seen as opposing forces.
Software development and QA practices are at the heart of the show Westworld. Check out the five lessons real QA teams can learn from the programming team at Delos, Inc.
Rainforest CTO, Russ Smith, discussed testing and troubleshooting mobile application with AWS Device Farm at AWS re:Invent this year.. Watch the full video here.