To Measure or Not to Measure? That Is the Question
summary
Compares concrete metrics and outcomes: defect rates by environment (Dev vs staging), look to book ratio, regression suite runtime and stability, and a baseline of how many user journeys are automated and reliably run; finds manual testing sometimes finds more bugs because the automation framework is brittle; measures mean time to green, PR review size/rate and speed of development; produces a one‑page state of quality report with three action items and drops metrics that don’t change outcomes.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:47Metrics in quality engineering
- 3:18Defining quality
- 6:29Process and team metrics
- 7:33Engineering and review metrics
- 8:36Release and defects
- 10:01Accelerate and DORA metrics
- 10:43Pitfalls of defect rates
- 13:11Test automation and pyramid
- 15:58Regression tests limits
- 17:02Development speed and velocity
- 18:50Mean time to green
- 21:15Acceptance criteria and BDD
- 22:17PR review size
- 24:25Choosing metrics
- 26:13Actionable reports
- 29:04Avoiding blame culture
- 31:51Conclusion and key takeaways
- 35:10Q&A
related talks
31mMeasure it or it didnt happen
39mTest Metrics – a thread or a threat
14mEssential Metrics for the Quality Assurance
29mYour Metrics Are Lying: How to Stop Reporting and Start Learning
34mAnatomy of a Testing and QA Audit of a Software Project
24mThe more we test, the worse?
41mThe Tester’s Guide to Quality
45mMaking your tests visible: displaying relevant test metrics in your projects