Move into better QA with shift left and shift right testing
App dev teams face pressure to deliver software frequently and to a high-quality standard. Make QA an ongoing and teamwide effort to achieve these sometimes contradictory goals.
Test, once considered the middle step between development and live code for end users, has spread to the left and right. However, while descriptive, the terms shift left and shift right testing don't tell the whole story.
The two approaches introduce software testing into developers' responsibilities and production environments, respectively. It's more than simply testing earlier and later than before; shift left and shift right testing signify a larger change in methodology. Organizations increasingly stretch QA across the application development lifecycle and merge it with other team members' responsibilities.
Alone or in combination with CI/CD pipelines, shift left and shift right testing put Agile-defined roles into a state of flux. The rethink is best seen on DevOps teams, where software quality is an organizationwide effort, part of everyone's responsibilities.
As more IT professionals tackle software quality tasks, issues can arise about the viability and practicality of each approach. In this FAQ, we set out to tackle common questions about these shifted methods of testing.
What are the benefits of shift left testing?
Shift left testing addresses the bottleneck that manifests when developers and testers work on separate teams -- an arrangement reminiscent of the Waterfall model. Shift left upends that configuration to get both types of team members to work collaboratively -- or have their roles collapsed closer together.
When testers work closely with developers, teams can devise more effective unit and integration tests, before code commit. They catch bugs earlier, before these issues manifest as harder-to-solve problems in executable code.
Furthermore, a shift left approach helps development teams that lack the resources to perform full-fledged usability testing, which enlists actual users to carry out tasks with an application. If a team member with QA testing skills is included when developers work on a GUI, she can warn developers of the parts of the design that will confuse users. It's better to know a feature is inadequate early on, before the team sinks a lot of time and effort into it.
What is necessary to adopt shift left testing?
If a team wants to stretch testing as far to the left as possible, QA best practices should inform how developers actually build software.
Ultimately, every team must test code. So, effectual unit tests serve as a cornerstone of shift left testing. One practice, popularized by Agile, is for developers to first write their tests and other dynamic checks, before they write the code, which falls within the purview of test-driven development. After all, if a team wants to stretch testing as far to the left as possible, QA best practices should inform how developers actually build software.
To make shift left even more efficient, automate tests. When developers check code into a CI system, for example, the team can configure unit tests to run automatically via a test framework. If issues arise, developers receive a notification to work on the code more.
What are the benefits of shift right testing?
Software tests in live environments can garner feedback from actual users, which should carry a lot of weight for developers. Even when a piece of software passes every QA check before release, there is no guarantee that it will meet users' expectations.
Shift right testing can help a team gauge the user experience (UX) -- how happy customers are with the software's performance, availability, functionality and usability. This feedback teaches teams how users react to new releases.
User data illustrates what functional and UX aspects need improvement. When performed in production, nonfunctional tests, such as performance, load and usability tests, might yield more accurate results compared to synthetic data in a simulated environment.
Shift left and shift right testing can both facilitate a secure and fast CI/CD pipeline, which, in turn, helps app dev teams face the increased pressure to deliver software faster. The State of DevOps survey from DevOps Research and Assessment in 2018 referred to what was once called IT performance as software delivery performance. This parlance indicates how effective software delivery predicts organizational performance, and an increasing number of enterprises recognize that fact. Shift right testing practices can vet high-risk deployments so that teams deploy more frequently with less apprehension.
Testers might not have the time, resources or freedom to access data that would enable them to create a testing environment that fully replicates production. So, to keep pace with the competition and ensure a quality UX, organizations should adopt shift right testing.
What is necessary to perform shift right testing?
Teams must effectively capture and embrace user feedback and use it to determine what changes to make to an application -- even if it runs counter to the team's long-standing notions about various features, functions and design.
Smoke tests are not thorough enough, and exploratory tests tend to have bad ROIs. So, teams should focus on finding the most severe defects. An organization's operations team should have a monitoring setup that collects valuable data about the availability and responsiveness of the software. Accordingly, an ops team can administer -- and monitor -- chaos engineering tests. Such tests reveal potential weak points and causes of failure, how efficiently servers can be restarted, how fast the app can switch to backup systems and how resilient the software is.
Some other techniques for testing in production include:
Shift right practices, such as canary releases, enable IT to deploy updates to a limited group of users; those users act as a test group. If the updates pass muster, the ops team can deploy the changes to more users. If the changes cause problems, ops can roll the updates back. For this practice and other parallel deployment strategies, such as blue/green deployments, the ops team must host multiple versions of an application at once.
If testing a live system seems too risky, a team can use synthetic accounts, which run userlike sequences repeatedly to test the application.
