Building innovative software faster and better is imperative to an organization’s success, so it makes sense to take advantage of DevOps. But what some teams fail to consider is that testing is a crucial part of the process. Without a “test early and often” mentality, DevOps would only be able to release software faster—not better.
Software technology is both a blessing and a curse for today’s organizations. While continuous improvement and delivery have increased the rate at which software solutions can turn into a company’s next big win, it also has lowered the barrier of entry for competitors to provide faster, cheaper, or better alternatives. Many organizations have had to change their software development practices to adjust to this new, aggressive landscape.
Agile development accelerates the rate of change, which in turn requires better processes for release and deployment. DevOps has stepped up to enable accelerated change, so the speed at which DevOps organizations can build innovative solutions becomes a critical factor of success. This ultimately begs the question, How fast can DevOps organizations innovate?
Surprisingly, the answer is fairly straightforward: as fast as the testing practices can move, while still minimizing the risk of any build moving into production.
That’s right—testing is a crucial part of DevOps. Keep reading …
Continuous Delivery, Quality, and Speed
Continuous delivery is one of the major pillars of any DevOps organization. I particularly like the Wikipedia definition of the term:
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. It aims at building, testing, and releasing software faster and more frequently.
Ensuring that the software can be reliably released at any time is a goal in every IT organization. It doesn’t matter how quickly your development team can adjust the code and spin out builds based on unit test results, or how fast your operations team can deploy the build into production; if it comes at the cost of breaking something that currently works, it’s no good.
Whether you’re responsible for building, testing, or releasing software, there is no way to ensure that software can be reliably released at any time without testing, from both functional and nonfunctional perspectives. Testing practices need to be automated and pervasive throughout the entire software and systems lifecycle, leading to what many quality professionals now call continuous testing. Unit testing and functional regression testing are a great start, but the demands of accelerated development require more comprehensive approaches that incorporate performance, load, and API testing as part of the daily testing activities..
Raising the bar on testing methodology is fundamental, but managing our human capital is a must.
Testers Should Be Embedded in the DevOps Team
First, I want to clarify that in my opinion, DevOps teams are composed of anyone involved in building, testing, and releasing an application. No, you don’t see any indication of testing in the name DevOps—but that’s because DevOps implies that testing is a part of development.
There can be multiple excuses for not embedding testers into the development teams, but the only acceptable excuse is compliance issues. At times there may be an external factor (normally legal-related) that forces segregated testing teams. But outside of legal ramifications, testing teams need to be included within development teams.
Having testers embedded in your development teams, even if they’re not collocated, will increase your team’s ability to evaluate the story’s acceptance criteria, clearly define the best test strategy to achieve that criteria, design test assets that deliver proper coverage, objectively evaluate test results … the advantages go on.
In other words, having testers working directly with your developers will fuel a “test early and often” mentality, making your DevOps teams much more thorough. It will also deliver a better sense of what it truly takes to reliably implement any change or new feature.
The Kind of Testing DevOps Requires
The Theory of Constraints involves identifying the primary factor holding your project back from achieving a goal, then improving that factor until it is no longer a problem. In most projects, the factor manifests as a bottleneck in the workflow.
Manual testing is still used in efforts like exploratory testing, but trying to support the fast-paced feedback loop required by DevOps and continuous delivery with manual testing is practically impossible. It would represent such a big bottleneck that the idea is effectively eliminated right off the bat.
Today’s digital world requires applications to be delivered on an ever-increasing variety of smartphones, tablets, laptops, and wearables, all running different operating systems and browsers. Implementing test automation tools combined with a clear understanding of user experience across configurations is the only way to eliminate any bottlenecks and deliver faster, more reliable builds.
I don’t want to minimize the importance of development and operations practices and tools in the success of DevOps adoption, but in my opinion, testing should be the heartbeat of any DevOps organization. DevOps enables agile development, and testing enables DevOps. Without the thoroughness of a “test early and often” mentality and the speed achieved by proper planning and automation, DevOps adoption would not be able to claim its goal of delivering better applications, faster.
