DEV Community

Discussion on: How do you measure and discuss the less measurable things about testing code?

Collapse
jlhcoder profile image
James Hood

I'm a huge fan of full CI/CD, so my key success metrics are deployment frequency and bad deployment rate (tracking bugs making it to production). I think these are better metrics to track than code coverage, because they get to the heart of what testing is--risk management.

That said, I don't ignore coverage. But I consider it a highly imprecise metric. 80% vs 90% doesn't tell me much. 80% vs 10% means something.

Collapse
ben profile image
Ben Halpern Author

I like this thought. Would these ideas apply much to a small team that doesn't really have enough overall activity to develop "rates" yet? Would love to take a small step in this direction for the future.

Collapse
jlhcoder profile image
James Hood

I apply this with 2-pizza teams so it doesn't have to be big teams. But if you're talking about 2-3 people, I prefer agile's "people over process" and just poll the group asking how they'd rate quality, what's working, where are the gaps, etc

Thread Thread
danlebrero profile image
Dan Lebrero

I am with James.

I just published Error budget: Google's solution for innovating at a sustainable pace that explains how do you know if you are going too fast.

A couple of tools that you may also want to take into consideration: