Today a software testing sector requires complete competence in TestOps and skills in developing qualitative automated tests from a QA engineer.

It happens due to the rapid development of CI/CD and the importance of QA engineers’ work with pipelines.

[highlight dark=”no”]But why is CI/CD crucial for every tester today?[/highlight]

There are several answers to this question:

• A possibility to launch tests automatically;
• Quality control based on Quality Gates;
• Creation of a qualitative release process.

How things looked like before and after implementation of CI/CD.

The possibility to launch tests automatically

The possibility to launch tests locally is out-of-date.

Now we can launch tests through CI/CD since this is its main task.

Let’s imagine that we have DevOps and have transferred the task of editing pipelines with tests.

Thus, we completely ignore the possibility to implement the second main parameter of CI/CD – monitor quality on the basis of “Quality Gates”.

Quality control by the “Quality Gates”

What do “Quality Gates” mean, or in other words – software code quality assurance?

Let’s imagine that the entire software code is a castle.

Each day a team of developers creates new lines of code for new features that can break the castle.

A primary task of testers is to test the functionality of each feature and reduce the risk of bugs’ appearance in a ready product.

But in this case, a QA lab has no guarantee to control all metrics since there is no protection from a human factor (someone has not completed a task, someone has completed it but hasn’t merged it to production, etc.)

[highlight dark=”no”]Only the usage of automated tests fixes this issue.[/highlight]

Each next test will be responsible for the execution of an important metric of testing.

If “borders” of a metric are not kept, “gates” will be closed and won’t push a feature to the online environment.

And the feature won’t be added to software code until all tests are executed, therefore, all potential bugs will be found and fixed.

Stages of testing CI/CD

To completely automate software testing, we need to develop a special list of tests to pass a pipeline.

We may use the method of “Fail first” for testing. In this case, functional tests (build functionality, code style, and execution of static analysis) are executed first of all.

An example of a CI/CD pipeline

Everything is clear with a build: if a product is not built, a feature is not implemented in the product.

A process of code styling should be transferred to CI/CD to instantly unify requirements and don’t waste time on code style bugs while conducting code review.

Static analysis is an important tool used to analyze the quality of created software code. It can show numerous critical bugs that will definitely lead to failures in software functionality.

Next, there are second-level tests: groups of unit tests with analysis of test coverage and control of reaching necessary indicators and also, systems of test integration with all available reports for analysis.

Moreover, there can be various non-functional tests such as scr tests, performance tests, usability tests, and security tests.

Main requirements for pipelines:

1. It should provide the highest number of features, taking the QA department’s requirements into account;
2. The time needed to execute a pipeline shouldn’t slow down development (this usually takes up to 20 minutes).

How CI/CD helps build a process of releases

Ci/CD doesn’t only help launch tests automatically and implement some metrics of software code quality assurance but also, enables manual testers to build a qualitative process of constant release.

Sometimes the process of releasing software is complex and depends on numerous manual actions.

Sometimes it’s a completely manual process: one artifact is built by developers, and a build is tested and then sent to the one responsible for delivering a feature to production.

This structure of work may contain numerous bottlenecks – just imagine what can happen if one of the workers is on vacation or is ill.

The process of release of each project team looks completely different but it usually includes the following steps:

1. A product build is constantly launched in the git branch;
2. Each build is tested in all common ways;
3. A product’s release candidate is checked and final tests are executed;
4. If the third step is executed successfully, the release candidate goes to production.

Any modern CI/CD system can build this process. But it needs to be comfortable either for a team of developers or the testing department.