Shift left testing
}} 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]
Harm Due to Late Testing
Shift left testing is important because it helps to prevent the following types of harm due to late testing:
- Testers may be less involved in initial planning, often resulting in insufficient resources being allocated to testing.
- Many requirements, architecture, and design defects are not uncovered and fixed until after significant effort has been wasted on their implementation.
- Debugging (including identifying, localizing, fixing, and regression testing defects) becomes harder as more software is produced and integrated.
- Encapsulation (object-oriented programming) makes it harder to perform white-box testing and to achieve high levels of code coverage during testing.[citation needed]
- There is less time to fix defects found by testing, thereby increasing the likelihood that they will be postponed until later increments or versions of the system, which creates a “bow wave” of technical debt that can sink projects if it grows too large.
Types of Shift Left Testing
There are four basic ways to shift testing earlier in the lifecycle (that is, leftward on the classic V-model). These can be referred to as traditional shift left testing,[3] incremental shift left testing, Agile/DevOps shift left testing,[4][5] and model-based shift left testing.[6]
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[7]), 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?]
Traditional Shift Left Testing
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.
Incremental Shift Left Testing
Agile/DevOps Shift Left Testing
As illustrated in the following figure, Agile and DevOps projects have numerous short duration Vs (a.k.a., 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.
Agile/DevOps Shift Left Testing
Model-Based Shift Left Testing
The previous forms of shifting testing left all concentrated on beginning the testing of software earlier in the development cycle. Waiting until software exists to begin testing, however, largely and unnecessarily limits the use of testing to uncovering coding defects. This delay is particularly disturbing because from 45 percent to 65 percent of defects are introduced in the requirements, architecture, and design activities.[8]
As illustrated in the following figure, model testing moves testing to the left side of the Vs by testing executable requirements, architecture, and design models. This shift enables testing to begin almost immediately, instead of waiting a long time (traditional), medium time (incremental), or a short time (Agile/DevOps) until software on the right side of the Vs is available to test. This trend is just beginning.
Model-Based Shift Left Testing
References
- ↑ Donald Firesmith (23 March 2015). "Four Types of Shift Left Testing". http://blog.sei.cmu.edu/post.cfm/four-types-shift-left-testing-082. Retrieved 27 March 2015.
- ↑ Microsoft (2012). "Test Early and Often". https://msdn.microsoft.com/en-us/library/vstudio/ee330950%28v=vs.110%29.aspx. Retrieved 27 March 2015.
- ↑ Velocity Partners (28 January 2014). "Agile Testing - The Agile Test Automation Pyramid". http://www.velocitypartners.net/blog/2014/01/28/agile-testing-the-agile-test-automation-pyramid/. Retrieved 27 March 2015.
- ↑ Paul Bahrs (6 November 2014). "Shift Left: Approaches and Practices". http://www.slideshare.net/Urbancode/shift-left. Retrieved 27 March 2015.
- ↑ Dibbe Edwards (18 September 2014). "Enabling DevOps Success with Shift Left Continuous Testing". https://www.ibm.com/developerworks/community/blogs/invisiblethread/entry/enabling_devops_success_with_shift_left_continuous_testing?lang=en. Retrieved 27 March 2015.
- ↑ Donald Firesmith (11 November 2013). "Using V Models for Testing". http://blog.sei.cmu.edu/post.cfm/using-v-models-testing-315. Retrieved 27 March 2015.
- ↑ Microsoft (2013). "Record and Playback Manual Tests". https://msdn.microsoft.com/en-us/library/dd286714.aspx. Retrieved 27 March 2015.
- ↑ "Quality Flaws: Issues and Challenges in Software Development". 2012. http://www.iiste.org/Journals/index.php/CEIS/article/viewFile/3533/3581. Retrieved 27 March 2015.
 |
