The concept of shifting testing left or right has been gaining momentum with the increased adoption of continuous integration, continuous delivery, and DevOps. Consultants and thought leaders have been encouraging teams to shorten feedback cycles between development and testing in order to increase velocity.
To determine if the product is meeting its intended purpose, they also recommend improving awareness of the user experience and user needs. While that sounds like excellent advice, do you really know what it means, how to do it, or who is going to do it? Probably not—and neither does the rest of your team.
By "team," I mean everyone involved in the creation of a feature or product: developers, testers, project managers, Scrum masters, product owners, and stakeholders. Each of these roles is critical to software quality and the process used to take it from conception to deployment. Note that these are roles to be played, not just positions to be filled. On a small project, it is feasible that a single person could fill multiple roles, or even all of them.
Introducing new ideas and processes can be frightening for development teams, because change is hard. And it's even harder when you don’t have clear answers and boundaries. Here's how to implement shift-left and shift-right in your organization.
The idea behind shift-left
Shift-left testing is the most frequently suggested modification for improving velocity and team efficiency. The idea behind shifting left is to test functionality and identify issues earlier in the development cycle. This is a commendable goal, but it is not as easy in practice as one may think. The transition requires changes to the team’s processes, along with adjustments in thinking and duties for developers and testers.
The usual implementation plan consists of instituting an X-driven development technique (test-driven, behavior-driven, acceptance test-driven, etc.) and putting the burden of early testing on developers. Many of them will assume that increasing the amount of testing they are required to do will result in a drastic loss of productivity, and they will fight the new process.
One might think that this is where testers would be allies. But they are generally too concerned about keeping their jobs, and instead often side with developers in order to maintain the status quo. In addition to this general resistance to change, consider the differences between tester and developer thought processes. While it is possible for one person to be competent as both a tester and a developer, that person cannot perform both roles at the same time.
A more considered implementation would be to transition testers from the end of the process to the beginning and keep them involved throughout. This can best be accomplished by improving tester involvement during the planning stages of projects.
During the concept stages, developers focus on how something can be done. A tester focuses on the risks involved and how the desired functionality can be validated. By collecting both of these viewpoints, you can build better acceptance criteria, as well as provide an outline as to how testing should be handled.
As your project moves into active development, your team can review the outline and determine how to address the test requirements. This process involves categorizing the tests into automated and manual and further breaking them down as unit, integration, and UI.
Once you've completed the breakdown, you can more easily share the tasks with the team based on how they relate to each person’s role. Developers should be writing the required unit tests based on the functional requirements defined and the tester input provided. Testers should be building their test suites and exploratory charters while the features are being developed so that they are ready once a testable portion is completed. The handling of automation and integration tests often varies but should involve both testers and developers, since it requires both technical savvy and risk analysis.
What it means to shift-right
You may be wondering how it is possible to move testing any further right in the development process, since it generally comes at the end already. But shift-right isn’t about moving all testing to the end of development; it’s about continuing test efforts in preproduction and production environments to obtain insights into the application that cannot be found easily during development.
These additional efforts typically come in the form of three things:
- Performance
- Fault tolerance
- User-experience testing
The value of these endeavors is that they provide vital data to the team about the quality of the product.
When implementing shift-right testing, you create an alternative team to handle this phase. This team focuses on accepting the completed development; deploying it into preproduction, an A/B environment, or production; and then beginning nonfunctional, exploratory, and advanced testing. With these tasks in mind, your team should be made up primarily of testers and developers, but also product owners and perhaps a development lead in advisory roles.
For more information about specific tests your team could introduce, read Lanette Creamer's 8 Reasons to Shift Testing Right, which offers examples of right-shifted testing and the value each brings. Also, Joe Colantonio wrote an excellent overview of microservice testing, which includes fault tolerance and how to test microservices in production, in Shift-right: Test microservices in the wild to tame DevOps.
Shift right? Shift left? Do both!
Rather than trying to decide which direction your team should go, consider the fact that shift-left and shift-right are not mutually exclusive techniques: You can reap the benefits of each method by choosing to go both ways.
- Implement shift-left to shorten the feedback cycle during development and increase the team's quality awareness.
- Then shift-right. By shifting left, you pave the way for testers to shift right and begin executing more exploratory, performance, and user-experience testing.
These practices complement each other and provide a broader range of testing and feedback.
Regardless of the decision your team makes about shifting test, your team should understand that the move doesn’t mean developers will be doing all of the testing and testers will be out of a job. This is an evolution in the development process that offers individuals in both roles to improve their collaboration and skills. It means adapting to changes in process and rising to new challenges as they appear. But that is part of the reason why people are in these professions anyway.
For more on shifting testing, I recommend reading Jesper Ottosen's Shift-Left, Shift-Right, and Shift Coach. His posts contain his personal insight into these methods and numerous references to other sources.
Image credit: Flickr
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
