How not to be a victim (of other peoples’ mistakes)
It’s now more than five decades since the development of computer applications for use in business became widespread. After all of this experience, projects are still going live in poor condition: late, over budget, buggy, all of these or, sometimes, not even making it into production at all. How can this be? Why do testers so often get the blame for these failures, and what can we do about it? In this presentation, Richard Taylor looks at some of the reasons for this. He shows why it goes much deeper than simple coding errors, into some of the core practices of project management and business / systems analysis. But what can testers do about these things – after all, we can only test what we’re given, in whatever time we’re given, can’t we? Richard believes that testers can, in fact, use their unique skills to improve the quality of software, and the effectiveness of our testing, before we take delivery. So, he argues, testers should not be content to be mere victims at the end of the development chain, and he proposes ways in which testers can use their expertise to eliminate some common causes of project failure.
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to How not to be a victim (of other peoples’ mistakes)
Similar to How not to be a victim (of other peoples’ mistakes) (20)
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI)
More from Stowarzyszenie Jakości Systemów Informatycznych (SJSI) (20)
Recently uploaded
Recently uploaded (20)
How not to be a victim (of other peoples’ mistakes)
- 2.
- 3.
- 4. Source: The 2014 IT Disaster Hall of Shame http://origsoft.com/news- desk/2014-disaster-hall-shame/
- 5.
- 6.
- 7.
- 8. debugunplanned dev rework debug Testing schedule in theory: Testing schedule in practice: Analysis & Design Implementation & Execution Planning & Control Evaluate exit criteria & reportIdentify Design Build Analysis & Des Implmt & ExecP & C c&r I&E confirmation and regression test how many test cycles do you have? debug c&r I&E c&r
- 9. debugunplanned dev rework debug Can get even worse: Evaluate exit criteria & report Analysis & D Implmt & Exec c&r I&E confirmation and regression test c&r I&E c&r wait … wait … dbg so we need to be prepared to help the developers
- 10.
- 11. How much do defects cost? 0 2000 4000 6000 8000 10000 12000 14000 16000 18000 requirem ents specification initialtestsystem /acceptance live running Folksam Boehm
- 12.
- 13. Cost of Quality Internal Failure costs – fixing & retesting bugs found Detection costs – static & dynamic testing The testing budget Detection costs – static & dynamic testing Prevention costs – training, prototypes Internal Failure costs – fixing & retesting bugs found External Failure costs – live failures Prevention costs – training, improvements, prototypes
- 14. Cost of Quality Internal Failure costs – fixing & retesting bugs found Detection costs – static & dynamic testing The testing budget Detection costs – static & dynamic testing Prevention costs – training, prototypes Internal Failure costs – fixing & retesting bugs found External Failure costs – live failures Prevention costs – training, improvements, prototypes
- 15.
- 16.
- 17.
- 18.
- 19. plan: end date early design review? then: Extra work delay result: very late big problems later manager: “let’s not bother, we’ll sort it out when we build it” – but, risk that design needs re-writing?
- 20.
- 21.
- 22.
- 23.