We have a web-app and a QA engineer who&#x27;s helping to ensure we don&#x27;t ship outages and we know about severe regressions. (We&#x27;re not aiming for pixel-perfect at the moment, but for good enough.) She&#x27;s doing that by building up a Selenium suite that catches regressions just fine, spec-driven testing for new features and exploratory testing for the unexpected.<p>How can I give her a sense of “a job well done”? I can and do &#x2F;tell&#x2F; her, cuz she&#x27;s doing great, but I&#x27;d like to do better, and &#x2F;show&#x2F; her: Here&#x27;s how we&#x27;ve been doing, and this has improved in the last weeks; you&#x27;re doing great.<p>We sat together to think about this, and came up with collecting those numbers per week:<p>* #severe bugs (bugs in our core functionality that are encountered by customers for whom there are no workarounds)
* #reported bugs (reported by customers)
* #caught severe bugs (bugs found in staging that hold up deployment — basically bugs in above “severe” category that we caught before they went live)<p>If those numbers are looking good, she feels she&#x27;s doing a great job.<p>How are you doing that? Do you have better ideas to measure the success and progress of QA in a startup?
Ask HN: How to measure QA in a startup?