3. Scrum Methodology – Testing approaches
Model 1 – Step execution
approach
Test
Dev
Model 2 – Parallel execution
approach
Test
Dev
Model 3 – Purist approach
4. Model 1 – Step execution approach
Test
Dev
Pros
•No tight commitments from DEV team
•QA commitments are independent in nature
Cons
•Breaks the basic rule “Potentially shippable product” of Agile
•Need to maintain DEV, QA ratio of 3:1 for manual and of 1:1 for automation testing
•20-25% buffer is kept aside in each sprint for fixing defects
•Slicing of product owner /functional analyst time
5. Model 2 – Parallel execution approach
Test
Dev
Cons
•Requires tight commitments from Dev team
•QA works on stories committed for the sprint
•Any delays in dev commitment have direct impact on QA commitment
•Wastage of productivity
•QA backlog keeps increasing with each sprint
•Work distribution imbalance
•Need to maintain DEV, QA ratio of 1:1 for manual and automation testing
•Imbalance in DEV, QA ratio will create lower overall commitments
•20-25% buffer is kept aside in each sprint for handling defects
6. Model 3 – Purist approach
•No DEV, QA separation
•Stories are committed by team without ratio consideration
•Full capacity is devoted to productivity leading to higher productivity and no
wastages
•Multi-skilled team
•Ease of management
•TDD approach can be used for continuous integration
7. Challenges with Purist approach
•Lack of multi-skilled asset in market
•Lack of Indian IT Industry will to move towards purist approach
•Different growth paths
•Different salary structures
•Different appraisal parameters
•Different selection criteria
•Lack of will to work on DEV or QA tasks
•Fear of being tagged ‘Developer’ or ‘Tester’
•Fear of being unusable in Indian IT job market
8. Step execution Parallel execution Purist
Productivity Medium Low High
Wastage Medium High Low
Engineering skill set Good Good Best
Ease of Medium Low High
management
Time management Medium Low High
Product High Low Low
owner/Functional
Analyst time
distribution
Resourcing High High Medium
requirements
No tight commitments from Dev team DEV team work commitment are independentQA commitment are independent in nature QA commitment are independent in nature and are dependent only on the work delivered in previous DEV sprints.Slicing of product owner/functional analyst time PO/FA needs to explain the same set of requirements twice.
Requires tight commitments from Dev team tight commitments from dev team as QA team has dependency on DEV commitmentQA works on stories committed for the sprint Tight coupling of DEV and QA workWastage of productivity Productivity wastage either waiting for work from DEV or re-work by DEV due to defectsQA backlog keeps increasing with each sprint Direct impact of tight coupling. QA focus limits to work in the sprint and backlog increases with any deliver variations from Dev teamWork distribution imbalance Considering 3 DEV and 1 QA in a sprint of 8 days, we have DEV capacity of 3*8 and QA capacity of 1*8. With dev deliveries planned for release three days prior to sprint demo, QA is left with 3 days to test work committed for 8 QA days.Need to maintain DEV, QA ratio of 1:1 for manual and automation testing Higher QA requirement due to work distribution imbalanceImbalance in DEV, QA ratio will create lower overall commitments To counter work distribution imbalance, the dev commitments get reduced.
