DevOps Without Test....Isn't DevOps

Even after a couple of years, the number one topic in development seems to be DevOps. Most of those discussions seem to revolve either around whether its "a cultural thing" or a "tool thing". I believe it is both, but what I really want to talk about is that it is also a "test thing".

Early on in my exploration of DevOps, I noticed that one of the primary benefits of the cultural side was that it was finally bringing Ops into the room, just as we brought QA into the room in the early days of Agile. I mentioned that to a client once, and they looked at me kinda funny. Turns out, QA isn't really as in the room as I thought, even today. Now I don't think a single blog post is going to fix that, but let's at least explore a few areas where we can begin to change that. Let's also look at the vital need for test, especially automated, in the DevOps world.

To begin with, what does DevOps mean? If you ask 5 professionals this question, you will likely get 7 answers. For this post, I will describe DevOps as the art and practice of developing software in such a way as to be continuously adding value in production. We will use tools and practices that enable this, such as Continuous Integration and Continuous Delivery. We will also write code in such a way as to enable the best monitoring of health and performance, since we are all responsible for keeping the software alive now, not just tossing it over the wall.

There are stories of teams that deliver software to production many times a day. Other teams merely deliver to some sort of stage environment that frequently, because for one reason or another such a rapid upgrade path might be disconcerting. Such a breakneck pace sounds scary to many, and indeed it probably is scary if we approach development in the old way of building something then handing it off to "QA" to be tested When Its Ready.

Such an approach would not just be impractical, it would be irresponsible. If we just emphasize speed, we will be tempted to cut corners on test, which we have seen many times, to quote Iron Man, is historically not awesome. So we are at an impasse. We can't deliver high quality software without QA, and we can't deliver exceptionally frequently if we have to do all of our testing manually.

The answer is to automate as much as possible. There are excellent tools for automating tests, the most commonly used being the different variants of Cucumber. Couple that with a good UI driver like Selenium and you have a powerful ability to automate all of the tests that confirm the software is doing what you intended, and isn't getting broken with subsequent check ins. Approach automation as everyone's responsibility, not just part of a separate team. Incorporate those tests into your CI/CD environment, so we have the assurance that every check in can potentially be the next release, should it be needed. As I stated before, doing anything less, in a DevOps environment, would be irresponsible.

This does not eliminate the need for strong, creative testers who can do the exploratory testing that we all know is the best part of testing. It frees those people up to do that testing, and it frees programmers up to be innovative, because we always have a foundation of safety that is our automated unit and acceptance tests.

Rocky Mountain Programmers Guild is offering workshop sessions that specifically target automation and the skills to make it successful. See our upcoming sessions here: www.rmprogrammers.com/automate-series