Why test automation is a key component in DevOps delivery

By Des Walker

It’s wonderful to see automation being widely implemented in business and IT today. Often, we find that leaders are willing to spend time and effort on automating infrastructure (cloud and on-premise) or on building and deploying applications. But sadly a lot of businesses don’t prioritise test automation. Testing remains a much lower priority in a DevOps transformation than it should have.

We see a lot of organisations who can build and deploy their application in under 1 hour through pipeline automation, however their test cycles are still mainly manual, unreliable and time-consuming.

Let’s say that your business uses teams of people to test its software with a mixture of onshore and offshore resources. This often means executing hundreds or thousands of test cases manually, just to prove that the application works. By delivering successful test automation, we’ve seen teams of 20 or more testers reduce to teams of 2 or 3; representing a significant saving in cost. Although there is an investment in setting this up, we’ve seen huge tangible benefits to fully developing test automation.

When considering test automation, there are a number of different test types to be taken into account. We believe that all aspects of testing can and should be automated, the degree of automation depends on what the customer outcome needs to be.

Typically we see many organisations focus on functional or regression testing, i.e. can we be sure we have a working application? Non-functional testing is as crucial if not more so, whether it’s load testing or security testing, this can be automated. Unfortunately, many do not know where or how to start with non-functional automation, so many businesses don’t automate this part of the cycle, resulting in long, unreliable execution periods still run in a waterfall manner.

You can expect significantly faster delivery times with automation. Without it, we typically see test cycles of weeks or even months. With test automation in place, you can see the same results in a matter of hours. In one case, we saw a test cycle of 3 weeks drop to just 1 hour.

Test automation improves the quality of delivered software too, with a far lower cost to operations. Imagine you’re building a car. If a human builds and tests the car, mistakes were often made. Would you forget something on your checklist? Perhaps. By automating the testing, you mitigate the risk of human error.

Why organisations shouldn’t delay test automation

Organisations that don’t use test automation face a number of challenges. Expect long, unreliable test execution periods. Expect costs that continue to rise due to the ever-increasing size and complexity of an application, with missed project deadlines and increased bug rates.

Expect almost every major project or programme to drag on. Without automated testing, senior leaders often can’t fathom why projects aren’t delivered on time, why deadlines are so frequently missed. In these circumstances, we often find that organisations start to lose faith in their IT team with broken promises for deadlines.

Especially in retail, modern companies set themselves up to deliver change rapidly. These disruptive companies can alter their business in weeks leaving the more traditional organisations in their wake. But by automating testing, large retailers can develop innovative software to compete with and respond to these modern, more agile companies. We find our clients can get months’ worth of competitive advantage thanks to the impact of this single solution.  

Most organisations will have invested in great in-house developers. These people are talented, focused and ambitious. However, if they’re waiting around for test results and bugs to come back, and it takes months to turnaround their work, then morale will start to slip. Slow test cycles annoy good developers, slow productivity to a halt and risk colleague retention.

How we can help

At Daemon Solutions we have a great deal of experience in DevOps, we have implemented DevOps pipelines, including functional and non-functional test automation, at many of our enterprise customers.

In order to reduce the cost of testing, and the cost of remediation (bugs, performance issues) we believe in the shift left approach. This approach relies on getting your development groups involved in the creation of good quality unit tests. Unit testing should not only cover functional testing but also non-functional in the case of Performance Testing.

Implementation of performance unit testing, with the ability to test units of code against a performance baseline as part of the code build process, allows performance issues to be caught early. In addition to performance unit testing, we automate peak, soak and stress testing into delivery pipelines where appropriate.

From a functional perspective, it is crucial that after code commits we are able to run testing to verify the functional correctness of the code. This means automated execution of the functional testing assets created during the development process.

We look to ‘right size’ our DevOps and test automation solutions for our customers, identifying where the most benefit can be gained and where we can implement quick wins. For example, if a customer runs performance testing at the end of an agile sprint delaying deployment for weeks, this is where we can focus to bring benefit by implementing daily performance runs, perhaps overnight.

You’ll be able to deliver software faster, more reliably and with better and more trusted software. You can predict the delivery date and expect significant operational cost savings in the long term. At Daemon Solutions, we know how to deliver results for our clients. Let us help you adopt the perfect solution for your current challenge. Connect to me on LinkedIn to find out more.

If you enjoyed this blog, why not read our article on how company culture can impact on your IT operations and development? In our next blog, we’ll be examining how DevOps can transform legacy systems, and the remove the challenge of legacy infrastructure.

By Des Walker