Automation insights and productivity tips from LEAPWORK.

All Posts

DevOps Automation: 5 Steps Towards Continuous Delivery

Automation is a prerequisite for success with DevOps. Especially, test automation is a key ingredient when it comes to providing fast and accurate feedback to testers and developers which, in turn, enables quick reactions to errors, bugs, and changing requirements.

In one of our previous blog posts, we explained how to build a continuous integration / continuous delivery pipeline in a DevOps environment. However, the ultimate success of your delivery pipeline will depend on your automation execution.

READ: How to Create a DevOps CI/CD Pipeline (With Example)

In the graphic below, all stages and gates of the release pipeline are color-coded so that it’s easier to identify and understand the flows and checks of the process. Depending on the software and compliance requirements, stages – or environments – might be added or removed from the pipeline, either permanently or by demand.

Furthermore, the gates represent a set of requirements that must be met for a build (a piece of code) to pass to the next stage, or environment, of the pipeline.

CD release pipeline DevOps

The effectiveness of a CD release pipeline depends on how fast the results of the Red and Blue Gate checks can provide feedback to relevant stakeholders. For example, if a unit test fails in Development, the developer who did the check-in should be notified immediately by an email alert. Another example, if the automated UI tests in Test fail, an alert could appear on a dashboard monitored by the team responsible.

The faster the feedback mechanism, the more likely it is to find a quick solution to the given issue. If a developer is notified weeks after error detection in a checked-in piece of code, he or she has most likely moved on to other tasks and projects, and the context and relevant requirements of the given code are not on top of his or her mind. The developer would have to spend time readjusting to the right context, resulting in significant productivity loss.

The answer to how to speed up the feedback mechanism in the release pipeline is automation. Ideally, all the automation needs of the product delivery process should be manageable by using one tool that enhances the work of all the roles involved in the pipeline; from testers to product and business owners.

With the LEAPWORK Automation Platform as an example, what follows is a walkthrough of five junctures in the release cycle where automation can be implemented.


The primary area of automated testing is regression testing. This helps ensure that changes to a product base are not creating bugs in the existing product. Regression testing usually takes place in the Test environment.

By relying on LEAPWORK, and without having to having a write a single line of code, the test team can automate and maintain the test cases required for passing the Blue Gate. The cases can run on a schedule, i.e. every night, repeatedly 24/7, or on an ad hoc basis.

The LEAPWORK Automation Platform comes with native plugins to the common build and release services such as Jenkins, TFS, Atlassian Bamboo, and TeamCity. 

This makes it very easy to trigger test cases to run as part of a release plan. Furthermore, LEAPWORK returns all test case results in JUnit format, which is natively supported by all platforms, enabling an overview of all test cases directly via any release platform an organization is using.

It is very useful to have individual test cases as a part of more than one schedule. This way, it is possible to test minor parts of the products often while having a schedule containing regression tests of all product features, which is then executed, for example, every night or close to a release.

As mentioned, automation is meant for making feedback instantly available. After test execution, all case results are available in the LEAPWORK Automation Platform, and it is possible to filter them by projects, schedules, and more. The results can also be emailed to designated stakeholders depending on the case outcome. Finally, test results can be automatically pushed to whichever bug management system is used (TFS, Jira, HP Quality Center, etc.).


Running regression tests against the Development environment serves two purposes:

  • Making sure that the build is testable, that is, ensuring that it makes sense to push to Test.
  • Providing feedback to developers about whether the Development environment is reliable; if the code works here it can be assumed that it also works in Test and Production.

Early regression testing only covers a small part of the total regression tests available, for two reasons. Firstly, because there is a higher frequency of deployment, or check-ins of code, to Development, there is an upper limit to the number of early regression tests that can be executed per day. Secondly, verification at this stage is usually kept at a limited number of basic test cases focusing on critical features.

The schedules for early regression testing are usually triggered as part of the same processes that generate the build and deploys the code to the Development server. This is easily done with LEAPWORK’s scheduling capabilities.


The third type of regression testing that is easily automated with LEAPWORK is feature verification on the individual developer’s local installation. With LEAPWORK, teams of testers, developers, and DevOps professionals can share and collaborate on test cases, and everyone can run them on their individual PCs if needed. The results of local runs provide valuable feedback to the entire team.


“Errors will occur.” This is a well-known and accepted truth in software production. So, during a release cycle, it is never a question of ”if errors will occur”, but rather how the organization will react on them. Enter the discipline of smoke testing. This is about running automated test cases against the Production environment to ensure that the software indeed runs as intended.

Tests done at this stage are the closest thing to real user interaction. An example of a test case could be to perform a user login to a web application and then validate the login.

The test cases used in smoke testing are solely used for this purpose. The outcomes of the tests are not allowed to dictate any drastic changes to the product. Smoke tests should be able to run both frequently and quickly, and they should not be allowed to push the production system to its limits.


Whenever the owner of the system under test—the product/business owner—must configure and set up the system for end-users, the LEAPWORK Automation Platform can be used for ensuring the validity of the system from a business perspective.

The short learning curve of the LEAPWORK Automation Platform and its flowchart-based approach to automation makes it an ideal tool for business owners, managers, and non-technical specialists. These people in an organization would be able to design and execute their own automation cases to monitor that the business-critical aspects of the product work, such as a sign-up flow to a subscription service.

READ: How to Automate Functional UI Tests in a DevOps World

Download Whitepaper: DevOps and Test Automation

Do you want to learn more about how to ensure rapid feedback across the CI/CD pipeline through shared automation ownership? Then download the whitepaper:

Download Whitepaper: DevOps and Test Automation
Lucia Cavero-Baptista
Lucia Cavero-Baptista
Content Marketing Manager

Related Posts

Test Automation and RPA Tools: What's the Difference?

If you’re using test automation and recently began looking into RPA, or if you are new to test automation but using RPA as a means to achieve efficient operations, you might at some point have wondered what the difference is between the two often interchanged terms, as well as if you can use the same tool for both.

[WHITEPAPER] Automating Workday® with LEAPWORK

An increasing number of companies are seeing the benefits of RPA in Workday®. Unfortunately, developing RPA functions is costly and time-consuming, requiring new personnel with specialized and expensive skills. So how can a company get the most out of automation without incurring massive implementation and maintenance costs?

Data-Driven Testing With Codeless Selenium

Data is found everywhere. Whether you are testing an application’s functionality with different data parameters or automating the process of moving data from A to B, you have probably realized by now that data is found to be a key component in most automation cases.