Agile testing for large projects

313 views
248 views

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
313
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Agile testing for large projects

  1. 1. Agile Testing for Large Projects A practical Exmaple Liang Gao
  2. 2. ∗ 以色列空军信息管理系统 ∗ Mission Critical ∗ 整个项目全部采用 XP 开发 概况
  3. 3. ∗ 以色列空军信息管理系统 ∗ 负责以色列空军日常运作与信息安全 ∗ 得到党和国家领导人的多方关注 ∗ Mission Critical ∗ 整个项目全部采用 XP 开发 概况
  4. 4. ∗ No “Deliver to QA“ ∗ No “Meeting the QA criteria for delivery” ∗ No ”Bug Priority” ∗ Short release ∗ Fully test in every two weeks ∗ Developer perform all regression at every cycle ∗ All Bugs fixed in each cycle ∗ “Planning Game” practice ∗ XP’s “Whole team” and “Site-together” practice Conforming To XP
  5. 5. ∗ Detailed documentation required ∗ Use professional testers for full acceptance test (User test) ∗ TDD (test driven development) ∗ 1st line of code is a test case ∗ Test automation at the every step of the development ∗ Unit test ∗ Real user simulation Variation To XP
  6. 6. ∗ Everyone tests ∗ Developer ∗ Business analysis ∗ Customer ∗ Product size = test size ∗ Untested work = no work Test Design and Execution
  7. 7. ∗ Eliminate dedicate tester bottleneck ∗ Increase developer test awareness  more corner case thinking  better quality code ∗ coding for testability in nature Everyone tests
  8. 8. ∗ Overall development progress = testing progress ∗ Test size is more correlated with complexity than line of code ∗ Strong signal to the whole team: only features after a fully regression at each iteration care counted as delivered product size. Product size = test size
  9. 9. ∗ In all channels under all conditions ∗ In each iteration review, untested work = failure ∗ After 2 releases ∗ 90% of developer think acceptance and system test is important ∗ 33% of developer are very interested or interested in taking a lead role in acceptance test ∗ 60% of developers are interested in leading system test Untested work = no work
  10. 10. ∗ Ease testing bottleneck Code less, Test more
  11. 11. ∗ Isolation claims ∗ Testers should be separated from developer ∗ Only test on specifications, not something “unofficially told” by developer ∗ Testers need not to be affected by developer words ∗ Interaction ∗ Shall we do more interaction between developers and testers? Interaction or Isolation
  12. 12. ∗ Isolated testers only found minor defects on this project (developers did more testing already) ∗ 2 minor bugs in 2 weeks Interaction or Isolation - finding
  13. 13. ∗ Integrate testing and coding ∗ Testing and coding time are usually equal ∗ Example : 5 hours specification, 10 hours coding, 10 hours testing Active Planning
  14. 14. ∗ Regression as global effort – requires separate planning ∗ Run on each iteration’s last day ∗ Workload divided among each team members Active Planning
  15. 15. ∗ Allocate bug-fix time globally Active Planning
  16. 16. ∗ Team centered approach ∗ Fix Defects ASAP Defects Management
  17. 17. ∗ Anyone in team can open ∗ Anyone in team can close ∗ Anyone in team can assign ∗ Sit-together reduce junk and duplicate defects Team centered approach
  18. 18. ∗ Average time to fix a defect is about 1 hour ∗ Remain constant even project grows with complexity ∗ No need to prioritize bugs! Fix Defects ASAP
  19. 19. Fix Defects ASAP
  20. 20. Agile Practice Cost of Curve
  21. 21. Average Bug Fix Time Per- iteration
  22. 22. 平均 Bug 寿命
  23. 23. ∗ A successful project ∗ Full regression and testing at each iteration ∗ All bugs are fixed Summary

×