If you’ve been working as a tester for any length of time, you can’t have failed to notice the shift towards CI/CD in many projects and organizations. Businesses, project and operations teams all want to try and take advantage of at least some of the perceived benefits of being able to quickly and consistently release new builds to production, at the push of a button. In the meantime, testers will likely have found that the CI/CD model has a big impact on how they need to approach Testing.

CI/CD Overview from Tester’s perspective

CI/CD is an important aspect of a software project. It saves a lot of manual and error-prone deployment work. It results in higher quality software after continuous integration, automated tests, and code metrics. With a CI/CD, for every change in software code, it is built and tested automatically. If it passes quality control gates along with the required tests, it is automatically deployed. The automated acceptance tests are executed against it. This process of quality control and automation is getting more and more necessary in today’s fast-paced software-centric Environment.

Best Practices to follow

Most of the CI/CD pipeline has Development, QA, Stage and Production environments where certain tests are run to ensure that the code which has been written is safe to push ahead. An automated test is the most important part of any CI/CD pipeline. Without proper automated tests that run fast, have good coverage, and no erroneous results, there can be no successful CI/CD pipeline. The automated tests are usually divided into multiple “suites”, each with their own objective. The list below gives a small overview.

1. Unit tests: This is the suite that is run first, often by developers themselves before they add their changes to the repository. Unit tests normally test individual classes or functions.
2. Integration tests: After Unit test next comes Integration tests. This makes sure that the modules integrated together work properly as an application. Ideally, these tests are run on environments that are similar to the production environment. For ex. you’d want to make sure if your application uses a database from the same integration environment.
3. System tests: Should test the entire system in an environment as close as possible to the real production environment.

Testing in Development Environment

In Development Environment, Smoke testing is done. Smoke Testing, also known as “Build Verification Testing”, is a type of software testing that comprises a non-exhaustive set of tests aiming to ensure the most important functions run properly. The results of this testing are used to decide if a build is stable enough to proceed with further testing.

• To implement smoke tests, the testing team will develop a set of test cases that are run when a new release is provided by the development team.
• It will be more productive and efficient if the smoke test suite is automated or it can be a combination of manual and automation.
• To ensure quality awareness, the smoke test cases are publicized to the development team ahead of time, so that they are aware of the quality expectations.
• It is important to focus on the fact that smoke test suite is a “shallow and wide” approach towards testing.

Testing in QA Environment

In QA Environment, Regression testing is done. Regression testing is the type of testing carried out to ensure that changes made in the fixes or any enhancement changes are not impacting the previously working functionality.

• The regression packs are a combination of scripted tests that have been derived from the requirement specifications for previous versions of the software as well as random or ad-hoc tests. A regression test pack should, at a minimum, cover the basic workflow of typical use case scenarios.
• Perform standard actions defined in the testing procedure & check the desired responses for correctness. Any failure of the system to comply with the set of desired responses becomes a clear indicator of system regression.
• Do a careful analysis of every defect based on the previous test scenarios to avoid slip in
  regression testing.
• Ensure that the regression test must be correct & should not be out of date.

Testing in Stage Environment

In Stage Environment, Performance Testing is done. Executing the performance test on production similar system (i.e. Stage environment) and availability of all the required resources to successfully run the test is essential. Any application performance test result depends upon the test environment configurations.

• Performance testing is often an afterthought. It is performed in haste late in the development cycle, or only in response to user complaints.
• It’s crucial to have a common definition for the types of performance tests that should be executed against your applications. For example Single User Test, Load Test, Peak Load Test and Stress Tests.
• It is best practice to include Performance testing in Development Unit Tests. Perform modular and system performance tests.

Testing in Production Environment

In Production Environment, Sanity Testing is done. Sanity test is usually unscripted, helps to identify the dependent missing functionalities. It is used to determine if the section of the application is still working after a minor change. Sanity Testing goal is to check system health.

• An excellent way is to create a daily sanity checklist for the production testing that covers all the main functionalities of the application.
• Sanity testing should be conducted on stable builds to ascertain new functionality/ bugs have been fixed and application is ready for complete testing.
• Sanity testing is performed by Testers only.

Conclusion

This blog points out which environments are part of the CI/CD pipeline, how it is configured to successfully deployment of an application. It also explains the best testing types and approach used in each environment and its best practices.

The post Best practices for Testers in CI/CD appeared first on DevOpsTech Solutions.