How mobile app QA testing gets in the way of continuous delivery… and how to fix it

Continuous delivery (CD), and the broader DevOps movement, have radically accelerated the pace of software development. 

With a cultural shift in development practices and software life cycles, deployment architecture and infrastructure have changed. Teams can now deploy code iteratively and quickly. Gone are the days of measuring release cycles in months or weeks. Now, it’s days — and sometimes even hours or minutes. Simultaneously, the main driver of continuous delivery is how you start coding from ground zero. Each next line of code becomes immediately deployable. 

Put simply: thanks to continuous delivery and networked testing practices, it now takes less time to design, create, and implement new features.

How fast is fast?

Testlio’s benchmark data revealed that clients update their mobile apps an average of two to four times per month. This tempo contrasts starkly with how quality assurance teams have traditionally worked.

At its very core, QA is fundamentally centered around the two pillars of detail and requirements. Before, this historically manifested itself in meticulous code analysis to avoid potential bugs and security vulnerabilities, paired with arduous real-world testing, to ensure the final product meets standards. But in this brave new DevOps-powered world, processes that made sense in the heady (and, some might say, best forgotten) days of Waterfall feel obsolete when you can deploy a new release before lunch.

As a result, many QA teams now find themselves walking a tightrope, torn between potentially bogging down the new turbocharged release cycle, or being too “hands-off” and potentially undermining the user experience with glitchy, potentially insecure software.

There are two reasons why QA teams find themselves in that position. The first is cultural. When Waterfall was king, it was customary to regard QA testing as an island amidst the broader software development archipelago – independent of other departments and roles. But organizations must be able to function as a whole, which means setting aside conflicting agendas and working for the common good.

And the second reason is technical. There is less time to verify issues between code being committed and deployed. Quality engineering processes must keep up and adapt to ensure faster turnaround times. Because continuous delivery requires getting all changes – new features, configuration changes, bug fixes, etc. – shipped to users safely and quickly in a sustainable way, the burden falls on QA teams to evolve their processes. They must adapt to the new way where code is always in a deployable state. And any evolution should focus on culture before technology.

This is precisely where DevOps shines – creating and accelerating scalable app development processes where testers work hand-in-glove with developers through all software development actions. 

The analytical and detail-oriented mindset of a tester can prove invaluable when conceiving requirements and specifications. It allows them to identify potential edge-cases that otherwise might fall through the cracks of automated unit and integration tests.

And this should be accompanied by technological evolution. DevOps is not the death knell of QA, as many have feared (and, indeed, predicted). It has, however, radically changed the nature of the job. QA testers face a choice: adapt or perish.

Related: How the right type of QA testing delivers on your need for speed

What does that mean for QA teams?

In practice, this means learning how to apply their existing competencies to the highly-automated CD workflows, thereby affirming the role of testing at the heart of any deployment process.

Platforms like Jenkins and GitHub Actions make it easy to integrate your old processes — like static code analysis, unit testing, and integration testing — into the development workflow without introducing the blockages and bottlenecks found in older software methodologies. Learning how to use them is, therefore, critical.

And even with this emphasis on automation, there’s still room for the soft skills that have long made QA testers an invaluable asset. Indeed, automation has arguably empowered QA teams to spend more time performing the creativity-driven tasks that ultimately produces better, more polished software.

Exploratory testing and networked testing approaches remain an essential tool in the quest to find software defects that would otherwise evade automated unit and integration tests, which, by definition, have a narrow focus. And crucially, exploratory testing can exist without necessarily acting as a bottleneck to developers or DevOps engineers, because testers can apply their domain knowledge, experience, and skills to explore the functionality of an app and uncover issues. Furthermore, for CI/CD approaches, networked testing can hook seamlessly into DevOps processes, ensuring the completion of unit, visual, functional, and other tests.

Another skill inherent in the QA mindset is the ability to document, reproduce, and prioritize errors before communicating them to development teams for resolution. This capacity isn’t easily replaced by machines — and will likely remain the case for several years. A reliable QA team can help accelerate the speed of deployments. By using their expert domain knowledge and integrating the teams more closely together, companies can realize the advantages of all the changes made in CD and the overarching DevOps ecosystem. 

If you’re looking for a partner to help streamline your business’s DevOps practices and priorities, contact Testlio for a demo.