Quantifying Quality for Engineers
summary
Framework named SPQR (security performance quality reliability) treats user success as avoiding all unacceptable events and multiplies independent probabilities to get end‑to‑end health. It uses observability and product telemetry, message send latency threshold 5s for performance, and folds bug databases and support tickets (tickets undersample ~1000:1) by mapping severities to occurrence probabilities bug severity mapped to probabilities 1e‑6–1e‑2. Prototype is implemented in Presto over Parquet on S3, produces a daily trace and shows performance driving most bad experiences.
AI-written summary · about
chapters (22)
- 0:00Introduction
- 0:45Math
- 2:38Feedback
- 5:40Unacceptable Experiences
- 7:10Only One Way
- 10:03Assumptions
- 10:52Reliability
- 12:53Performance
- 15:12Quality
- 20:11Security
- 21:44Independence
- 22:30Data Warehouse
- 23:03Early Results
- 25:38Disclaimer
- 26:26Tools
- 27:29Keiths background
- 28:27How much Slack invests in observability
- 30:02How does your organization use these metrics
- 31:58How do we ensure accountability and ownership
- 34:02Where can we find more material about SPQR
- 34:35Have you ever seen SPQR in other organizations
- 35:44Any recipe for incorporation of technical debt into SPQR
related talks
46mQuality Engineering for DevOps Teams
24mThe 3-pillar, balanced quality model of Proactive QA, Detective QA and Reactive QA
49mIs your Quality on the Road to Nowhere?
46mFull Court Quality: Lacing Up for Speed, Stability & Style
40mReal Quality Assurance from an Agile and Lean Viewpoint
36mHow Good Is Your Software Product? (Evolving "Quality"Throughout The SDLC)
22mQualityOps–Left Shift Customer Success With A Thriving Quality Engineering Ecosystem
26mSoftware Quality in Software Houses? Yes! (SQISHY)