Build a Bridge to Connect Shift Left & Shift Right
Part 1: The Why
Two paradigms dominate the modern software testing landscape, shift left and shift right. These are fueled primarily by the need to accelerate software delivery to keep pace with a more dynamic and demanding digital engagement landscape.
Shift left moves testing workloads earlier in the SDLC, leveraging test automation and practices like behavior-driven development (BDD) to foster developer accountability and more comprehensive testing.
Shift right moves testing workloads later in the SDLC, leveraging humans and automation to perform both end-to-end testing and to conduct production testing and in the wild testing with real users on real devices.
While some solution providers may attempt to promote the merits of shift left or shift right in ways that put them at odds with one another, they are in fact both required ingredients to keep up with increasing demands for software delivery speed. Employing aspects of both should be part of every modern product team’s process.
So, what’s this about a bridge?
Consider the metaphor of a bridge that connects two towns. Towns that possess different qualities and strengths. Town A has great restaurants and nightlife. Town B offers a multitude of cultural experiences including a museum and live production theater. The bridge, or bridges, that connect the two play a critical role in determining the quality of life for the residents of both towns. Residents of Town A can claim a better quality of life because they have access to the cultural spoils of Town B, and vice versa.
In the context of shift left and shift right, bridges should play an equally critical role. They represent bidirectional signals between shift left and shift right testing workloads that inform more optimal use of limited human and machine testing resources.
The Perils of a Poorly Engineered Bridge
Like real-world bridge building, connecting shift left and shift right requires purposeful planning. Failure to establish this connection can have notable negative consequences including a false sense of security on software quality that ultimately undermines speed.
Unlike other aspects of the SDLC, software testing is by definition an exercise in making intelligent resource tradeoffs. No product team can achieve 100% test coverage without limitless resources and time. Once an organization accepts that testing is about optimization, they can harness the value of real time access to data that informs better and better resource allocation tradeoff decisions over time.
The absence of a well engineered bridge between shift left and shift right means neither initiative is getting the data set needed to make optimal tradeoff decisions.
Engineering leaders are adopting shift left by arming their developers with test automation tools, device farms, and implementing continuous integration governance to encourage embedding more testing into everyday activities. However, there will be diminishing returns to the ROI of these initiatives if downstream testing (shift right) signals are nonexistent, slow, or overly noisy. Asking a developer to go beyond basic unit testing of their code assumes that developers have the input needed to sustainably execute the right tests. The test case candidates for shift left should in fact be heavily influenced by testing that occurs downstream of the developer.
In the absence of good bridging, the lens for shift left developer testing will be too narrow, leading to the aforementioned false sense of security. Further, shift left initiatives that are disconnected from end UX testing invites waste. Precious developer capacity is spent creating and managing test cases that may not be aligned with the evolving definition of a compelling user experience.
Finally, disconnected shift left initiatives undermine the ultimate goal of increased software delivery speed, because product and business owners lose confidence and double down on creating more QA release candidate gates.
The Rewards of a Well Engineered Bridge
High performing developers want to deliver high quality software, which on the surface bodes well for the adoption of shift left testing. But high performing developers also loathe inefficiencies associated with bad processes or lack of access to information.
A well engineered bridge between shift left/right empowers developers with the ongoing signals needed to align and realign their testing workloads. The manual and automated testing investments they make are enhanced with access to richer information.
Consider a scenario where in-the-wild testing reveals an application bug associated with a specific mobile device/OS configuration. A well engineered bridge ensures that developers not only address the bug, but also have the context to update their automated test suites to remove blind spots and catch issues before the release candidate is shipped. The result is a better developer experience, and the self reinforcing adoption of increasingly efficient shift left testing.
Beyond better developer experiences and productivity, a well engineered bridge facilitates better optimization of testing workloads across the SDLC. Zooming out from the episodic nature of the bug scenario above, product teams can better optimize testing capacity across engineering and quality assurance teams. QA teams can promote test cases and automation scripts to developer teams while shifting resources and time towards incremental areas like exploratory and usability testing. The test coverage map is broadened over time as a result of increased efficiency not increases to investment levels.
Stay tuned for Part 2, which will reflect on the what and the how of building a well engineered bridge to connect Shift Left and Shift Right.