Testing applications used to be a technically challenging, time-crunched activity scheduled days or weeks before an application’s release. Development teams were given the leeway to code until the eleventh hour, and testers, who did much of their work manually, had little choice but to make do with the bit of time given to them. The result was that many applications underwent substandard testing, and technology teams were forced to respond to the production issues and defects escalated by end-users and application monitoring systems.
, unit testing frameworks, and test automation practices have upended this paradigm. Instead of performing quality assurance at the end of the development process, many testing practices now start and fully execute during coding, integration, and deployment. , and CI/CD pipelines call out to run the tests during their code integration or delivery phases. The net result is that developers are alerted when their code changes break the build and can take immediate steps to address the reported issue.
Automating testing and integrating testing scripts into CI/CD pipelines is known as shift-left testing. It implies that more quality assurance practices can be done in the development phase to catch issues earlier in the release timeline. for agile and devops teams who want to increase deployment frequencies.
At the introduction of new functionality, the constructed test scripts validate the new capabilities. These tests can then be automated and included in the build or deploy steps. Instead of having QA engineers run regression tests at the end of a release process, you can run and validate many of these tests as part of development. These tests shift left from the end of the release process to earlier development and coding phases.