[musingsole]

Don't overthink it.

This advice covers 80-99% of actual bugs. Real bugs don't reappear once fixed -- if they do, it means they were never fixed. Metrics designed for a bug that was fixed may be relevant but specifically ARE NOT TARGETED at any new bugs.

Though all of this really highlights the core problem with metrics and dashboards and such in the corporate world: if the problem were a problem and not just a convenient political puppet, we'd have solved it by now instead of talking about what thinking about solving it looks like.

[eloff]

I think applying actual engineering wisdom to software in this case is a mistake. Nobody writes an automated test for a bug and then deletes it once the bug is fixed. You wrote the test in the first place so you get alerted when there is a regression before it gets into production. Regressions happen all the time.

[Too]

In isolation, bugs don't suddenly reappear no. So if you only regression test on unit-level, it's very unlikely the test will ever fire red again. What you should do is write use-case regression tests. This will protect you from major regressions, such as "user-registration is taking several minutes", because this is a major bug that can occur for a million new reasons, even if last time the reason was isolated to "database query x was running very slow", your test should track the former, not the latter.

[pixl97]

I would like you to talk to my programming team about regressions.

[m3047]

I think the argument in this (narrow) discussion would be you haven't fixed (or identified / addressed) the problem.