Shift-left testing

Last updated

Shift-left testing [1] is an approach to software testing and system testing in which testing is performed earlier in the lifecycle (i.e. moved left on the project timeline). It is the first half of the maxim "test early and often". [2] It was coined by Larry Smith in 2001. [3] [4]

Contents

Harm because of late testing

Shift-left testing aims to prevent the following types of harm because of late testing:

Types of shift-left testing

There are four basic ways to shift testing earlier in the life-cycle (that is, leftward on the classic V-model). These can be referred to as traditional shift-left testing, [5] incremental shift-left testing, Agile/DevOps shift-left testing, [6] [7] and model-based shift-left testing. [8]

Traditional shift-left testing

As illustrated in the following figure, traditional shift-left moves the emphasis of testing lower down (and therefore slightly to the left) on the right hand side of the classic V model. Instead of emphasizing acceptance and system level testing (e.g., GUI testing with record and playback tools [9] ), traditional shift-left concentrates on unit testing and integration testing (e.g., using API testing and modern test tools). The transition to traditional shift-left testing has largely been completed.[ by whom? ]

Incremental shift-left testing

As illustrated in the following figure, many projects developing large and complex software-reliant systems decompose development into a small number of increments (Vs) having correspondingly shorter durations. The shift-left illustrated by the dashed red arrows occurs because parts of the single, large waterfall V model’s types of testing (shown in gray) are shifted left to become increments of the corresponding types of testing in the smaller incremental V models. When each increment is also a delivery to the customer and operations, then incremental shift-left testing shifts both developmental testing and operational testing to the left. Incremental shift-left testing is popular when developing large, complex systems, especially those incorporating significant amounts of hardware. Like traditional shift-left, the transition to incremental shift-left has also been largely completed.

Agile/DevOps shift-left testing

As illustrated in the following figure, Agile and DevOps projects have numerous short duration Vs (sprints) in lieu of a single or small number of V as in the previous two examples of shift-left testing. These small Vs would also be modified if one or more early sprints are used to block out the basic requirements and architecture or if test-first and test-driven development (TDD) are being performed. The shift-left occurs because the types of testing on the right sides of the earliest of these tiny Vs are to the left of the corresponding types of testing on right side of the larger V(s) they replace. While the following figure appears remarkably the same for Agile and DevOps, Agile testing is typically restricted to developmental testing and does not include operational testing, which occurs once the system is placed into operation. The transition to Agile/DevOps shift-left testing is currently popular and ongoing.

Model-based shift-left testing

The previous forms all concentrated on testing earlier in the development cycle. However, they all test after software exists and seek to uncover only implementation defects.[ citation needed ]

Model-based testing moves testing to the left side of the Vs, by testing requirements, architecture, and design models. This shift begins testing almost immediately, instead of waiting a long time (traditional testing), medium time (incremental testing), or short time (Agile/DevOps) for software to become available to the right side of the Vs. This trend is just beginning.

Related Research Articles

<span class="mw-page-title-main">Software testing</span> Checking software against a standard

Software testing is the act of checking whether software satisfies expectations.

The waterfall model is a breakdown of development activities into linear sequential phases, meaning they are passed down onto each other, where each phase depends on the deliverables of the previous one and corresponds to a specialization of tasks. The approach is typical for certain areas of engineering design. In software development, it tends to be among the less iterative and flexible approaches, as progress flows in largely one direction through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance. The waterfall model is the earliest SDLC approach that was used in software development.

<span class="mw-page-title-main">Iterative and incremental development</span> Development methodology

Iterative and incremental development is any combination of both iterative design and incremental build model for development.

Software development is the process used to create software. Programming and maintaining the source code is the central step of this process, but it also includes conceiving the project, evaluating its feasibility, analyzing the business requirements, software design, testing, to release. Software engineering, in addition to development, also includes project management, employee management, and other overhead functions. Software development may be sequential, in which each step is complete before the next begins, but iterative development methods where multiple steps can be executed at once and earlier steps can be revisited have also been devised to improve flexibility, efficiency, and scheduling.

Agile software development is the mindset for developing software that derives from values agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001. As documented in their Manifesto for Agile Software Development the practitioners value:

Brownfield development is a term commonly used in the information technology industry to describe problem spaces needing the development and deployment of new software systems in the immediate presence of existing (legacy) software applications/systems. This implies that any new software architecture must take into account and coexist with live software already in situ.

Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.

Feature-driven development (FDD) is an iterative and incremental software development process. It is a lightweight or Agile method for developing software. FDD blends several industry-recognized best practices into a cohesive whole. These practices are driven from a client-valued functionality (feature) perspective. Its main purpose is to deliver tangible, working software repeatedly in a timely manner in accordance with the Principles behind the Agile Manifesto.

The incremental build model is a method of software development where the product is designed, implemented, and tested incrementally until the product is finished. It involves both development and maintenance. The product is defined as finished when it satisfies all of its requirements. This model combines the elements of the waterfall model with the iterative philosophy of prototyping. According to the Project Management Institute, an incremental approach is an "adaptive development approach in which the deliverable is produced successively, adding functionality until the deliverable contains the necessary and sufficient capability to be considered complete."

<span class="mw-page-title-main">Scrum (software development)</span> Management framework

Scrum is an agile team collaboration framework commonly used in software development and other industries.

Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace. Specification by example is used to capture examples of desired and undesired behavior and guide coding.

Azure DevOps Server, formerly known as Team Foundation Server (TFS) and Visual Studio Team System (VSTS), is a Microsoft product that provides version control, reporting, requirements management, project management, automated builds, testing and release management capabilities. It covers the entire application lifecycle and enables DevOps capabilities. Azure DevOps can be used as a back-end to numerous integrated development environments (IDEs) but is tailored for Microsoft Visual Studio and Eclipse on all platforms.

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the message layer. API testing is now considered critical for automating testing because APIs serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.

In software engineering, a software development process or software development life cycle (SDLC) is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

DevOps is a methodology in the software development and IT industry. Used as a set of practices and tools, DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle. DevOps is complementary to agile software development; several DevOps aspects came from the agile way of working.

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.

Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and following a pipeline through a "production-like environment", without doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery.

<span class="mw-page-title-main">DevOps toolchain</span> DevOps toolchain release package.

A DevOps toolchain is a set or combination of tools that aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organisation that uses DevOps practices.

Continuous configuration automation (CCA) is the methodology or process of automating the deployment and configuration of settings and software for both physical and virtual data center equipment.

Mobile DevOps is a set of practices that applies the principles of DevOps specifically to the development of mobile applications. Traditional DevOps focuses on streamlining the software development process in general, but mobile development has its own unique challenges that require a tailored approach. Mobile DevOps is not simply as a branch of DevOps specific to mobile app development, instead an extension and reinterpretation of the DevOps philosophy due to very specific requirements of the mobile world.

References

  1. Donald Firesmith (23 March 2015). "Four Types of Shift Left Testing". Archived from the original on 2015-09-05. Retrieved 27 March 2015.
  2. Microsoft (2012). "Test Early and Often". Archived from the original on 2 April 2015. Retrieved 27 March 2015.
  3. Smith, Larry (September 2001). "Shift-Left Testing". Dr. Dobb's Journal. 26 (9): 56, 62. Archived from the original on 2020-06-21. Retrieved 2020-06-04.
  4. "Sep01: Shift-Left Testing". 2014-08-10. Archived from the original on 2014-08-10. Retrieved 2019-09-06.
  5. Velocity Partners (28 January 2014). "Agile Testing - The Agile Test Automation Pyramid". Archived from the original on 2 April 2015. Retrieved 27 March 2015.
  6. Paul Bahrs (6 November 2014). "Shift Left: Approaches and Practices". Archived from the original on 6 April 2015. Retrieved 27 March 2015.
  7. Dibbe Edwards (18 September 2014). "Enabling DevOps Success with Shift Left Continuous Testing". IBM . Archived from the original on 2 April 2015. Retrieved 27 March 2015.
  8. Donald Firesmith (11 November 2013). "Using V Models for Testing". Archived from the original on 2 April 2015. Retrieved 27 March 2015.
  9. Microsoft (2013). "Record and Playback Manual Tests". Archived from the original on 2 April 2015. Retrieved 27 March 2015.