Shift left is a familiar exhortation to teams and organizations engaged in Agile and Lean software development. It most commonly refers to incorporating test practices and an overall test sensibility early in the software development process (although it may also be applied in a DevOps context to the need to pull forward operations practices). Shift left sounds reasonably straightforward: just take the tasks that are on the right-hand side of your timeline and pull them forward (i.e., shift them to the left). As this post describes, however, there are some subtleties and qualifications you should consider in order to realize the benefits of a shift left strategy. These include targeting test goals, shifting-left the test mindset, and adopting shift-left enabling practices at the small team level and at scale.

Targeting Test Goals

Testing is not a single monolithic activity. There are different categories of test with different quality assurance goals. Testing may be conducted to verify a unit of work produced by an individual developer. It may be conducted at a component or system level or in the context of a system of systems. Quality assurance goals associated with testing may include

• verifying compliance to coding standards
• verifying integration points among multiple developers or development teams
• ensuring functional correctness, performance, security, usability, etc.

Testing activities may be pre-scripted or open-ended and exploratory. Testing may be conducted on code that is "hot off the presses" or regression testing may be done on mature code to ensure it hasn't been impacted by adjacent system changes.

In short, testing is a multi-layered collection of inter-related activities. Consequently, any shifting left of test efforts must be qualified by an understanding of the type of testing that is being pulled forward and its associated goals and preconditions.

Shifting-left the Test Mindset

While test activities must be shifted left, activities alone are insufficient. What also must be shifted left is what might be called a test sensibility. For developers, a test sensibility means internalizing a critical perspective on their code: to have the goal not just to make it work but to make it not not-work. At the project level, a test sensibility means shifting from milestone accomplishment seeking to fault-seeking behavior. This shift requires structuring development lifecycle activities to pursue as many quality assurance goals as possible as early as possible. It means shifting from the optimistic outlook of that should work to assuming the existence of underlying faults that must be exorcised.

Achieving a shift to the left for test, however, requires more than awareness. It requires enabling and supportive practices. Some sample practices for both small teams and scaled-up projects are discussed below.

Shift-left Practices at the Small Team Level

At the Agile team level, shift-left enabling practices include test driven development (TDD), story slicing, and the Definition of Done.

• In TDD, the developer starts out by writing an automated test case to verify the piece of code he or she is about to write. The automated test will initially fail, of course, because the code doesn't exist. The developer then writes the code and tests it using the automated test harness. The developer then extends the automated test base by adding a test that will be used to verify the next piece of code she writes, and so on. In essence, TDD shifts testing so far to the left, it's in front of code.

• Story slicing is performed to ensure that the sizes of the stories being developed fit comfortably within the confines of the sprint or iteration. Story slicing also ensures that each atomic work item will deliver some observable value. Typically, we think of that value in relation to the needs of the end user. However, learning and risk reduction also supply value. To the extent that stories can be sliced to traverse integration points and interfaces, story slicing is a practice that can be used to shift integration testing (and integration learning) to the left.

• The team-level Definition of Done outlines the criteria that must be met for the work of a given iteration to be considered complete. The team-level Definition of Done shifts testing to the left of the iteration boundary. It gauges value delivered in light of verification and validation activities performed and fundamentally integrates the concepts of value and quality assurance. The team-level Definition of Done checklist is created by the team members themselves and so represents a shift left of test sensibilities, as well as test activities. The Definition of Done at the team level will be affected by the overall project scope and context. A team that expects to release directly to production needs to adhere to different standards than a team working in a large-scale team-of-teams whose iteration output must be integrated into a larger system prior to release.

Shifting Left at Scale

On larger systems and team-of-teams programs, analogous practices may be employed to enable shifting left at scale. These practices include mission threads, a multi-level Definition of Done, and value-based project planning.

• A mission thread is a sequence of end-to-end activities and events that is executed to achieve one or more of the capabilities of a system-of-systems (SoS). For large-scale systems, mission threads can be employed to shift testing to the left in the same manner as story slices can be used in a smaller, more localized context. That is, mission thread scenarios may be constructed to traverse multiple interfaces and systems thus facilitating a shift left of integration, system, and even quality attribute testing.

• In a large-scale environment, a release to production will frequently consist of the work of multiple teams, across multiple increments. Release to production therefore requires verification and validation activities that transcend the Definition of Done employed by the individual teams. These activities include integration tests, end-to-end system functional tests and system-level quality attribute testing. The Scaled Agile Framework (SAFe) advocates a scalable Definition of Done that can be scaled from the team level to the system level to the solution level and finally to the release level. The multi-level Definition of Done bounds the viability of shift left testing (i.e., you can't integrate something that doesn't yet exist), but also helps ensure that integration, system, and quality attribute testing are shifted left as far as practicable.

• Regardless of the level it addresses, a Definition of Done is formulated for the purpose of verifying and validating the delivery of value. Testing is shifted left to coincide with the boundaries of value delivery. To enable testing to shift left, value delivery must shift left. That is, the project plan or roadmap or work breakdown structure or what have you must be designed with a focus on producing coherent, discrete testable components of value as early and as often as possible. Structuring the project plan around the incremental delivery of value provides a framework in which to execute a shift-left test strategy.

Automation: The Essential Enabler

Finally, no matter what the scale of the program or project, automation is an essential enabler of any shift left test strategy. At the small-team level, automation helps to ensure that the required verification and validation activities can be completed within the confines of the iteration time box. For larger projects the concern is to shift testing to the left to coincide with the point of change. Since change in Agile projects is incremental, iterative and ongoing, it follows that test activities must follow the same pattern. Without automation, test cannot hope to keep pace with the rate of development changes and will inevitably drift farther and farther to the right, moving the program closer and closer to a waterfall style of development.

Wrapping Up and Looking Ahead

Shifting left the delivery of verified and validated value is a central tenet of Agile development. The phrase itself is simple and snappy but achievement of a shift-left test strategy requires an active and conscious transformation of both practices and mindset. It requires thinking differently about how work is structured, how processes are designed, how roles are defined and how development dollars are invested. Going forward, DevSecOps practices extend shift-left thinking beyond testing and into security and operations. Shifting to the left involves collapsing and integrating silos, activities and roles in the service of accelerating the delivery of value. It is at the core of Agile development and will continue to inform the ongoing evolution of Agile practices.

Additional Resources

Read the SEI Blog Post 4 Types of Shift-Left Testing.

Read the SEI Technical Report Introduction to the Mission Thread Workshop.

Read Shift-Left Testing the Agile Way by Suzanne Miller and Robert Binder in the March 2017 ITEA Test & Evaluation Journal.