... and in future
Consequently, the first step towards Continuous Testing has already been taken. And how will the current model now become a Continuous Testing model? Actually, the answer is quite simple: Divide your software into services / microservices and guarantee that each service can be provided independently of all the others via a deployment process. If necessary and appropriate, each deployment step of each service is checked for correctness in this connection by suitable automated tests to be defined.
In theory, this sounds very simple indeed, but the details require a great deal of effort in order to be implemented. Each service should have its own CI/CD pipeline for this. To avoid redundancies in the production and maintenance of the pipelines and obtain a uniform pipeline structure, a pipeline template should be defined, which then uses each service and implements and if necessary shapes the services (for graphic clarification, see Figure 3).
In this way, automated tests, such as unit tests, integration and API tests, end-to-end tests, burden and performance tests or whatever kind of test can be carried out for each deployment of each defined service. It is always necessary in each case to define which tests are necessary or make sense and when.
Particularly with regard to the error-prone and very slow end-to-end tests, the following questions need to be clarified to create the correct dimension of tests for the deployment pipelines:
- Does a smoke test suite make sense for the end-to-end tests and do I want to carry these out instead of end-to-end tests?
- Is it necessary to carry out end-to-end tests in each service, in part perhaps several times during the pipeline process?
- What end-to-end tests are really important for integration in my service deployment pipeline?
- Is the end-to-end testing as a kind of integration test of several services enough?
- Is the separate performance of end-to-end testing via an own process perhaps sensible or helpful in order to get regular feedback?
And how do I now start with the implementation?
The subject matter at first appears to be very theoretical. But to explain the subject in more detail in practical terms, we will make use of an example to provide an introduction to Continuous Testing. Figure 4 provides a graphic illustration of the potential procedure in implementation.
Let us assume, a company has decided to deploy Continuous Testing. It cannot find the resources or skills needed for this within its own workforce and obtains the corresponding know-how from consultants, who support its own team.
The point of departure is characterised by web-based software, consisting of a front-end platform and back-end platform. Both back-end as well as front-end are based on a service, which is in turn based on REST. Other functional web services / microservices are provided, for control by the front-end or via an API (likewise via REST). On the one hand, there are manual tests that run via the web GUI of the application. On the other, the automated end-to-end tests are carried out locally at intervals on a developer machine. There are no interface tests and the conduct of existing automated tests in Jenkins is neither implemented nor planned.