|
| 1 | +--- |
| 2 | + |
| 3 | +title: "Shift Left Approach to Testing" |
| 4 | +excerpt: "How to ensure better code and higher product quality" |
| 5 | +tags: Testing, Quality Assurance |
| 6 | +authors: |
| 7 | +- Anjali Goyal |
| 8 | +header: |
| 9 | + teaser: /assets/images/post/shift-left1.png |
| 10 | + teaser_alt: Quality Assistance Approach |
| 11 | +category: Software Quality Assurance |
| 12 | + |
| 13 | +--- |
| 14 | + |
| 15 | +“**Shift left**” testing movement is about pushing testing towards the early stages of Software Development Life Cycle. |
| 16 | + |
| 17 | +By testing **early and often**, a project can reduce the number of bugs and increase the quality of the code. |
| 18 | + |
| 19 | +{% include |
| 20 | +components/figure.html |
| 21 | +url="/assets/images/post/shift-left-intro.png" |
| 22 | +%} |
| 23 | + |
| 24 | +## **Traditional Quality Model vs Shift Left Model** |
| 25 | + |
| 26 | +Up until the late 1990s, stakeholders favored quality only at the latest phases of the software development lifecycle - more specifically, the testing and deployment phases. |
| 27 | + |
| 28 | +When testing is paused until the end of development, any bugs that do show up will usually be more difficult to fix. In severe cases, their resolution needs the software to be reworked in its entirety. Consequences of such an approach would be: |
| 29 | + |
| 30 | +- Poor quality product delivered to customer, prone to critical bugs. |
| 31 | +- Increase in cost, since the software needs to be sent back and reworked from scratch. |
| 32 | +- Increased time to market since such reworks will take longer to complete. |
| 33 | + |
| 34 | +Worst case, developers have to redesign the application. |
| 35 | + |
| 36 | +{% include |
| 37 | + components/figure.html |
| 38 | + url="/assets/images/post/shift-left2.png" |
| 39 | + description="Traditional vs Shift Left Quality Model" |
| 40 | +%} |
| 41 | + |
| 42 | +So, here we are with problem statement from Traditional Quality Model |
| 43 | + |
| 44 | +**🚨The problem** - Poor quality product resulting in delayed time to market. |
| 45 | + |
| 46 | +**🎯The goal** - Better code, high quality product and faster time to market. |
| 47 | + |
| 48 | +**💡The solution** - Adopt **SHIFT LEFT APPROACH** to Testing |
| 49 | +<br> |
| 50 | +<br> |
| 51 | + |
| 52 | +## Shift Left Approach for FRs within development cycle |
| 53 | + |
| 54 | +Presenting to you, the **Quality Assistance Approach**(as we call in BB) which emphasises on early testing and leaving minimal room for critical/ blocker issues by the end of the development cycle. |
| 55 | + |
| 56 | +{% include |
| 57 | +components/figure.html |
| 58 | +url="/assets/images/post/shift-left3.png" |
| 59 | +description="Quality Assistance Approach in development cycle" |
| 60 | +%} |
| 61 | + |
| 62 | +Navigating phase by phase: |
| 63 | +- As the development cycle starts, QAs to write high-level test cases against each user story during the planning day or the 1st day of the development cycle |
| 64 | +- QAs to then organise 'Kick-off' session (preferably the next day) where tests are reviewed with developers and other stakeholders(such as BAs or SAs) to ensure everyone is on the same page for feature Requirements and Acceptance Criteria |
| 65 | +- After the Kick-off session, as the development of the feature takes place, QAs focus on developing test automation scripts |
| 66 | +- After the features are developed, Dev sets up a 'Review' session with QA before pushing code to the test environment(even before creating a PR). Note that this is not an actual testing phase, but all bugs found during review can be fixed immediately by the Dev |
| 67 | +- If QA and Dev are both happy with the developed feature, then Dev releases the code for further testing and QA starts test execution |
| 68 | + |
| 69 | +Key benefits of above approach within the development cycle: |
| 70 | + |
| 71 | +- Development team is aligned on the requirements |
| 72 | +- Leaves minimal room for critical/blocker bugs |
| 73 | +- QA can inform the developers about issues in the review session which can be fixed right away |
| 74 | +- QA knows where to focus when the functionality is released to test |
| 75 | +- QAs have increased time for exploratory testing |
| 76 | +- QAs have increased time for UI automation within the development cycle |
| 77 | +<br> |
| 78 | +<br> |
| 79 | + |
| 80 | +## Shift Left Approach for NFRs |
| 81 | + |
| 82 | +**Non-Functional Requirements(NFRs)** of a product define the systems operational attributes like **performance, accessibility, reliability, usability, scalability, load, stress, recoverability, security, localisation, etc**. |
| 83 | +Besides being operational and compliance must-haves, NFRs are also essential contributors to the value proposition of the product. These factors can be a key differentiator of the product in the market. |
| 84 | + |
| 85 | +In traditional quality model, often the release roadmaps are designed in such a way that the NFRs are slotted for last few weeks of the delivery. The teams end up testing NFRs in a hurry to meet the release deadlines, leading to low confident, risky releases with a compromise in quality. |
| 86 | +Hence, NFR testing must also shift-left and prep must start right from Requirement phase of SDLC. |
| 87 | + |
| 88 | +{% include |
| 89 | +components/figure.html |
| 90 | +url="/assets/images/post/shift-left4.png" |
| 91 | +description="Shift Left Approach for NFRs" |
| 92 | +%} |
| 93 | + |
| 94 | +_Requirement phase:_ Identify the NFRs and prioritise them |
| 95 | + |
| 96 | +_Design phase:_ |
| 97 | +- Define and agree on the DoD of the product |
| 98 | +- Capture the NFRs as part of Acceptance Criteria on User Story level |
| 99 | +- Story estimates includes the effort of NFRs |
| 100 | +- System architecture is designed taking NFRs into account. |
| 101 | + |
| 102 | +_Development phase:_ |
| 103 | +- NFR test scenarios are written considering Acceptance Criteria |
| 104 | +- Kickoff session should include NFR test scenarios |
| 105 | + |
| 106 | +_Test phase:_ NFR execution is performed along with Functional test execution, before moving the User Story to “QA Done” |
| 107 | + |
| 108 | +_Production & Maintenance phase:_ Release is deployed in production. All FRs and NFRs are complete. Thus, reducing the risk of NFRs impacting delivery timelines. |
| 109 | +<br> |
| 110 | +<br> |
| 111 | + |
| 112 | +## Key benefits of Shift Left Approach to Testing |
| 113 | + |
| 114 | +{% include |
| 115 | +components/figure.html |
| 116 | +url="/assets/images/post/shift-left5.png" |
| 117 | +description="Key benefits of Shift Left Approach" |
| 118 | +%} |
| 119 | + |
| 120 | +- Reduced costs involved in Development and Testing as bugs detected earlier are cheaper to fix. |
| 121 | +- Reduced risk of NFR bugs impacting the delivery timeline. |
| 122 | +- Increased efficiency in the software development process as effective utilisation of time and resources. |
| 123 | +- Early Bug Detection ensures Better Code and Product Quality. |
| 124 | +- Offers a competitive advantage in the market as higher quality product is delivered. |
| 125 | +- Enhanced Test Coverage, considering both functional and NFRs are covered as part of test suite and the application is evaluated for all its features. |
| 126 | +- QAs have more room for automation and exploratory testing within the development cycle. |
| 127 | + |
| 128 | + |
| 129 | + |
| 130 | + |
0 commit comments