Your SlideShare is downloading. ×
Gl scrum testing_models
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Gl scrum testing_models

238
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
238
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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.
  • Transcript

    • 1. Scrum Methodology– Testingapproaches Vikas Mangla Senior Consultant – Engineering vikas.mangla@globallogic.com Owner, Scrum Alliance, Delhi Circle (Registered Scrum Alliance User Group) http://www.scrumalliance.org/user_groups /157
    • 2. Agenda•Introduction to testing approaches in Scrum•Pros and Cons of approaches•Discussion
    • 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 PuristProductivity Medium Low HighWastage Medium High LowEngineering skill set Good Good BestEase of Medium Low HighmanagementTime management Medium Low HighProduct High Low Lowowner/FunctionalAnalyst timedistributionResourcing High High Mediumrequirements
    • 9. Questions?
    • 10. Thank You