Download to read offline
Uploaded byOri Bendet
Testing Your Software Testers
The document discusses the importance of evaluating software testers and highlights key metrics for assessing testing effectiveness. It emphasizes that while the total number of defects is less relevant, escaped defects and the time taken to test are critical for ensuring quality. The focus is on improving testing efficiency and defect resolution to enhance software quality.
More Related Content
![Karnacki wearables 3_ways-20150402[1]](https://cdn.slidesharecdn.com/ss_thumbnails/karnackiwearables3ways-201504021-150330145347-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Testing Your Software Testers
![[TestWarez 2017] Od testowania do monitoringu jakości – wyzwania Continuous ...](https://cdn.slidesharecdn.com/ss_thumbnails/blaszakmichalprezentacjatestwarez2017engfinal-180125202316-thumbnail.jpg?width=640&height=640&fit=bounds)
Testing Your Software Testers
- 1.
- 2. ABOUT ME 6y in HPESoftware in various managerialQA rolesToday– Inbound PM for a new cloud offering
- 3. Largest Pharm. Customer inEurope Critical Defect in Diaper
- 4. Academia vs Industry(=the Real World) Academia Industry
- 5. The Real World… Westill have testers! And we love them!
- 8. So why Test yourTesters?
- 10.
- 11. The Metrics that don’t matter Total# of defects • How many defects does your application currently have that are open • The quantity of defects is no longer as relevant as once was Direct coverage • Test coverage of a feature (manual/automated) • ”Done is done” Unit testing coverage • % of code covered by unit tests • The majority of defects are detected during integration testing and end-to-end testing
- 12. The Metrics that Really matter %of escaped defects • Escaped defects are those that are missed by the tester and found by the end user • Ensures that you’re focusing on the most defects and areas that are important to the end Time to Test • Getting from ‘in-testing’ to ‘done’ • Measuring the efficiency of the tester and how slowly or quickly they are completing tasks. Defect resolution time • Time it takes a defect to be fixed and verified • The majority of defects are detected during integration testing and end-to-end testing
- 13.
- 15.
Editor's Notes
- #12 Total number of defects – how many defects does your application currently have that are open. the quantity of defects is no longer as relevant as it once was. You may prefer that a single bug in your application critical path will be found and solved quickly on the spot rather than the other 40 that get logged. Direct coverage - This is the automated and/or manual test coverage of a feature. In agile, what’s done is done; there is no possibility of missed coverage. If any feature is not covered by tests in a particular sprint, it will not be considered ‘done’, and will be moved to the next sprint until it’s completed. Unit testing coverage - Measuring unit testing coverage doesn’t necessarily contribute to the quality of the product. Even if you do have high unit test coverage, you’re still not guaranteed high quality in the final product, as the majority of defects are detected during integration testing and end-to-end testing, which is done after the unit tests have run.
- #13 Percentage of high/critical and escaped defects - Escaped defects are those that are missed by the tester and found by the end user. The key is making sure the tester is focused on what really matters to the customer. This KPI ensures that you’re focusing on the most important defects and areas that are important to the end user Time to test - This is the time it takes a backlog item to get from ‘in-testing’ to ‘done’. We found this to be an important KPI for measuring the efficiency of the tester and for determining how slowly or quickly they are completing tasks. Defect resolution time - this KPI measures and qualifies the tester’s responsibility and ownership for their bugs. Our responsibility as a QA team looking for quality is to track all of the resolution time, and not just the time it takes to find the bug, or verify the fix. We have to track and make sure the bug was fixed the way it was supposed to be fixed, and to close out the issue in a reasonable time to satisfy users. Percentage of rejected defects - These are defects that are found in the product but not accepted by the developer as defects. A large number of rejected defects indicates whether or not the developer and tester are on the same page about the feature’s functionality and its purpose.