Skip to content

Commit 448449d

Browse files
Shift Left Approach to Testing (#55)
* Commit changes for Shift Left Approach to testing * Commit changes for Shift Left Approach to testing * Commit changes for Shift Left Approach to testing
1 parent cdf9687 commit 448449d

File tree

10 files changed

+184
-54
lines changed

10 files changed

+184
-54
lines changed

Gemfile.lock

Lines changed: 49 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -1,26 +1,27 @@
11
GEM
22
remote: https://rubygems.org/
33
specs:
4-
actionpack (7.0.4.3)
5-
actionview (= 7.0.4.3)
6-
activesupport (= 7.0.4.3)
7-
rack (~> 2.0, >= 2.2.0)
4+
actionpack (6.1.7.3)
5+
actionview (= 6.1.7.3)
6+
activesupport (= 6.1.7.3)
7+
rack (~> 2.0, >= 2.0.9)
88
rack-test (>= 0.6.3)
99
rails-dom-testing (~> 2.0)
1010
rails-html-sanitizer (~> 1.0, >= 1.2.0)
11-
actionview (7.0.4.3)
12-
activesupport (= 7.0.4.3)
11+
actionview (6.1.7.3)
12+
activesupport (= 6.1.7.3)
1313
builder (~> 3.1)
1414
erubi (~> 1.4)
1515
rails-dom-testing (~> 2.0)
1616
rails-html-sanitizer (~> 1.1, >= 1.2.0)
17-
activesupport (7.0.4.3)
17+
activesupport (6.1.7.3)
1818
concurrent-ruby (~> 1.0, >= 1.0.2)
1919
i18n (>= 1.6, < 2)
2020
minitest (>= 5.1)
2121
tzinfo (~> 2.0)
22-
addressable (2.8.0)
23-
public_suffix (>= 2.0.2, < 5.0)
22+
zeitwerk (~> 2.3)
23+
addressable (2.8.4)
24+
public_suffix (>= 2.0.2, < 6.0)
2425
autoprefixer-rails (10.4.13.0)
2526
execjs (~> 2)
2627
bootstrap (5.0.2)
@@ -29,25 +30,24 @@ GEM
2930
sassc-rails (>= 2.0.0)
3031
builder (3.2.4)
3132
colorator (1.1.0)
32-
concurrent-ruby (1.1.9)
33+
concurrent-ruby (1.2.2)
3334
crass (1.0.6)
34-
em-websocket (0.5.2)
35+
em-websocket (0.5.3)
3536
eventmachine (>= 0.12.9)
36-
http_parser.rb (~> 0.6.0)
37+
http_parser.rb (~> 0)
3738
erubi (1.12.0)
3839
eventmachine (1.2.7)
3940
execjs (2.8.1)
40-
faraday (1.3.0)
41-
faraday-net_http (~> 1.0)
42-
multipart-post (>= 1.2, < 3)
43-
ruby2_keywords
44-
faraday-net_http (1.0.1)
45-
ffi (1.15.4)
41+
faraday (2.7.4)
42+
faraday-net_http (>= 2.0, < 3.1)
43+
ruby2_keywords (>= 0.0.4)
44+
faraday-net_http (3.0.2)
45+
ffi (1.15.5)
4646
forwardable-extended (2.6.0)
47-
http_parser.rb (0.6.0)
48-
i18n (1.8.11)
47+
http_parser.rb (0.8.0)
48+
i18n (1.13.0)
4949
concurrent-ruby (~> 1.0)
50-
jekyll (4.2.0)
50+
jekyll (4.2.2)
5151
addressable (~> 2.4)
5252
colorator (~> 1.0)
5353
em-websocket (~> 0.5)
@@ -62,10 +62,10 @@ GEM
6262
rouge (~> 3.0)
6363
safe_yaml (~> 1.0)
6464
terminal-table (~> 2.0)
65-
jekyll-category-pages (1.1.1)
65+
jekyll-category-pages (1.1.2)
6666
jekyll (~> 4.0)
6767
jekyll-paginate (~> 1.1, >= 1.0.0)
68-
jekyll-feed (0.15.1)
68+
jekyll-feed (0.17.0)
6969
jekyll (>= 3.7, < 5.0)
7070
jekyll-gist (1.5.0)
7171
octokit (~> 4.2)
@@ -74,9 +74,9 @@ GEM
7474
jekyll-paginate (1.1.0)
7575
jekyll-paginate-v2 (3.0.0)
7676
jekyll (>= 3.0, < 5.0)
77-
jekyll-sass-converter (2.1.0)
77+
jekyll-sass-converter (2.2.0)
7878
sassc (> 2.0.1, < 3.0)
79-
jekyll-seo-tag (2.7.1)
79+
jekyll-seo-tag (2.8.0)
8080
jekyll (>= 3.8, < 5.0)
8181
jekyll-sitemap (1.4.0)
8282
jekyll (>= 3.7, < 5.0)
@@ -85,68 +85,64 @@ GEM
8585
jekyll_asset_pipeline (0.6.2)
8686
jekyll (>= 3.5, < 5.0)
8787
liquid (~> 4.0)
88-
kramdown (2.3.1)
88+
kramdown (2.4.0)
8989
rexml
9090
kramdown-parser-gfm (1.1.0)
9191
kramdown (~> 2.0)
92-
liquid (4.0.3)
93-
listen (3.4.1)
92+
liquid (4.0.4)
93+
listen (3.8.0)
9494
rb-fsevent (~> 0.10, >= 0.10.3)
9595
rb-inotify (~> 0.9, >= 0.9.10)
9696
loofah (2.20.0)
9797
crass (~> 1.0.2)
9898
nokogiri (>= 1.5.9)
9999
mercenary (0.4.0)
100100
method_source (1.0.0)
101-
mini_portile2 (2.8.1)
102101
minima (2.5.1)
103102
jekyll (>= 3.5, < 5.0)
104103
jekyll-feed (~> 0.9)
105104
jekyll-seo-tag (~> 2.1)
106-
minimal-mistakes-jekyll (4.22.0)
105+
minimal-mistakes-jekyll (4.24.0)
107106
jekyll (>= 3.7, < 5.0)
108107
jekyll-feed (~> 0.1)
109108
jekyll-gist (~> 1.5)
110109
jekyll-include-cache (~> 0.1)
111110
jekyll-paginate (~> 1.1)
112111
jekyll-sitemap (~> 1.3)
113112
minitest (5.18.0)
114-
multipart-post (2.1.1)
115-
nokogiri (1.14.3)
116-
mini_portile2 (~> 2.8.0)
113+
nokogiri (1.13.10-arm64-darwin)
117114
racc (~> 1.4)
118-
nokogiri (1.14.3-x86_64-darwin)
115+
nokogiri (1.13.10-x86_64-darwin)
119116
racc (~> 1.4)
120-
octokit (4.20.0)
121-
faraday (>= 0.9)
122-
sawyer (~> 0.8.0, >= 0.5.3)
117+
octokit (4.25.1)
118+
faraday (>= 1, < 3)
119+
sawyer (~> 0.9)
123120
pathutil (0.16.2)
124121
forwardable-extended (~> 2.6)
125122
popper_js (2.11.7)
126-
public_suffix (4.0.6)
123+
public_suffix (5.0.1)
127124
racc (1.6.2)
128-
rack (2.2.6.4)
125+
rack (2.2.7)
129126
rack-test (2.1.0)
130127
rack (>= 1.3)
131128
rails-dom-testing (2.0.3)
132129
activesupport (>= 4.2.0)
133130
nokogiri (>= 1.6)
134131
rails-html-sanitizer (1.5.0)
135132
loofah (~> 2.19, >= 2.19.1)
136-
railties (7.0.4.3)
137-
actionpack (= 7.0.4.3)
138-
activesupport (= 7.0.4.3)
133+
railties (6.1.7.3)
134+
actionpack (= 6.1.7.3)
135+
activesupport (= 6.1.7.3)
139136
method_source
140137
rake (>= 12.2)
141138
thor (~> 1.0)
142-
zeitwerk (~> 2.5)
143139
rake (13.0.6)
144-
rb-fsevent (0.10.4)
140+
rb-fsevent (0.11.2)
145141
rb-inotify (0.10.1)
146142
ffi (~> 1.0)
147143
rexml (3.2.5)
148-
rouge (3.26.0)
149-
ruby2_keywords (0.0.4)
144+
rouge (3.30.0)
145+
ruby2_keywords (0.0.5)
150146
safe_yaml (1.0.5)
151147
sassc (2.4.0)
152148
ffi (~> 1.9)
@@ -156,9 +152,9 @@ GEM
156152
sprockets (> 3.0)
157153
sprockets-rails
158154
tilt
159-
sawyer (0.8.2)
155+
sawyer (0.9.2)
160156
addressable (>= 2.3.5)
161-
faraday (> 0.8, < 2.0)
157+
faraday (>= 0.17.3, < 3)
162158
sprockets (4.2.0)
163159
concurrent-ruby (~> 1.0)
164160
rack (>= 2.2.4, < 4)
@@ -172,13 +168,12 @@ GEM
172168
tilt (2.1.0)
173169
tzinfo (2.0.6)
174170
concurrent-ruby (~> 1.0)
175-
unicode-display_width (1.7.0)
176-
webrick (1.7.0)
177-
zeitwerk (2.6.7)
171+
unicode-display_width (1.8.0)
172+
webrick (1.8.1)
173+
zeitwerk (2.6.8)
178174

179175
PLATFORMS
180-
ruby
181-
x86_64-darwin-19
176+
universal-darwin-22
182177

183178
DEPENDENCIES
184179
bootstrap (~> 5.0.2)
@@ -194,4 +189,4 @@ DEPENDENCIES
194189
webrick (~> 1.7)
195190

196191
BUNDLED WITH
197-
2.2.24
192+
2.3.22

_data/authors.yml

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -59,3 +59,8 @@ Yash Kapila:
5959
name : "Yash Kapila"
6060
avatar : "assets/images/avatars/yash.jpeg"
6161
bio : "Principal Frontend Engineer - Customer Success"
62+
63+
Anjali Goyal:
64+
name : "Anjali Goyal"
65+
avatar : "assets/images/avatars/anjali_goyal.jpg"
66+
bio : "Senior QA Engineer - Customer Success"
Lines changed: 130 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,130 @@
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+
38.6 KB
Loading
24.5 KB
Loading

assets/images/post/shift-left1.png

1020 KB
Loading

assets/images/post/shift-left2.png

237 KB
Loading

assets/images/post/shift-left3.png

213 KB
Loading

assets/images/post/shift-left4.png

13.5 KB
Loading

assets/images/post/shift-left5.png

373 KB
Loading

0 commit comments

Comments
 (0)