Mean Time to Detect (MTTD) and Repair (MTTR)
MTTD and MTTR are time-based metrics borrowed from reliability engineering that measure the efficiency of defect management. Together they tell you: how quickly are defects being found, and how quickly are they being resolved? These metrics are particularly valuable for identifying bottlenecks in the defect workflow and setting realistic expectations for release timelines.
MTTD - Mean Time to Detect
- Definition: Average time from when a defect was introduced into the code to when it was first discovered by testing
- Formula: MTTD = Sum of (detection date - introduction date) for all defects / Number of defects
- Estimation: The exact introduction date is rarely known - estimate it as the date the feature was declared 'coding complete' by the developer
- Interpretation: Low MTTD = defects found quickly (shift-left working, continuous testing catching issues early). High MTTD = defects are living in the system for days or weeks before discovery - they accumulate, interact with each other, and the context for fixing them is lost
- Improving MTTD: Continuous integration with automated tests (detects defects within hours of introduction), frequent QA testing during development rather than waiting for feature completion, Three Amigos sessions (detects requirement defects before coding even starts)
MTTR - Mean Time to Repair
- Definition: Average time from when a defect is detected and logged to when it is fixed, re-tested, and closed. Measures the efficiency of the defect resolution process
- Formula: MTTR = Sum of (close date - open date) for all defects / Number of defects
- Track MTTR by severity: Critical defects should have MTTR < 24 hours (immediate priority). High MTTR < 3 days. Medium MTTR < 1 sprint. Low MTTR by product backlog prioritization
- High MTTR by category reveals workflow problems: High MTTR for all severities = development capacity issue or triage backlog. High MTTR only for Low severity = low severity deprioritization (acceptable). High MTTR only for specific developer = individual bottleneck (coaching needed). High MTTR in specific module = module complexity requiring specialist knowledge
- MTTD and MTTR together: If MTTD is low and MTTR is high, defects are found quickly but not fixed quickly - development bottleneck. If MTTD is high but MTTR is low, defects take long to find but are fixed quickly once found - shift-left opportunity. The goal: minimize both for maximum quality efficiency
Tip
Tip
Practice Mean Time to Detect MTTD and Repair MTTR in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Playwright rising fast - modern API, auto-waits, all browsers
Practice Task
Note
Practice Task - (1) Write a working example of Mean Time to Detect MTTD and Repair MTTR from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Mean Time to Detect MTTD and Repair MTTR is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- MTTD and MTTR are time-based metrics borrowed from reliability engineering that measure the efficiency of defect management.
- Definition: Average time from when a defect was introduced into the code to when it was first discovered by testing
- Formula: MTTD = Sum of (detection date - introduction date) for all defects / Number of defects
- Estimation: The exact introduction date is rarely known - estimate it as the date the feature was declared 'coding complete' by the developer