Request info

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. 

How fast is fast?

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.

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.

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. 

Jumbotron image