Or something....

True, developers love to code new things. But there is a regimen in place where bugs that have survived triage must be fixed. A dev who has completed a new feature but not touched a bug is in sorry eyes :-)

>I figured you were on vacation or something . . .
>
>Thanks for the reply. I'm still not convinced about how seriously they take bugs. After all, developers love doing new and cool things. Going back to track down and fix bugs is not nearly as fun or glamorous.
>
>>(Sorry for the delay responding, was AFK for a few weeks)
>>
>>Very good point on over reliance on automated testing as a panacea. We ran into several situations where a bug was found that already had a test, but the test was poorly written and masked or misintepreted the bug via a bad baseline or bad coding.
>>
>>I don't think people think that through in a lot of cases. The full test cycle for a product is misunderstood by a lot of IT managers. They see automated testing as a goal in-of-itself and don't always realize that it only works with rigorous development of test plans, reproduction scenarios, etc.
>>
>>And then there's the test harness itself: I recall that during the VFP 8 product cycle we discovered that a flag in the harness had been shut off at some point in the past and no single-user DLL tests had been run for a long time(!)...although tests that could also be run in multi-user settings as well were still running.
>>
>>And I reiterate that all bugs are taken seriously. They are prioritized by impact on the user. If there's an easy work-around, it's low priority. If it C0000005 or hangs the PC, it's fixed no matter what. Sometimes, seemingly innocuous bugs or annoying bugs that appear to be willfully ignored (as a lot of folks accused us of doing over the years) are not fixed because fixing them would either break other behavior or introduce unacceptable risk into the stability of the product.