Explore shift-left testing
Testing in application lifecycle management is essential to maximize code quality and minimize operational risk associated with deploying and updating software. The term shift-left in this context conveys the idea of moving testing activities as early as possible in the development phase. The organization in our sample scenario should consider incorporating this approach into its DevOps strategy in order to minimize the current security and stability issues. In this unit, review different types of tests that could be implemented in this manner and then examine their implementation methods.
What tests should be part of shift-left testing?
Software development incorporates a wide range of test types, but those of a particular interest to us include:
Unit tests: These tests focus on the smallest testable parts of an application code, such as individual functions or methods. The objective is to establish whether each unit of code can successfully perform its intended operation in isolation from the rest of the codebase and external dependencies. Such tests should be fully automated, quick (complete within 30 seconds), and provide full code coverage (which basically means that all unit tests should collectively test the entire codebase). Unit testing is suitable for the shift-left approach. We recommend applying it to all code as early in the development cycle as possible, preferably at the beginning of the programming phase.
Smoke tests: These tests are meant to assess the core functionality of an application in a test environment. While they test the actual application (rather than its individual, isolated components, as unit tests do), their purpose is to determine if the application build or deployment is sufficiently stable to warrant more in-depth testing. However, they don't verify interoperability between apps. As with unit tests, they should be fully automated and relatively quick (user interaction can be simulated by using browser automation tools and user interface automation frameworks). The term smoke test is meant to convey the idea of smoke indicating a major issue (fire) that should be addressed as soon as possible. Smoke testing should also be implemented early in the development cycle, preferably as soon as a version of the software providing its core functionality is available. This applies to both the application build and deployment phases.
Integration tests: These tests validate interaction between different application components. Unlike unit tests, they can take a considerable amount of time to complete. The extended duration of these tests is commonly used as an argument for running them early in the software development lifecycle. In general, you should consider integration tests in scenarios for which unit or smoke tests aren't suitable. However, the recommendation is to schedule them to execute in regular intervals. This approach offers a reasonable compromise between a potential delay in detecting integration issues and an extra wait time required to complete them.
Acceptance tests: These tests determine whether a software product meets the business requirements and is ready for a delivery to its consumers. Acceptance testing isn't suitable for the shift-left strategy, but it might be possible to incorporate some of its elements early in the software development lifecycle. For example, acceptance criteria and user stories, which are essential components of acceptance testing, should be introduced early in the development process. This facilitates collaboration between development teams, product owners, and project stakeholders. In addition, software consumers and project stakeholders should be engaged in the earlier testing phases in order to share their feedback. This might involve using such methods as alpha or beta testing, usability testing, or early releases, ahead of the formal acceptance testing.