Skip main navigation

New offer! Get 30% off one whole year of Unlimited learning. Subscribe for just £249.99 £174.99. New subscribers only T&Cs apply

Find out more

Testing Workflow

In this step, Sam Guckenheimer will discuss how the workflow of testing changes in DevOps environments
Testing workflow is something that changes dramatically in DevOps. In the old days, we would do testing after development and before production. Testing would act as a sort of quality gate on the movement of code to production. It still acts as a measure of quality, but it’s something that we do continuously in DevOps. Let’s look at the difference. So when you did testing after development, bugs would get caught late in the delivery cycle. Bugs in production were typically caught by users. The consequences of this are that manual regression tests expand. Testers are filing increasingly long bugs in order to create repro steps.
Testers find themselves arguing with developers, and developers find themselves merging code late long after they originally worked on it. So that you frequently have a rejection rate, or a failure feedback rate, or when developers think they make fixes, but don’t quite because of this miscommunication. And the whole process of testing slows down the delivery cadence. The bugs in turn often don’t get fixed, because they get deferred. People say, wait a minute. We don’t have time to do that, so we’re just going to push them off to a subsequent release.
And a symptom of all of this is that you hear, oh, if only we had better requirements, and the blame goes on to bad requirements when, in fact, the requirements are largely irrelevant. They’re not what’s delivered to the user. It’s the working software that the user touches. Let’s look at the alternative. When you test throughout the life cycle, bugs are caught early. They’re caught often the same day, even if they’re in a production environment. Testing and operations are collaborating closely with development, and the bugs aren’t caught by customers as much. They’re caught in advance, and they don’t recurs frequently. In turn, this creates an increased collaboration across development testing and operations, however many people are involved in this.
The validation of what’s going on in production encourages faster, smaller releases. Customers get faster delivery, and they love the faster cadence. And its customer approval, and acceptance, and usage that becomes the measure of quality, not some apriori guess at the requirements. It’s quality in the eyes of the customer.

Early and Timely Feedback

Automating testing from the very beginning of development provides developers with timely feedback that they can use to improve the application quality.

Speeds Up Software Delivery

Automated testing matches up the pace with continuous delivery cycles. It is not possible for manual testing to keep up the pace with the rapid release cycles in a DevOps organisation. Manual testing would be a bottleneck where time to market is critical. Automated testing comes with a much faster turnaround time.

Reduces Cost

Automated testing reduces cost significantly. Manual testing is an expensive exercise, and it could consume a large portion from the overall project budget, whereas the cost of automated testing is significantly lower.

Fundamental to Continuous Integration and Continuous Delivery Approach to DevOps

Automated unit tests that get fired at every build are wired into the continuous integration system.


Automated testing increases confidence toward releasing a reliable application to end-users in the fast-paced DevOps release framework.


You can write tests once and run them repeatedly with varying configurations.

Robust Testing Architecture

When you think ‘test early and test often’ using automated testing, you essentially build a robust testing architecture that helps produce higher-quality software.

Join the discussion

How do you currently test for changes? Do you see these options as an improvement in your process? Have you noticed the negative consequences associated with the process of testing after Development, before Production?
Use the discussion section below and let us know your thoughts. Once you’re happy with your contribution, click the Mark as complete button to check the step off, then you can move to the next step.
This article is from the free online

Microsoft Future Ready: Fundamentals of DevOps and Azure Pipeline

Created by
FutureLearn - Learning For Life

Reach your personal and professional goals

Unlock access to hundreds of expert online courses and degrees from top universities and educators to gain accredited qualifications and professional CV-building certificates.

Join over 18 million learners to launch, switch or build upon your career, all at your own pace, across a wide range of topic areas.

Start Learning now