You are here

The future of DevOps-driven software delivery will be very different from our past experience building and deploying software. One key difference is that the idea of managing, tracking, and releasing software with defects will become more and more rare.

How DevOps can put known defects on the endangered species list

public://pictures/John-Jeremiah-Technology-Evangeslist-HP.png
John Jeremiah, Evangelist, GitLab

It seems like QA professionals love defects, just as everyone loved Cecil the lion. Software development organizations have large teams of people dedicated to search for, document, store, track, and manage defects. Given all this attention, you'd think defects were prized jewels. Indeed, testers are proud of their ability to break software and find defects.

When it comes to DevOps, however, QA professionals need to consider defects in a different light. A DevOps process leads to higher quality and fewer defects, especially known defects. These are defects that, for one reason or another, the team has decided not to fix but to release into production. It's a form of technical debt that's rarely ever repaid.

The DevOps difference

If your DevOps team is doing continuous integration, they check in code and build frequently. Following this approach, they're making smaller code changes more frequently, rather than large changes less frequently.

They're also continuously testing, using automated tests to evaluate every code change and ensure that their code passes all the tests and keeps the build "green" (defect free). They're committed to keeping the build green so that when tests fail, they have two choices: either quickly fix the problem to pass the tests, or roll back their changes from the build and go back to their dev environment and fix the problems.

By using continuous delivery and treating infrastructure as code, they ensure that any time the infrastructure changes, the change is updated throughout the delivery environment. This eliminates the "it works on my machine" refrain.

Through continuous assessment of the application and delivery processes, software engineers get rich and actionable feedback to ensure that their apps deliver business value and that they can improve their own delivery speed and quality.

In the book, Continuous Delivery, Jez Humble and David Farley describe how quality is different in a DevOps team:

Ideally, bugs should never be introduced into your application in the first place. If you are practicing test-driven development and continuous integration and have a comprehensive set of automated tests...developers should be able to catch bugs before they are discovered by testers or users. High quality software is only possible if testing becomes the responsibility of everybody involved in delivering software and is practiced right from the beginning of the project throughout its life.

So, if you're doing DevOps and you've been doing it for a while, things will be different, probably very different.

  • Changes and releases will be much smaller than before.
  • All changes will go through extensive automated testing before ever reaching production.
  • When tests fail, the bug will get fixed—not saved, tracked, managed, and then hopefully fixed—just fixed. The DevOps team owns its changes and releases, so no more "over the wall" hand offs to Ops. Instead, the team will be monitoring and supporting much more of their application than they do today.
  • When things go wrong, the team will prioritize production bug fixes based on impact to end users, and the team will have two objectives, not one. The first is to recover from the problem and quickly get things working again. The second is to look at the root cause and learn how to prevent future problems through new tests, improved automation, better collaboration, or other changes.

The end of defects?

As a result, you can expect to see a significant decline in known defects. Since the development team is keeping the build green, fixing bugs rather than allowing them to continue on in the build, you'll have fewer and fewer known problems in the system. This is the goal of "shift left"—to find and fix bugs early.

It's up to you to help make known defects an endangered species. The sooner you can find a bug after it's introduced, the easier it is to fix. This is the power of DevOps and continuous integration, testing, delivery, and assessment. By shortening the cycle time between bug creation and bug discovery, you enable the developer to quickly fix, rebuild, and retest—an always-ready-to-release application.

A new day for QA

But what does this mean for thousands of testers and QA professionals? Is their livelihood also endangered?

Absolutely not. In a DevOps organization, those skills are more important than ever. As part of the team, you help design and create automated testing to ensure that each build is thoroughly tested and of high quality. You won't spend your time managing and tracking defects, and you won't have to apologize to users about having to live with them.