It's a good example of why there needs to be good discussion between stakeholders, developers, testers and other members of a product team with regards to bugs/enhancements/features/issues.

After a release like that, I often end up having the stakeholder come to me a day or two later with a "critical bug" that must be fixed asap. The bug is generally something that the dev team and I see as trivial such as a scrollbar where there doesn't need to be one or a missing border around a frame or some other aesthetic issue that does make the project cleaner, but not any more usable. The bug is usually in the database but was prioritized away by the test and/or dev team as being insignificant, especially when compared with data integrity or software functionality.
I try to push for regular bug triage meetings with the stakeholders, especially near the end of a project. But most of the time, the stakeholders are far too involved with trying to negotiate the endgame with the customer (who is usually driving us towards an unrealistic product deadline) and as a result, they don't want to take the 'downtime' to fully understand each bug. Instead, they have me go to them with a list of bugs titles sorted based on the priority set by myself and the developer and in 2 minutes, we scan the list.

To project managers and other stakeholders...please get involved with the defect tracking process and provide input on the issues to be fixed. To test and dev teams, look for input from your stakeholders to make sure you're getting the important things fixed. Otherwise, you'll find yourselves scrambling in the week following a release.
No comments:
Post a Comment