Senior software developer at Amazon Web Services. I work on the AWS Serverless Application Repository and AWS SAM. I’m passionate about writing quality software and teaching others how to do the same.
Location
Seattle, WA
Education
BS Computer Engineering, Minors: CS and Math
Work
Sr. Software Development Engineer at Amazon Web Services
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.
Senior software developer at Amazon Web Services. I work on the AWS Serverless Application Repository and AWS SAM. I’m passionate about writing quality software and teaching others how to do the same.
Location
Seattle, WA
Education
BS Computer Engineering, Minors: CS and Math
Work
Sr. Software Development Engineer at Amazon Web Services
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'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: