In today’s agile age, Continuous Delivery is not only a great concept but an increasingly critical one. This discipline, which facilitates the release of software to production at any time, supports agile practices and can cut the time-to-release of websites and apps from several weeks to just a few hours.
However, it could be argued that the industry hasn’t closed the circle yet when it comes to realizing a full Continuous Delivery Process.
Continuous Integration (CI) gave us the first part. CI methodologies are already very popular, with many IT organizations incorporating it into their daily working practices. CI involves integrating code into a shared repository and verifying each check-in with an automated build, enabling us to detect, locate and solve problems much quicker - and at a fraction of the cost.
Hot on the heels of Continuous Integration came Continuous Deployment - the deployment or release of code to production as soon as its ready, ensuring your releases go to market as quickly as possible. And so the second piece of the Continuous Delivery puzzle fell into place.
But, to date, there’s been a vital piece missing. And that’s why it’s now time for the next paradigm changing methodology to make its mark on our online forums and the lives of DevOps teams everywhere.
Continuous Testing: Continuous Delivery’s Missing Link
What is Continuous Testing?
Up to now, testing has been slow to catch up with other agile methodologies.
If you run your testing late in the software development process, you risk discovering problems at a very late stage. At best, this is a huge and complicated headache. At worst, it’s a total game changer, forcing you to go back to the drawing board at the last minute.
Even for developers who run testing early with manual test executions, it can be incredibly time consuming and problematic. They need to run tests after each phase of the cycle - after writing the test, after producing the code and after refactoring the code.
On top of that, as software ages, you need to test much more often to ensure its quality. But most companies are working with limited resources and without much time to execute these tests. This gives you an unappealing choice: either risk compromising on quality or compromise on time. Neither of these options fit nicely within a smooth Continuous Delivery process.
Continuous Testing means you don’t need to compromise. You can automate your testing and integrate it into the build process as early as possible. A continuous testing platform runs in the background, automatically executing the tests and ensuring that issues are identified almost immediately. Thus reducing the time-to-release and closing the circle to ensure a successful Continuous Delivery process.
Key benefits of this technique include:
Finding Issues Earlier in the SDLC. Issues can be found and fixed quicker because developers can QA their own code.
Faster Release Cycles. Automated testing saves a huge amount of time. QA is now part of the build - not something done manually after its pushed to a QA environment.
Improved Code Quality. You can test EVERYTHING on every build.
Minimal Time Wasted
Less Risk. You KNOW your code is good with every build.
Continuous Testing is only going to become more essential as time goes on and technology continues to evolve. Just take a look at modern applications like mobile apps or wearables. They all have a backend and several front ends. This means that, at any point in time, you need to be able to test APIs, regressions, the performance and UIs on various operating systems and devices. To effectively manage this, fully automated testing is a must.
But, as I hope I’ve shown in this article, Continuous Testing is more than just automation. It’s the final step in the Continuous Delivery Process, augmenting software quality processes and ensuring speed, agility and risk management.
A true agile process must be 100% automated. And I believe it will be inherent to the Continuous Delivery Process in 2015 and over the coming years.
For a detailed look at continuous testing, which includes a checklist of requirements, check out the continuous testing whitepaper.
This post was written in May 2015, and updated for accuracy in March 2019.
You might also find these useful:
Interested in writing for our Blog? Send us a pitch!