Jenkins Management for Automated Testing — Continuous Integration, Continuous Delivery and Making Your Life Easier
In my Automated Testing (AT) series, we will discuss testing frameworks, AT best practices & approach, and managing Jenkins. I seek to share my QA knowledge and bounce off ideas with fellow testers in developing a complete and robust AT Testing System.
This article assumes you have the basic understanding of Jenkins, Automated Testing, and Continuous Integration/Continuous Delivery (CI/CD)
Why Jenkins + AT + CI/CD?
It is not unusual that developers make mistakes when committing codes into master branch(es). These can be categorised into technical failures and business logic failures.
Technical Failures:
- Wrong dependencies’ versions
- Dependencies not prepared/installed
Business Logic Failures:
- Merging multiple features potentially causing failure in meeting business requirements
This is a typical CI/CD in a development cycle. In such a design, we can ensure that the system is Built & Deployed successfully, or trigger alerts upon failures.
Will this be sufficient? Will It be able to detect any business logic failures? Well, the answer is No. We need to enhance this process and integrate it with automated testing.
Refining the CI/CD Process
We need a highly reliable process that aims not just to ensure successful server deployments, but also the completeness of meeting business requirements.
In this design, we maintain the CI/CD in the original process — dev push codes, GIT triggers Jenkins build, notify failure.
So, what changed? We maintain a separate repo AT Repo solely for testing purposes, containing all the AT cases. Nightly, an api-all-test-run job will be triggered, running test cases that checks if a particular server meets the business requirements. A JUnit Testing Report is generated after an api-all-test-run which indicates the failed test cases to the Dev/QA. From this point on, failures will be remedied by the assignee.
By creating separate jobs, we are able to build and run test cases individually. A build-deploy job is triggered whenever changes are made in the main repo. A api-all-test-run job is triggered nightly to test the latest server(s) deployed.
This process successfully integrates AT into a CI/CD design. Devs are alerted when a build fails every time codes are pushed to master. At the same time, this process ensures that the system maintains or meets its (new) business logic.
This is a brief article introducing the AT CI/CD process. There are surely unanswered questions:
- how to build an
AT Repo? - how to generate a
JUnit Testing Report?
In the next few articles of this series, we aim to build a simple server and showcase AT in the works. Stay tuned and see ya!
