Writing Tests before Development
Shift Left Testing: Write tests before you do development
The “shift left” testing movement is about pushing testing toward the early stages of software development. By testing early and often, a project can reduce the number of bugs and increase the quality of the deliverables. The goal is to not find any critical bugs during the deployment phase that require code patching.
Shift-left testing activities include:
- Testers helping developers implement unit testing
- Planning, creating, and automating integration test cases
- Planning, creating, and employing virtualized services at every stage and component level
- Gathering, prioritizing, and processing feedback
4 Types of shift-left testing:
- Traditional Shift Left Testing moves the emphasis of testing lower down (and therefore slightly to the left) on the right hand side of the V. Instead of emphasizing acceptance and system level testing (e.g., UI testing with record and playback tools), traditional shift left concentrates on unit and integration testing (e.g., using API testing and modern test tools). The transition to traditional shift left testing has largely been completed.
Takeaways:
This model is already history as teams are moving towards scaled-agile rather than traditional V-model
2. Incremental Shift Left Testing. Few modern software-reliant projects use a strict waterfall development cycle. As shown in Figure below, 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.
Takeaways:
Again tradition waterfall is generally no longer followed, unless a specialised need to do so.
3. Agile/DevOps Shift Left Testing. As shown in 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 Figure below 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.
Takeaways:
This is what we follow at DK! With scaling-agile sprint model as well as using TDD to write automation in early phase of sprints. We not only follow agile shift-left (or developmental cycles) but also maintaining the quality in DevOps shift-left testing which includes operational testing of system once the system is in operation (e.g. incident management, sonarqube score) This certainly is preferred over traditional models but the desired and most ideal shift-left approach is below, model based.
4. 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. As shown in Figure below, 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 and will become increasingly popular as executable models and associated simulation/testing tools become more widely available.
Takeaways & conclusion:
This is an ideal and holy-grail of the topmost quality that can be achieved in a project, certainly followed at tech-giants like Google. What model-based shift left really means is- we must include QA right from the beginning of decisions on product requirements and architectural designs, keeping QA as the first-class candidate. Thus what we will achieve is a model based shift-left for testing every stage like requirements, architecture, and design models etc. without any delay to feedback.
Like to tinker and learn through trials and errors? We might use your quirky mind in our team! Join us in making the next life-centric digital solutions
