What do you get when you combine shift-left testing and continuous testing? You get shift-left continuous testing, of course.
What does shift-left continuous testing actually mean? This blog post explains shift-left testing, then offers tips on how organizations can leverage shift-left continuous testing to improve the speed and quality of their software delivery processes.
What Is Shift-Left Testing?
The easiest way to define shift-left testing is to start with the concept of shift-left. Shifting-left simply refers to the idea of performing an action earlier within a process. So, as it relates to software testing, shift-left testing is the approach of taking the action of testing your software and moving it to the left in the delivery pipeline—or, testing your software earlier in the development lifecycle than is historically typical.
While it is true that the benefits of shift-left testing are numerous, one particular benefit stands out above the rest. By beginning the process of testing your software earlier in the development lifecycle, you can almost guarantee that no critical bugs will survive late into the lifecycle. By testing software components as they are developed and integrated into the common codebase, bugs in the code that may result in major issues will be identified earlier. Through this practice, these bugs can be fixed at this early point when a fix is most likely easier to implement, rather than later when the fix is likely much more involved, and may require a major refactor for resolution. So, simply beginning the process of testing earlier in the lifecycle can serve to ensure that the speed of software delivery is not hindered by mistakes made months earlier in development.
What is Continuous Testing?
Continuous testing can be defined as the use of automated testing throughout the stages of the development lifecycle to determine the level of business risk associated with a potential release candidate. While continuous testing is not the same as automated testing, continuous testing requires as much test automation as possible at each step of the delivery pipeline.
The goal of continuous testing is to achieve end-to-end automated testing for the application in development, with as few gaps in test coverage as the team can manage in order to catch issues as early as possible—thus ensuring that they can be fixed as early as possible. With this, the level of business risk associated with a potential release candidate can be lowered, and the level of confidence in the quality of the release candidate can be raised.
In my mind, the concepts of shift-left testing and continuous testing share some commonalities. So how can we take these concepts in put them into practice in an effort to test continuously and shift our testing processes left in the delivery pipeline?
Combining These Concepts: Shift-Left Continuous Testing
In order to combine shift-left testing and continuous testing effectively, we must first understand why we are combining them, and what the goal is.
Essentially, the objective is to automate as much of our application testing as possible, maximize our test coverage to the best of our ability, and perform testing as early in the development pipeline as possible.
Below are a few tips that may help a DevOps organization get started with shift-left continuous testing.
Make “Has Automated Testing” Part of the Acceptance Criteria for User Stories
A big part of getting the DevOps team up to speed with continuous testing is finding a way to get developers to be consistent in their efforts to automate testing. Test scripts need to be written to test individual features as they are developed.
A good way to make sure that this occurs on a consistent basis is to include the requirement for automated testing as part of the acceptance criteria for the user story. In doing this, the user story will not be considered complete until automated test scripts have been developed to test the work done by the developer.
For example, a user story that represents a new web feature may have test scripts written using Selenium that test each form of user interaction with the feature. As the application matures and approaches a potential production release, you will find that much of the testing associated with your application has been automated. The different features of the application have test scripts written that can be run at any time to ensure the quality of the code.
Integrate Your Automated Test Scripts with Your CI Builds
As features for the application are developed and automated test scripts are written, you want to make sure that they integrate well with your CI tool. Have the test scripts run during each build—and if they fail, then the build should fail.
This will ensure that no existing features are broken as new code is developed. The application is continuously tested during each integration with the codebase, and prior to each deployment to another environment.
Simply testing each feature with each build in this manner establishes a certain level of quality within the application that will help to ensure a successful production release. It’s easier to fix a bug if it’s caught earlier in the process, and having your CI build run automated test scripts with each commit to the common codebase will help catch bugs early.
Conclusion
Shift-left testing and continuous testing are two useful strategies that can go a long way towards helping your organization truly adopt the philosophies of DevOps. When used together, they will serve to catch bugs early and validate the code often, and they will save your organization time and heartache by decreasing the time and effort required to fix issues with the application and increasing the quality of the product being released.
Scott Fitzpatrick is a Fixate IO Contributor and has over 5 years of experience as a software developer. He has worked with many languages, including Java, ColdFusion, HTML/CSS, JavaScript and SQL.
