Part II: Build a Bridge Between Shift Left & Shift Right

In the first blog of this series, I used the metaphor of a bridge connecting two towns to illustrate the importance of establishing purposeful connections between your shift left and shift right testing initiatives.

Modern product organizations that fail to engineer a bridge to link the two “towns” (shift left and shift right) will, at a minimum, suboptimally utilize precious human and machine testing resources. In the worst-case scenario, product teams could undermine their most important strategic imperative: speed-to-market on software delivery.

For Part 2, we’ll dig into what a well-engineered bridge between shift left and shift right is and how a product team establishes one.

A well-engineered bridge is a fused bridge

Testlio introduced fused testing earlier this year to offer enterprise product teams a prescriptive way to strike the right balance of manual and automated testing. The resulting industry reception has been strong because product teams need a more pragmatic blueprint to build (or rebuild) their quality engineering programs. 

Fused testing is a methodology decoupled from where testing occurs in the SDLC, opening up possibilities for product teams to capitalize on fused testing regardless of how much that team has embraced shift left and shift right practices. 

But what has also emerged is the role that embracing fused testing can play as a bridge between shift left and shift right testing initiatives. The reason is simple. 

Shift left initiatives have notably served as the recent rally cry for enterprises to make incremental investments in test automation. But the revelation is that those investments have lacked a necessary ingredient to deliver on the promise of shift left test automation. Fused testing is that missing ingredient.

Fused testing ensures a sustained connection between shift left and the downstream testing that is and will always be required for product teams to release software successfully. Fused testing is the well-engineered bridge. Below I offer up specifics regarding how product teams can establish that bridge.

Shift left powered by fused testing

Shift left initiatives empower developers to assume more responsibility for quality, often by:

• Embedding quality engineers into development teams
• Deploying automated tests triggered by continuous integration workflows
• Adopting disciplines like BDD (Behavior Driven Development) to define functional test cases earlier in the product development cycle

All three of these can be implemented without fused testing, but the implication will be a lower ROI to the organization. 

Why? 

Because failing to incorporate fused testing into the above shift left initiatives means there will be “testing dead zones” — a phrase I use to define segments of an end-to-end testing process that either (1) lack actionable information or (2) lack actions altogether.

Let’s envision an enterprise product team that has invested in test automation to give their developers access to an automated test suite triggered by a code commit. This practice is and should be heralded as a significant maturity milestone in the journey to adopt shift left testing. But the problem is the signals that result from this testing won’t be fully actionable without a bridge that connects these quality signals to additional testing capacities beyond what developers can and will assume. The emergence of testing dead zones will be inevitable.

Now, envision the same scenario but with an extended workflow built into the process that automatically initiates manual intervention from the QA team when the same test fails three consecutive times. Furthermore, the bridge offers a multitude of signal-based workflows. An on-demand quality engineer is called into action to validate the script and runtime environment. At the same time, an expert manual tester is triggered to reproduce the issue across more devices for validation and additional forensics. Not only does this eliminate the testing dead zones across shift left and shift right, but it also ensures a strong ROI from the investments made in each of them. 

Attaining such a comprehensive and configurable testing workflow does require some organizational and process mechanisms that expand the design principles of shift left testing:

• Outcome-oriented mindset. Require shift left testing to define and document a full testing event chain across issue discovery, validation, triage, and resolution. 
• Empower stakeholder success. The ultimate champion for shift left within the organization should also have access to and influence over the use of manual testing talent.  
• Episodic testing. Acknowledge the requirement for episodic, context-driven testing along the shift left testing event chain.
• Configurability is strategic. Require configurable workflows so incremental and episodic testing can be continuously optimized to address an inherently broad and dynamic application testing matrix. 

A workflow that contemplates the opportunity to make smarter tradeoffs over time regarding whether machine or human should be testing and which humans should be triaging or validating a possible defect based on opportunity cost is the ultimate goal. 

That’s how a team can design and build the bridge.

Stay tuned for Part 3, which will further reflect on the what and the how of building a well-engineered bridge but with emphasis on shift right testing initiatives.