What is Continuous Integration (CI)?
To put it in simple words, it’s an action where developers are integrating code into a shared repository preferably, multiple times per day with the goal of finding errors quickly, providing fast feedback on the quality of the code, and executing an automated build to show the current state of the system. Continuous testing or automated testing is not part of CI but it’s usually paired together in order to discover the presence of bugs and give increase the project confidence level.
Agile testers should be part of the CI as a whole since they need to develop the automated tests, prioritize them, help with configuring testing environments, support the developers to understand and replicate a bug flow, etc.
In an ideal world, once the CI process is established, the code is built, the tests are executing automatically and the team is getting fast feedback on whether the system behaves like it should be following the requirements. But, that’s not usually the case due to potential conflicts that can happen while implementing this concept:
- Executing the CI frequently to get code quality feedback
- Code verification as much as possible per build
It’s not just writing automated tests. The goal is to write good automated tests and by good, I mean, understandable, flexible, and optimized but most important in this case would be reduced execution. Try to write tests that are not executing too long. I know that the tests can sometimes be too complex to write and you simply cannot refactor the test to execute faster and to be understandable and flexible at the same time. Long test executions can slow down the CI process, often resulting with not so frequent changes and no fast feedback.
But in terms of CI, choose tests that are most valued, tests that are covering the important aspects of the system but that are not executing too long.
CI approaches and solutions
Different organizations have different priorities and solutions when it comes to finding the balance between CI and testing. One of the approaches would be to prioritize the test. In other words, tests that are most important are always executed. The other approach would be to configure the runs. The daily run would consist of the basic and most important tests that provide quick feedback on the overall quality. The nighly run would consist of a larger number of tests that are executing longer.
Another approach is to increase the number of unit, integration tests included in the run and decrease the UI tests which generally take more time to execute or move the UI tests in a separate specific nightly run. That way we support the Test Pyramid approach having many tests at API level rather than UI level.
Selecting the tests that can test only the new feature can shorten the execution time and the CI process overall but it is not recommended since some regressions could be missed. Running the tests in parallel on multiple environments is another solution but it requires a lot of resources, time, and money to set it up.
What is Continuous Testing (CT)?
Continuous testing is an activity that involves testing early, and often, and automating in order to get feedback and release software rapidly. When new code is pushed, a set of tests are triggered and run on a production-like environment. The goal is, again, to get rapid feedback and increase confidence in the product overall. Continuous testing can include different test levels and types but in general, testing needs to be part of a DoD of a feature.
Want to learn more about continuous testing? Enroll Now for Continuous Testing in DevOps By Edureka and increase your chances to get hired by Top Tech Companies
How Continuous Testing affects Continuous Deployment?
In order to be able to continuously deploy, you need continuous integration and continuous testing. All code changes are deployed to a testing environment after the build run has passed. Different types of tests are performed here like functional, non-functional, load, performance, stress, visual, accessibility, usability testing, etc.
After the necessary testing is done the team has the confidence to successfully deploy the changes into production with a single push of a button, of course, after the DoD is satisfied. Automatically deploying into production is something companies strive for because it minimizes the time for developing a new code and having already released code be used by the users in production.
Share This Post
Latest Posts
- Crucial Aspects Of Superior Test Code Quality
- Streamline Your Cucumber BDD Tests with Gherkin Lint: A Comprehensive Guide
- How to Test Authentication and Authorization with Confidence + Best Tips
- Exploring the Three Scrum Artifacts: Grasping Their Essence and Effective Utilization
- How do Scrum teams work effectively to deliver quality products to their stakeholders?
