Demystifying DevOps: A Day in the Life of a DevOps Tester
The idea of working as a test specialist on a team using DevOps can feel intimidating. There are at least two technology stacks, containerization and continuous integration, that you need to be familiar with. Add a source code repository like Git, a few test frameworks, and a scripting language to bundle everything together, and you start to approach a useful skill set.
My experience has been that very few people need to be able to start from scratch. Here is what a normal day of testing in DevOps looks like for me.
My current team follows pairing and Extreme Programming practices. For every code change, there are two developers and one test specialist. Most of the time, we start a change request by building a new test. This might be in RSpec or through Cucumber. Either a developer or a test specialist will write the test, and then a developer will write code to make that test pass. This helps us to understand the code we are writing, to refactor with less worry, and to know when we are done.
Throughout this red, green, refactor process, we are building new environments locally. One of us will push a change, and I might pull those changes and build a local environment.
The containers come in when we are closer to a usable version of the change. Many of the DevOps stories I read involve using commands I can never remember in workflows that feel archaic. I am able to do everything through our continuous integration system.
First I use a drop list to select the branch I want to use to build a new container. Building the container takes about five minutes. After my container is built, I select which environment to deploy to. After a few more minutes, I have a production-like environment available to explore and perform test ideas that are more complex than the programmatic testing we do during the development flow.
Pairing and having a test specialist removes most of the easy-to-find bugs that normal development leaves for the testing role. Generally I will still find problems related to the unpredictable way customers can use the product. I demo these bugs, then we make a decision as a group about whether they matter. Deciding to make a fix puts us back in the red, green, refactor cycle.
Over the course of a feature change, I might make one container, or I might make several. But it is very easy, taking somewhere around seven minutes each time I need to create a new environment from scratch. Once we feel like we are in a deliverable state, we create one last container environment in a branch merged with the head branch and demo to our product owner. That demo includes a discussion of any lingering things we decided not to fix so we can get some fresh perspective on them.
Testing in DevOps can feel scary, but like most things, once you get in a day-to-day groove, it becomes an indispensable part of your workflow.
