As brownie sundaes are a really important topic I am going to wax eloquently on my recipe for a perfect brownie sundae:
At this point in time you must be wondering what this has to do with CI/CD? Well here is the thing. CI/CD is like the brownie. The entire toolchain that you setup, whether you are using Jenkins, Bamboo or some other platform, and the effort that the development team takes to put the software into modules that can be built and deployed is the brownie!
But you still need the ice cream and that basically boils down to the validation that you can carry out as a part of the CI/CD tool chain. There are a couple of methods that can be used to create validation suites. Taking the analogy a bit further – should you use chocolate or vanilla ice cream or better yet BOTH? No, I have never had chocolate and vanilla in the same brownie sundae …you can only take an analogy so far! But it makes sense to use unit testing and system testing in your CI/CD validation.
From the start unit tests have been considered as a crucial part of a CI/CD implementation. However, the question quickly arose as to whether unit testing was sufficient for continuous deployment, especially all the way to production? Could it cover all type of validation especially for web-based systems? Much of the industry has moved towards using both. For example, this article from Infoworld (by author Isaac Sacolick) delves into using continuous testing after deployment and using system automation tests to perform regressions in addition to unit tests that are created by the developer. The article suggests going even further by integrating performance and security tests into the CI/CD chain.
CI/CD chains have slowly started incorporating system tests into their suites. There are a number of reasons why system tests were not there from the beginning in CI/CD systems. These are:
As early as possible! Following shift left (as outlined in this article by Forbes author Adrian Bridgewater) principles the goal is to test as early as humanly possible. Ideally when the developer first checks in their code, even before an integration test, they should be able to get a high degree of validation from their unit test and system test executions.
The key is that it should be easy and quick. A typical development life cycle starts off with low effort on quality in the initial stages of development and typically ends with very high focus on quality at the end of the development stage. As the figure above shows, starting to test early and often is key to reducing defects found downstream in production or even worse by customers.
For a developer’s productivity not to be impacted the CI/CD execution in totality needs to be fast. Our target is to have the following happen in the time that it takes you to have a coffee break:
The easier it is to add system testing to the CI/CD execution chain the less time the developer has to spend on making this happen and the more time he/she can spend on creating features! In a perfect world all the developers should need to do is to add one line of scripting in the CI/CD script to invoke the system test execution. This line would specify:
Webomates CQ offers this integration today.
An astute brownie sundae lover would have noticed by this point in time that I have not quite reached the other essential ingredients, namely fudge and caramel. Well the fudge for us would be analysis and the caramel would be exploratory testing.
The temptation to say that you have to fudge the analysis is really high at this stage! 😊 And often that is what can happen if it takes the developer too long to figure out if anything is broken and then to identify what is broken. So, they fudge it and push the build!
After all, what the developer wants to know is whether the work that (s)he has done in the last few hours has broken the software build in any way or can they proceed. Also, if they have broken something then any information that can rapidly help identify the defect will help. Examples of such help are:
Webomates CQ provides a defect prediction that helps a developer rapidly recognize whether there is a new bug that has been introduced.
Here I am really going to go out on a limb and challenge current dogma. If there was the ability to have an exploratory test carried out as part of the CI/CD chain would you choose to execute it?
Test case based testing only goes so far and is pretty rigid. It is a really good way to verify that what you know and have defined works correctly. Exploratory testing goes beyond the known envelope to try things out that are not heavily documented and scripted. It’s an incredibly valuable way to get an idea of the unknown and constantly increase the level of quality that you have. If you want to learn more about the differences between Exploratory and Test case based scripting read this blog that I wrote earlier on the subject.
Webomates CQ offers exploratory testing as part of its offering today.
CI/CD is a rising wave that technology companies are adopting all over the world. A lot of the value revolves in building and testing frequently so that incremental change can be verified more quickly and deployment to production can occur faster. However, in order to achieve this goal, verification at the system level is important. Using your existing system automation, or adding in a service like Webomates CQ for CI/CD can far more quickly and easily help realize the goal of rapid and reliable deployments in the field. Like with my brownie sundae, all the parts are integral to achieving the perfect balance and perfect tasting sundae!
If you are interested in learning more about Webomates’ CQ service please click here and schedule a demo or reach out to us at info@webomates.com.
Test Smarter, Not Harder: Get Your Free Trial Today!
Start Free Trial
Leave a Reply