Would you "track" feature coverage in any way, or is it more an approach for talking about testing with the team in general?
This is an approach for talking about testing with the team, but one which relates more to today's framework heavy fast user feedback cycle development approach.
While this is a different metric to track, and I have no idea how to do it I am actively looking for an opportunity to do it - with a mature team that has worked before.
Yeah, I like the idea too. It might also have a nice byproduct of forcing you to name features and assign value to them. Testing in general forces you to think through the value and arrangement of code, but features kind of get lost and messy, and we might support features not delivering value, but we don't really draw the line.
And features could also be proxied by user stories - which have an element of value, and acceptance criteria as part of their documentation.
This can also be tied with metrics on how features are used to get a better insight
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.