Dev QA Balance
From AgileOpenNorthwest
Time & Place: Wednesday, Feb 10, 2010 8:00 am Lopez C
Title: Dev / QA Balance
Host: Greg Myers
Contents |
QA - Dev Imbalance is Common
- Most participants experienced delay between Dev complete and QA release in their Sprints
- 1 to 2 weeks was common
- Some organizations staggered Dev and QA between 2 Sprints
- Some participants had Dev working on stories for next Sprint while QA finished testing
Is it bad if Dev and QA is unbalanced?
- No
- If there is no real problem, maybe it is not so bad
- Common experience
- QA needs time to test the final release
- No time to automate during the Sprint
- Yes
- Delayed testing takes longer
- Devs get interrupted from their new tasks
- Code is cold, taking longer to debug
- QA Spends extra time
- confirming, batching bugs for Dev efficiency
- fewer Dev / QA conversations
- QA spends less up-front time with new stories
- less design input
- less familiar with code when testing
- One participant said they got more time up-front by staggering Dev and QA
- Delayed testing takes longer
Strategies for Balance
- Eliminate specializations when possible
- Dev helps test at end
- Smaller stories
- Test automation
- write test cases first
- write tests
- write just enough code to pass tests
- flesh out the code
- QA writes automated tests during the Sprint
- FIT tests for object structure
- Co-locate Dev and QA team members
- Early drops to a sandbox so QA can get early looks
- Devs and QA sit together and work on UAT tests, test coverage
Metrics
- Some teams don't track any QA metrics
- Some teams track bugs once Dev compete is achieved
- some teams track bugs post-deployment
Organizational Impediments
- No or limited integration or staging environments
- Limited automation resources
- Limited QA resources
- Limited budget
- Requirements for multi-week acceptance testing
- Lack of trust between Dev / QA
- Lack of access to Devs
- QA must repeat all Dev testing
Black Box Testing
- Tie experiential testing to "most likely" paths - not just random effort
- based on risk and frequency of user access to features
- helps to have error trapping standards that will catch low-frequency events, so don't have to test
Advantages of Automation
- Better coverage of one-offs
- errors don't creep back in
- tests run more quickly
- tests can run off-hours
- frees up time for black-box testing
