Skip to content
Published on

Shift Left with OpenTAP

Categorized
Articles

The concept of Shifting Left has come into vogue to describe moving a process or process stage to occur earlier in a left-to-right timeline. Shifting Left applies to various types of testing, especially tests aimed at improving usability and cybersecurity.

This blog reviews the implications for Shifting Left across various software development models, and highlights the benefit of combining a leftward shift with test automation.

The Waterfall Development Model

The first cited use of "Waterfall Model" was by Winston W. Royce in 1970, but the model itself dates back to the 1950s. The Waterfall, in one form or another, has been widely used for software projects; it is very simple to understand and to follow, but also quite rigid. In strict waterfall development, each phase must be completed before the next phase can begin without overlapping the phases or reaching back until a new project is begun.

Traditional Waterfall Model with late-stage testing

The most notable shortcoming of the Waterfall is that Testing does not begin until Implementation is complete, as a prelude to Deployment. This late ordering has always be cited as the principal weakness of the Waterfall Model.

Agile Development

Today, Waterfall is considered "old hat" and no dev team worth its salt will admit to following it (although many do). In its place is Agile Development, with practices emphasizing interactive requirements discovery, incremental product definition and collaboration among cross-functional teams and end users. Unlike Waterfall, Agile emphasizes adaptive planning, evolutionary development, early delivery, continual improvement, and flexible response to changes in requirements. In an enterprise setting, Agile can form the basis for continuous development and delivery, a.k.a. DevOps.

The Agile Life-cycle, showing integrated testing and increasing remediation costs

Moreover, Agile implicitly addresses testing as part of its incremental approach.

Shifting Left - Test Early, Test Often, Test Always

Shift Left is an approach to software test, system test and cybersecurity in which testing begins substantially earlier in the product or service life cycle, that is, moved leftward on a project timeline.

Shifting left offers testing practitioners many advantages over legacy test timing:

  • No longer treating testing as a discrete phase of development, but as integral to the entire lifecycle

  • Application of additional resources available during development

  • Opportunities to discover defects in requirements, architecture and design

  • Easier debug through testing during prototyping, implementation and integration (vs. attempting to test after the fact)

  • Increased code coverage through co-design of test code (vs. black box)

  • Reduced accumulation of technical debt

  • Preventing testing from becoming a bottleneck

  • Avoiding/reducing increasingly costly remediation later in the life cycle

Shifting Left is Not Free; Not Shifting Left is Unaffordable

The last point is perhaps the most important. In legacy Waterfall methodology, testing only begins on the eve of delivery. As laid out in the Agile diagram above, post-development testing can increase remediation costs 100-1000 times over beginning testing earlier, during prototyping (and never stopping).

Many development organizations, however, believe that they lack test and QA/QC resources to support Shifting Left. Those resources are present but are "wearing different hats": those of software developers, architects and other devs. Moreover, developers are frequently inexperienced in building and running test code, or even disdain the chore. This discomfort is another reason why testing is often left until later in the life-cycle, kicking the testing can down the road to dedicated testers and QA/QC.

Test Code is Alien

Test Code is often treated like an alien artifact

Especially in hardware-centric organizations, test code is treated as an "alien artifact", coming from third parties - chipset manufacturers, subsystem suppliers or accompanying open source project code. Test code can arrive in a different programming language, e.g., Python or assembler, when the rest of the project is in C# or Java. And because it "doesn't fit", legacy test code runs outside of normal build scripts, often requiring manual invocation and inspection of execution logs. Development teams don't want to deal with this code and often don't understand what it does.

Unfunded Mandate

The imperative to Shift Left sounds beneficial, but can end up as an unfunded mandate. A great idea, but too much work for the current release or resources; product management tags the move as "desirable but not urgent" and the devs happily move Shift Left into a conceptual "parking lot".

Shift Left with Test Automation

One of the best remedies for increased short-term cost and resource utilization (real and perceived) from Shifting Left is Test Automation. Test Automation streamlines repetitive but necessary tasks in a formalized testing process already in place, and can facilitate new testing, especially test that are difficult to perform manually. Test Automation reduces the pressure on the testing team and provides faster feedback about the stability of code under development by automating results delivery and analysis.

There are many approaches to test automation, with various approaches benefiting differing use cases. All of the following testing scenarios benefit from Test Automation by improving repeatability, scalability, ease of invocation, standardizing results collection, and facilitating post-test analysis.

  • API driven testing uses programming interfaces to software and/or hardware to validate the behavior under test. API-driven testing doesn't depend upon user interfaces and so lends itself to blackbox testing as well.

  • GUI testing generates user interface events (e.g., keystrokes and mouse motion), and observes the changes that result in the user interface, to validate that the observable behavior of the program is correct.

  • Hardware testing typically proceeds at different levels of abstraction

    • Raw h/w test exercises devices under test (DUTs) directly, using special purpose test jigs and dedicated, non-production test code; most important before availability of production hardware

    • Test-in-place exercises production hardware interface code - device drivers and interface subsystems

Even considering the advantages described above, Test Automation is not a panacea and doesn't always result in a leftward shift in testing practices. Test Automation that relies on bespoke software can create create bottlenecks in the development lifecycle by

  • taking back resources when the Test Automation software itself becomes a support burden

  • limiting collaboration among teams from non-standard / incompatible Test Automation frameworks

  • lacking integration and interoperability with key development tools

  • demanding programming expertise in "alien" (legacy) tooling environments

and many other challenges.

The Advantages of OpenTAP

Open source standards-based OpenTAP lends itself perfectly to support Shifting Left through flexible Test Automation. Itself a fast-moving open source project, OpenTAP can keep pace with rapid product development and test cycles. Through a rich set of pre-built plugins and the ability to create new ones, OpenTAP easily integrates with existing software and hardware test harnesses and workflows. Importantly, OpenTAP eliminates the burden of maintaining and reworking homegrown test tools for even minor test set changes.

OpenTAP also removes key human stressors that can impact productivity. It facilitates cross-team collaboration with a unified, shared Test Automation platform. It leverage software development and support talent when available. Based upon the ubiquitous and popular Microsoft .NET framework and implemented in C#, OpenTAP supports other popular programming languages like Python and is extensible through an open plugin architecture. And if your team prefers a graphical approach, OpenTAP interoperates with a graphical programming environment to minimize the need for software engineering expertise.

Conclusion

Combined with Test Automation, Shifting Left is more than a buzzword - it's an actionable development imperative. The earlier your project and dev teams start testing, the higher quality you can deliver to market, with lower overall development costs, especially from remediation and reworking. OpenTAP provides the ideal platform to facilitate Shifting Left, with a standards-based, flexible and open test automation solution.