• The seminal DevOps book, Gene Kim’s “The Phoenix Project,” was one year old;
• Gartner predicted that 25 percent of Global 2000 enterprises would adopt DevOps to some extent by 2016;
• “Continuous Testing” just started appearing in industry publications and conferences;
• Many of today’s popular test frameworks were brand new — or not yet released;
• The term “microservices” was just entering our lexicon;
• Only 30 percent of enterprise software testing was performed fully “in house.”

Times have changed — a lot. If the way you test hasn’t already transformed dramatically, it will soon. And the pace and scope of disruption will continue to escalate throughout the foreseeable future.

On the one hand, testing is all too often the roadblock that stands between highly accelerated Dev processes and highly automated ops-driven delivery processes. But on the other hand, testing is essential for ensuring that the release doesn’t place the business at risk — undermining the very “customer experience” that digital transformation is dedicating to enhancing.

How can you achieve the optimal balance between speed and risk to deliver engaging customer experiences faster than competitors? Enter Continuous Testing.

Continuous Testing is the process of executing automated tests as part of the software delivery pipeline in order to obtain feedback on the business risks associated with a software release as rapidly as possible.

Continuous Testing really boils down to providing the right feedback to the right stakeholder at the right time. For decades, testing was traditionally deferred until the end of the cycle. At that point, testers would provide all sorts of important feedback… but nobody really wanted to hear it then.  It was too late, and there was little the team could feasibly do, except delay the release. With Continuous Testing, the focus is on providing actionable feedback to people who really care about it and when they are truly prepared to act on it.

Contrary to popular belief, Continuous Testing can happen at any point in the application delivery lifecycle. At some point, the concept of Continuous Testing was inappropriately conflated with the trend of “Shift Left.” To deliver the right feedback to the right stakeholder at the right time, Continuous Testing needs to occur throughout the software delivery lifecycle — and even beyond that to production (e.g., monitoring information from production and feeding that back from the quality perspective).  Just as the name indicates, Continuous Testing involves testing continuously. Simply starting and finishing testing earlier is not, by definition, Continuous Testing.

Of course, testing continuously in a way that provides the right feedback to the right stakeholders at the right time is no easy feat. The short answer to why it’s so challenging is that the time available to test is constantly decreasing while the complexity of what we need to test is increasing. But it’s more than that. To better understand why “reinventing testing” is now so essential, let’s take a quick look at some of the core forces influencing modern application delivery.

This post is originally published here: 

The post Why You Must Reinvent Testing for Agile and DevOps appeared first on Read Dive.