Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile testing for large projects


Published on

real examples for agile testing on large software development projects.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Agile testing for large projects

  1. 1. Agile Testing for Large ProjectsA practical ExmapleLiang 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” practiceConforming To XP
  5. 5. ∗ Detailed documentation required∗ Use professional testers for full acceptance test (Usertest)∗ 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 simulationVariation To XP
  6. 6. ∗ Everyone tests∗ Developer∗ Business analysis∗ Customer∗ Product size = test size∗ Untested work = no workTest Design and Execution
  7. 7. ∗ Eliminate dedicate tester bottleneck∗ Increase developer test awareness  more cornercase thinking  better quality code∗ coding for testability in natureEveryone tests
  8. 8. ∗ Overall development progress = testing progress∗ Test size is more correlated with complexity than lineof code∗ Strong signal to the whole team: only features after afully regression at each iteration care counted asdelivered 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 isimportant∗ 33% of developer are very interested or interested intaking a lead role in acceptance test∗ 60% of developers are interested in leading system testUntested work = no work
  10. 10. ∗ Ease testing bottleneckCode less, Test more
  11. 11. ∗ Isolation claims∗ Testers should be separated from developer∗ Only test on specifications, not something “unofficiallytold” by developer∗ Testers need not to be affected by developer words∗ Interaction∗ Shall we do more interaction between developers andtesters?Interaction or Isolation
  12. 12. ∗ Isolated testers only found minor defects on thisproject (developers did more testing already)∗ 2 minor bugs in 2 weeksInteraction or Isolation - finding
  13. 13. ∗ Integrate testing and coding∗ Testing and coding time are usually equal∗ Example : 5 hours specification, 10 hours coding, 10 hourstestingActive Planning
  14. 14. ∗ Regression as global effort – requires separate planning∗ Run on each iteration’s last day∗ Workload divided among each team membersActive Planning
  15. 15. ∗ Allocate bug-fix time globallyActive Planning
  16. 16. ∗ Team centered approach∗ Fix Defects ASAPDefects Management
  17. 17. ∗ Anyone in team can open∗ Anyone in team can close∗ Anyone in team can assign∗ Sit-together reduce junk and duplicate defectsTeam 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 fixedSummary