Slide 1

Slide 1 text

GoBusiness Sharing GDS Quality Engineering Chapter 5th March 2020 1 git: @sshinnee

Slide 2

Slide 2 text

Contents 1. Challenges We Faced 2. Overcoming Them 3. Things We Learnt 2 git: @sshinnee

Slide 3

Slide 3 text

Challenges 3 git: @sshinnee

Slide 4

Slide 4 text

The Social Challenges 4 git: @sshinnee

Slide 5

Slide 5 text

Siloed Roles 5 git: @sshinnee

Slide 6

Slide 6 text

6 https://encrypted-tbn0.gstatic.com/images?q=tbn%3AANd9GcSTD4vXieH202pxLsSMcky9ei6Pf-yBI29k-89c3_EUFQgojl01

Slide 7

Slide 7 text

The Technical Challenges 7 git: @sshinnee

Slide 8

Slide 8 text

Low Fidelity E2E 8 git: @sshinnee

Slide 9

Slide 9 text

9 https://ak7.picdn.net/shutterstock/videos/5015357/thumb/3.jpg

Slide 10

Slide 10 text

10 git: @sshinnee

Slide 11

Slide 11 text

Challenges A. Siloed Roles a. Slow Feedback b. Weaker Quality B. Patchy End To End a. Difficult to Maintain b. Low Fidelity 11 git: @sshinnee

Slide 12

Slide 12 text

How We Overcame Them: Challenge 1 12 git: @sshinnee

Slide 13

Slide 13 text

A Testing-Centric Approach 13 git: @sshinnee

Slide 14

Slide 14 text

A Testing-Centric Approach A. Test Cases to be written before Development starts B. Developers to do self-testing before it’s Ready For QA C. Anyone can pick up testing of features D. Testing is a team sport 14 git: @sshinnee

Slide 15

Slide 15 text

Test Cases Before Development - Allows us to realize what we don’t understand about the feature - Clarity on target Why? 15 git: @sshinnee

Slide 16

Slide 16 text

Everyone Tests Why? - Greater Ownership over the Product 16 git: @sshinnee

Slide 17

Slide 17 text

How We Overcame Them: Challenge 2 17 git: @sshinnee

Slide 18

Slide 18 text

Less Is More 18 git: @sshinnee

Slide 19

Slide 19 text

Less is More A. Deletion of Unstable Code B. Flows Rather Than Functionality 19 git: @sshinnee

Slide 20

Slide 20 text

badtests.txt 20 git: @sshinnee

Slide 21

Slide 21 text

Flows, not Functions Why? A. Promotes Reusability B. Promote Readability, not Verbosity or Succinctness a. DAMP not DRY 21 git: @sshinnee

Slide 22

Slide 22 text

Data-PO-Flow How? A. Repetition in Flows, not Functions B. Page Objects to mimic Front-End a. promote Application Understanding b. prevent duplicate code C. Have Best Practices for Standardization 22 git: @sshinnee

Slide 23

Slide 23 text

Code Walkthrough 23 git: @sshinnee

Slide 24

Slide 24 text

Best Practices In Code 1. Strict Model 2. Choose a Convention to Prevent Astonishment 24 git: @sshinnee

Slide 25

Slide 25 text

Less is More A. Deletion of Unstable Code B. Flows Rather Than Functionality a. Promoting Reusability b. Promoting Readability, not Verbosity or Succinctness i. DAMP not DRY C. Data - Page Object - Flow Structure a. Repetition in Flows, not Functions b. Page Objects to mimic Front-End, promote Application Understanding, prevent duplicate code i. We can do reuse this way c. Have Best Practices for Standardization 25 git: @sshinnee

Slide 26

Slide 26 text

Learnings A. Testing is a Team Effort B. Quality is a Team Effort C. Testing Pyramid a. Unit, Integration and E2E tests should complement each other b. E2E is expensive and kept to the necessary minimum D. Flow-based Functional Scripts 26 git: @sshinnee

Slide 27

Slide 27 text

People want to reuse, but don’t know what exists already 27 git: @sshinnee

Slide 28

Slide 28 text

Standardization helps people find functions - new users can add code into the existing structure with ease 28 git: @sshinnee

Slide 29

Slide 29 text

Good Quality comes from a sense of ownership from the team 29 git: @sshinnee

Slide 30

Slide 30 text

30 https://image.freepik.com/free-vector/factory-robotized-production-line-cartoon_1441-3009.jpg

Slide 31

Slide 31 text

31 https://i.ebayimg.com/00/s/NDA4WDYxMg==/z/Cm8AAOSwAxpdrtEU/$_20.JPG