re: How do you measure and discuss the less measurable things about testing code? VIEW POST

VIEW FULL DISCUSSION
 

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.

 

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.

 

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

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:

code of conduct - report abuse