Velocity, Meet Quality:
Why DevOps must define QA as Code
You’ve heard of pair programming and test-first development. You’ve heard of agile software development. You’ve heard of continuous integration, daily builds and continuous delivery. You’ve heard of infrastructure as code. These keystone practices make possible a DevOps culture of continuous (daily, weekly, monthly or regularly iterating) working software production.
All too often, however, velocity comes at a cost: quality. Sure, the nightly builds are working and the developer-defined unit tests are glowing green. The deployment environment has been hammered out and it’s easy to roll back to a known working version when a simple UX change turns out to have deeper implications.
But what happens with a distributed denial-of-service attack pummels your system, a gangster snatches the cached data and catalogs your application-level zero-day vulnerabilities for future sale on the dark Net? What happens when customers pan your app and your brand loses momentum? What happens when your inability to quickly deliver rock-solid functionality is widely speculated on in the media and you lose a critical round of funding?
The good news is, you have a team of quality superheroes in your organization, if you’ll only let them emerge. QA’s job is to bring a much-needed dose of reality into DevOps. QA doesn’t break software, QA breaks the illusion that your software works at each of these phases of the lifecycle:
- Development: unit, acceptance and sanity testing
- Continuous Integration: unit, acceptance, incremental intetration and database testing
- Quality Assurance environment: smoke, integration, functional, usability, compatibility, install/uninstall, regression, security/penetration and database testing
- Staging environment: performance, stress, load, soak, end-to-end, system, attack, penetration and privacy testing
Unfortunately, even as DevOps is speeding toward most organizations like an oncoming freight train, enterprises haven’t changed the way they do test and are still using the same mismatched tools of the last 20 years. The good news is, QA can use the DevOps focus on “automating all the things” to define a new keystone practice: QA as code. QA now has the ability to pull up any environment they want with the same ease developers and operations teams can.
QA can make transformational quality on top of consistent velocity a reality by automating tests, unifying test platforms and defining critical QA checkpoints as code. QA can redefine itself as a change agent, not a bottleneck (for inspiration, here’s how Google reimagined QA engineers).
QA as Code is the future
Code is sexy. And thus far, every piece of the lifecycle that has been redefined “as code”—in other words, with new standards of automation—has resulted in a renaissance of technology around that critical activity. We’ve seen it with versioning. We’ve seen it with development environments. We’ve seen it with testing, continuous integration and deployment.
It’s an oxymoron, but defining something as code actually means an explosion of productive exploration in how best to refine it into a repeatable, elegant process. It’s time for QA to enjoy the same artisanal reimagining we’ve seen in dev and ops, with a renewed respect for how QA will lead the quality revolution in DevOps, at a time when quality is more critical than ever.