Shift-left testing: Difference between revisions

Revision as of 20:56, 26 September 2019

Latest revision as of 12:06, 5 October 2024

(35 intermediate revisions by 25 users not shown)

Line 1:

{{Short description|Type of software testing}}

{{multiple issues|{{more footnotes|date=May 2015}}{{essay-like|date=May 2015}}

{{Orphan|date=May 2015}}

}}

'''Shift-left testing'''<ref>{{cite web|url=httphttps://bloginsights.sei.cmu.edu/post.cfmsei_blog/2015/03/four-types-of-shift-left-testing-082.html |title=Four Types of Shift Left Testing |author=Donald Firesmith | date=23 March 2015 |accessdatearchive-url=https://web.archive.org/web/20150905082941/https://insights.sei.cmu.edu/sei_blog/2015/03/four-types-of-shift-left-testing.html |access-date=27 March 2015|archive-date=2015-09-05 }}</ref> is an approach to [[software testing]] and [[system testing]] in which testing is performed earlier in the [[software development life cycle|lifecycle]] (i.e. moved left on the project timeline). It is the first half of the maxim "Testtest early and often.".<ref>{{cite web |url=https://msdn.microsoft.com/en-us/library/vstudio/ee330950%28v=vs.110%29.aspx |title=Test Early and Often |author=Microsoft | date=2012 |accessdateaccess-date=27 March 2015 |archive-date=2 April 2015 |archive-url=https://web.archive.org/web/20150402174955/https://msdn.microsoft.com/en-us/library/vstudio/ee330950(v=vs.110).aspx |url-status=live }}</ref> It was coined by Larry Smith in 2001.<ref>{{Cite journal|last=Smith|first=Larry|date=September 2001|title=Shift-Left Testing|url=https://www.drdobbs.com/shift-left-testing/184404768|journal=Dr. Dobb's Journal|volume=26|number=9|pages=56, 62|viaaccess-date=2020-06-04|archive-date=2020-06-21|archive-url=https://web.archive.org/web/20200621040103/https://www.drdobbs.com/shift-left-testing/184404768|url-status=live}}</ref><ref>{{Cite web|url=http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2001/0109/0109e/0109e.htm|archive-url=https://web.archive.org/web/20140810171940/http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2001/0109/0109e/0109e.htm|url-status=dead|archive-date=2014-08-10|title=Sep01: Shift-Left Testing|date=2014-08-10|website=web.archive.org|access-date=2019-09-06}}</ref>

== Harm duebecause toof late testing ==

Shift-left testing is important because it helpsaims to prevent the following types of harm duecaused toby late testing:

* Testers may be less involved in initial planning, often resulting in insufficientInsufficient resources being allocated to testing.

* ManyUndiscovered defects in requirements, architecture, and design, defectsalong are not uncovered and fixed until afterwith significant effort has been wasted onwhile theirimplementing implementationthem.

* Difficulty [[Debuggingdebugging]] (including identifying, localizing, fixing, and regression testing defects) becomes harder as more software is produced and integrated.

* Reduced [[code coverage]] during testing{{Citation needed|date=October 2017}} as a result of [[Encapsulation (object-oriented programming)|encapsulation]] makes it harder to performimpeding [[white-box testing]] and to achieve high levels of [[code coverage]] during testing.{{Citation needed|date=October 2017}}

* A “bow wave” of [[technical debt]] that can cause a project to fail.

* 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 life-cycle (that is, leftward on the classic [[V-model]]). These can be referred to as traditional shift-left testing,<ref>{{cite web |url=http://www.velocitypartners.net/blog/2014/01/28/agile-testing-the-agile-test-automation-pyramid/ |title=Agile Testing - The Agile Test Automation Pyramid |author=Velocity Partners | date=28 January 2014 |accessdateaccess-date=27 March 2015 |archive-date=2 April 2015 |archive-url=https://web.archive.org/web/20150402164204/http://www.velocitypartners.net/blog/2014/01/28/agile-testing-the-agile-test-automation-pyramid/ |url-status=live }}</ref> incremental shift-left testing, Agile/DevOps shift-left testing,<ref>{{cite web |url=http://www.slideshare.net/Urbancode/shift-left |title=Shift Left: Approaches and Practices |author=Paul Bahrs | date=6 November 2014 |accessdateaccess-date=27 March 2015 |archive-date=6 April 2015 |archive-url=https://web.archive.org/web/20150406145122/http://www.slideshare.net/Urbancode/shift-left |url-status=live }}</ref><ref>{{cite web |url=https://www.ibm.com/developerworks/community/blogs/invisiblethread/entry/enabling_devops_success_with_shift_left_continuous_testing?lang=en |title=Enabling DevOps Success with Shift Left Continuous Testing |author=Dibbe Edwards |website=[[IBM]] |date=18 September 2014 |accessdateaccess-date=27 March 2015 |archive-date=2 April 2015 |archive-url=https://web.archive.org/web/20150402110506/https://www.ibm.com/developerworks/community/blogs/invisiblethread/entry/enabling_devops_success_with_shift_left_continuous_testing?lang=en |url-status=live }}</ref> and model-based shift-left testing.<ref>{{cite web |url=http://blog.sei.cmu.edu/post.cfm/using-v-models-testing-315 |title=Using V Models for Testing |author=Donald Firesmith | date=11 November 2013 |accessdateaccess-date=27 March 2015 |archive-date=2 April 2015 |archive-url=https://web.archive.org/web/20150402110448/http://blog.sei.cmu.edu/post.cfm/using-v-models-testing-315 |url-status=live }}</ref>

=== 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<ref>{{cite web |url=https://msdn.microsoft.com/en-us/library/dd286714.aspx |title=Record and Playback Manual Tests |author=Microsoft | date= 2013 |accessdateaccess-date=27 March 2015 |archive-date=2 April 2015 |archive-url=https://web.archive.org/web/20150402113241/https://msdn.microsoft.com/en-us/library/dd286714.aspx |url-status=live }}</ref>), 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|date=April 2016}}

<gallery>

Traditional-Shift-Left.jpg|Traditional shift-left testing

Line 24:

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.

<gallery>

Incremental-Shift-Left.jpg|Incremental shift-left restingtesting

</gallery>

Line 34:

=== 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.{{cn|date=January 2021}}

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.<ref>{{cite web|url=http://www.iiste.org/Journals/index.php/CEIS/article/viewFile/3533/3581 |title=Quality Flaws: Issues and Challenges in Software Development |author1=P Mohan |author2=A Udaya Shankar |author3=K JayaSriDevi |last-author-amp=yes | date=2012 |accessdate=27 March 2015}}</ref>

As illustrated in the following figure, modelModel-based testing moves testing to the left side of the Vs, by testing executable requirements, architecture, and design models. This shift enablesbegins testing to begin almost immediately, instead of waiting a long time (traditional testing), medium time (incremental testing), or a short time (Agile/DevOps) untilfor software onto become available to the right side of the Vs. is available to test. This trend is just beginning.

<gallery>

Model-Shift-Left.jpg|Model-based shift-left testing

Line 43:

== References ==

{{reflist}}

== External links ==

* [https://devopedia.org/shift-left "Shift Left" Devopedia]

{{Software testing}}

[[Category:Software testing]]