Measuring the effectiveness of testing using DDP

Transcription

1 Measuring the effectiveness of testing using Prepared and presented by Dorothy Graham 1 Contents introduction: some questions for you what is and how to calculate it case studies uses, abuses, common concerns and advice 2

2 Questions you may be asked How good is the testing anyway? Can you prove you are doing a good job? Your testing can still be just as good in less time, can t it? (That deadline pressure really didn t matter, did it?) How many bugs have we missed? Is the testing any better for this release? (Have we learned anything?) (Have we really improved our testing?) Are we better or worse in our testing compared compared to how to other we were groups/organizations? last time / last year? 3 : what you need to have do you keep track of defects? defects found in testing different test stages, e.g. system test, user acceptance test different releases e.g. testing for an incremental release in RAD defects found in live running reported by users / customers can you find these numbers from a previous project and your current project? do you have a reasonable number of defects found? if so, you can use to measure your test effectiveness 4

3 Useful measures a useful measure: supports effective analysis and decision making, and that can be obtained relatively easily. Bill Hetzel, Making Software Measurement Work, QED, easy measures may be more useful even though less accurate (e.g. car fuel economy) useful depends on objectives, i.e. what you want to know 5 Contents introduction: some questions for you what is and how to calculate it case studies uses, abuses, common concerns and advice 6

4 How effective are we at finding defects? defects found in testing or defects found testing defects found in testing defects found wards not found -yet start release benchmark point 7 Defect Detection Percentage () defects found by this testing total defects including those found wards "this" testing could be a test stage, e.g. component, integration, acceptance, regression, etc. testing for a function, subsystem or defect type all testing for a system testing of a sprint or increment Note: Capers Jones Defect Removal Efficiency?? not removal but detection - not efficiency but effectiveness 8

5 Effectiveness at finding defects defects found release time 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% defects found in testing: defects found testing: total defects found: 50 = = % 9 example testing live running live % = = = % 10

6 Exercise 1 Exercise 1 The following data has been recorded for a project. Calculate the of each testing stage based on all the defect information. Fault Information Testing stage Official testing module and integration Tool testing & development Number of faults 299 = = = % 40 = = = % Release testing 19 = = = % User Acceptance test 10 = = = % Pilot 9 = = = % Running ( one month) 20 Hint: you don t really need a calculator just round the numbers to the nearest 10 and you will be close enough! Defects found in this stage of testing = Defects found in this and all subsequent stages of testing Dorothy Graham Page 1 of 2

7 Exercise 1 Exercise 1 Solution: Calculation Testing stage No. faults 1) Official testing module and integration % 300 / 400 2) Tool testing & development 40 40% 40 / 100 3) Release testing 19 33% 20 / 60 4) User Acceptance test 10 25% 10 / 40 5) Pilot 9 33% (or 31%) 10 / 30 ( 9 / 29) 6) Running ( one month) 20 n/a How did we get these figures? Remember = Defects found in testing / all subsequent defects Stage 1 Official testing Test stage 1 found approximately 300 defects this is the numerator (top) The sum of all the subsequent stages is = (rounded up) (rounded up) + 20 = 100 So the denominator (bottom of the equation) is = 400 for Stage 1 is therefore 300/400 or 75% Stage 2 Tool testing Test stage 2 found 40 defects this is the numerator (top) The sum of all the subsequent stages is = 20 (rounded up) (rounded up) + 20 = 60 So the denominator (bottom of the equation) is = 100 for Stage 2 is therefore 40/100 = 40% Stage 3 Release testing Test stage 3 found 19 defects (round up to 20) this is the numerator (top) The sum of all the subsequent stages is = (rounded up) + 20 = 40 So the denominator (bottom of the equation) is = 60 for Stage 3 is therefore 20/60 = 33% Stage 4 User Acceptance test Test stage 4 found 10 defects this is the numerator (top) The sum of all the subsequent stages is = 10 (rounded up) + 20 = 30 (29 to be exact) So the denominator (bottom of the equation) is = 40 for Stage 4 is therefore 10/40 = 25% Stage 5 Pilot Test stage 5 found 9 defects (round up to 10) this is the numerator (top) The sum of all the subsequent stages is = 20 (the only remaining stage is live running) So the denominator (bottom of the equation) is = 30 for Stage 4 is therefore 10/30 = 33% (31% if you calculate 9/29) There is no for live running, since the live running total goes into the calculation of all the previous s. Dorothy Graham Page 2 of 2

8 example: ST UAT ST UAT ST UAT ST UAT All test % = 100 = 100 = % example: ST ST UAT ST UAT ST UAT All test % 40% = 100 = 100 = % 14 14

9 example: UAT ST UAT ST UAT ST UAT All test % 40% 33% = 50 = 50 = % example: all test ST UAT ST UAT ST UAT All test % 40% 33% 60% = = 150 = % 16 16

10 Exercise 2 Exercise 2 The following data has been recorded for a project. Calculate the in the columns on the right. The first one has been done as an example. (A calculator may be useful for some of these your mobile phone has one!) Fault Information Release System Test User Acceptance Test running (1 month) ST UAT ST LR UAT LR All test LR Release % 40% 33% 60% Release Release Release How did we get these figures? Release 1 ST UAT: 100 / ( ) = 100 / 150 = 67% ST LR: 100 / ( ) = 100 / 250 = 40% UAT LR: 50 / ( ) = 50 / 150 = 33% (Remember not to include the ST defects here) All test LR: ( ) / ( ) = 150 / 250 = 60% Dorothy Graham www. DorothyGraham.co.uk Page 1 of 2

11 Exercise 2 Exercise 2 Solution: Calculations Release System Test User Acceptance Test running (1 month) ST UAT ST LR UAT LR All test LR Release % 40% 33% 60% Release % 71% 83% 95% Release % 67% 50% 83% Release % 25% 17% 38% How did we get these figures? Release 2 ST UAT: 150 / ( ) = 150 / 200 = 75% ST LR: 150 / ( ) = 150 / 210 = 71% UAT LR: 50 / ( ) = 50 / 60 = 83% All test LR: ( ) / ( ) = 200 / 210 = 95% Release 3 ST UAT: 200 / ) = 200 / 250 = 80% ST LR: 200 / ( ) = 200 / 300 = 67% UAT LR: 50 / ( ) = 50 / 100 = 50% All test LR: ( ) / ( ) = 250 / 300 = 83% Release 4 ST UAT: 50 / ( ) = 50 / 75 = 67% ST LR: 50 / ( ) = 50 / 200 = 25% UAT LR: 25 / ( ) = 25 / 150 = 17% All test LR: ( ) / ( ) = 75 / 200 = 38% Dorothy Graham www. DorothyGraham.co.uk Page 2 of 2

12 in iterative development 40 new sprint/release of Sprint 1 S of Sprint 2 S = 40 = 80 % 50 of Sprint 1 S3 = = 73 % = = 58 % 17 Contents introduction: some questions for you what is and how to calculate it case studies uses, abuses, common concerns and advice 18

13 Case studies from clients 1 mo year 1 70% year 2 92% 10 mo 50% est Finance (insurance) System Test Group = 38% (before performance testing) Priority 1 & 2 only: = 31% Operating system 23% to 87% by application Defects: 1 / / 200 Scientific software (chemical analysis) Not useful for low numbers of defects 19 Summary for AP Europe 20

14 Information Technology Conclusions UAT more variable than ST mainly personnel Target zone for ST : 75-90% Factors behind the figures size, complexity, tester experience, time, documentation whether UAT started before ST was finished where on the S-curve when stopped Figures don t tell you cost, severity of those you missed cost of finding 30 stopped here? or here? /12/01 08/12/01 09/12/01 10/12/01 11/12/01 12/12/01 13/12/01 14/12/ Summary for AP Europe Project or App. Months Status Comments Before New Testing Process S4 50% ESTIMATED After New Testing Process R1 3 81% FINAL Major re-engineering LBS 4 91% FINAL CP 7 100% FINAL Reporting System DS 3 95% FINAL APC 4 93% FINAL ELCS 4 95% FINAL Eur impl. of US system SMS 3 96% FINAL Enhancement Release C 4 96% FINAL E7 (US) 5 83% FINAL Global Enhancements E7 (Eur) 1 97% Global Enhancements Source: Stuart Compton, Air Products plc 22

15 Rolling Software Testing Defect Detection Percentage Measure (rolling quarterly produced values looking back four quarters) Period under review # Projects Analysed Target Defects in Testing Total Defects Prod'n Bugs Historical Estimate n/a 50 Rolling 1 Qtrs to Q1 Y1 2 n/a Rolling 2 Qtrs to Q2 Y1 1 n/a Rolling 3 Qtrs to Q3 Y1 1 n/a Rolling 4 Qtrs to Q4 Y1 2 n/a Rolling 4 Qtrs to Q1 Y Rolling 4 Qtrs to Q2 Y Rolling 4 Qtrs to Q3 Y Rolling 4 Qtrs to Q4Y Rolling 4 Qtrs to Q1 Y3 90? Rolling 4 Qtrs to Q2 Y3 90? Rolling 4 Qtrs to Q3 Y3 90? Rolling 4 Qtrs to Q4 Y3 90? Source: Stuart Compton, Air Products plc 23 Anonymous client all systems history of this ST UAT ST UAT ST LR UAT LR All LR Extreme % 31% 92% 95% Ultimate % 30% 85% 90% Professional % 40% 89% 94% Realistic % Idiotic % 64% 96% 98% Total % 36% 92% 95% 24

16 Anonymous client (telecoms) % 98.00% not yet stable decline why? Test Rel defects running % 96.00% % 94.00% % % 92.00% % 90.00% test process improvement % 88.00% % % Release % 25 Contents introduction: some questions for you what is and how to calculate it case studies uses, abuses, common concerns and advice 26

17 benefits can highlight test process improvements the effect of severe deadline pressure the impact of overlapping test phases can raise the profile of testing can help predict future defect levels is applicable over different projects reflects testing process in general can give on-going monitoring of testing 27 Uses of when you know test & production defects calculate to monitor the effectiveness of testing in finding defects for different test stages (e.g. ST, UAT) in different releases when you know your prediction: once you know your typical predict the number of production defects (e.g. when software is released) NOTE: not an exact science, but useful to set expectations! 28

18 Prediction of production defects Defects found so far 66% 20 50% 20 80% 20 Predicted defects not found yet Abuses of monitoring individuals or too small a group or timeframe using only other metrics are also important blame the testers if is low prediction only an indication take it with a grain of salt distorted reporting e.g. testers report the same defect 10 times don t report that, it ll make me look bad 30

19 When NOT to use when you don t have many defects in test or in production (i.e. very high quality software) your defect tracking is immature, purely subjective, untrustworthy, or non-existent the software products you produce are never used by anyone (no live running) it doesn t matter how many defects are in them it is impossible to get data on defects found in live running (difficult is OK!) you re not interested in improving 31 What does it mean? is very high ( > 95%) testing is very good? system not been used much yet? next stage of testing was very poor? e.g. ST looks good but UAT was poor, ST UAT is high but live running will find many defects! is low (< 60%) testing is poor? requirements were very poor, affecting tests? poor quality software (too many to find in the time)? deadline pressure testing was squeezed? 32

20 Options for measuring what to measure simplest: all test defects / all defects so far by severity level how "deep" to go? deeper levels give more detailed information deeper levels more complex to measure advice: start simple simple information is much better than none learn from what information you have 33 Technical aspects what time frame for defects found in live? this is arbitrary / whatever makes sense for you many people use 1 month, some use 3 or 6 months can I measure of different test stages? any stage where you have defects that came wards but don t measure individual people!! can I use in agile development? yes: choices accumulate, or measure until next release what if different defect tracking systems? ok to combine if consistently recorded 34

21 Accuracy of defect data most common stumbling block what about duplicates? what about enhancement requests? what if some aren t really defects? the same answer always applies it doesn t matter how you do it as long as you do it the same way each time! most useful aspect of trends, changes over time and why 35 The technical person s trap we re testers we can see all the problems! you may think of lots of problems with this metric yes, (as any measure) can be mis-used but that doesn t mean it can t be useful take the high level view, warts and all, computed simply and consistently, can help you monitor your testing processes and show the effects of both good and bad things 36

22 How to start using suggested first step calculate for a release that is now live what to measure first? most people start with System Test consider looking at highest severity only to start or two s, one for high severity, one for all defects getting data from live running if you don t normally have live defect data, ask for it data collection & calculation should be easy / automatic get your test management tool or defect tracking tool to calculate it for you automatically 37 Summary: key points requires counts of defects but does not need great accuracy is a useful measure easy to calculate based on defect data you probably already have can tell you how effective your testing efforts are and how other things affect it - discussion about 38