What Is Continuous Delivery Doing to Software Testing?
Most of the conversations I’ve heard about testing over the past few years are related to its death. (Or supposed death.) Some people go as far as saying that having a tester role is an antipattern for software development—something that points to organizational dysfunction.
Software teams using continuous delivery focus on building software in small pieces so that new code can be pushed to production multiple times a day instead of on a sprint cadence. There is also an explicit focus on code quality before production and on monitoring afterward.
So, what is this doing to testing?
The biggest effect I see in the continuous delivery and DevOps revolutions is the shift of testers into programming roles.
Most agile shops have a release cadence. Every two weeks, the development team is expected to ship a batch of new software to customers. And for many, this cadence looks a lot like a compressed waterfall: a few days for discussing the changes, a few days for development, and a few days for testing and bug fixing. Maybe this isn’t “true” agile, and maybe it is agile done poorly, but it is what I see most often.
Continuous delivery takes that idea to its logical conclusion. Rather than delivering full features, developers break them up into very small changes that can be developed, tested, and delivered all in one go, usually by a pair of programmers as opposed to a single person. Instead of having a tester at the end of the release cycle, pairs focus heavily on quality by building layers of automation in the form of test-driven and behavior-driven development. These tests are checked in along with the code change so that anyone making changes on that piece of code in the future can benefit.
You probably noticed that I didn’t mention a tester anywhere in between development and production. Testing still happens, but it is done closer to the code, and by programmers instead of testing experts. Companies that do continuous deployment usually employ very few testers, but they are highly skilled and fill a coaching and teaching role. They alternate between pairing with developers and helping with test design, teaching people how to explore, and acting as test consultants.
After code is shipped to production, monitoring systems report on errors, system resource issues, and abnormalities that might point to a software problem. Continuous delivery emphasizes reducing the size of problems and removing them from production quickly over deep quality understanding before production. In continuous delivery, expediency is valued over depth.
If you’re worried about the testing role becoming endangered, don’t. Agile has been around for a long time now, and most people can’t seem to get that right. The people doing continuous delivery are outliers.
The testing role will change over time, but I don’t think it is going anywhere.
