Originally Posted by
guitara
It's a busy busy week as you know, but I'll address a couple of these points. We should discuss this more later when we all have a bit more time (post-cycle?).
On the dates being incorrect on the calendar, there was an original note of april 4th for the actual release date for the beta, but it wasn't showing up. I think it was a separate line item even. Anyways, I made sure the note shows up now. That said, the cadence calendar is showing the saturday start dates, not actual event dates, whereas the release schedule is showing the exact important dates. The Final Beta release happens the week of March 30th from our cadence perspective, hence it's listed on that weeks' line -- I hope this makes sense. (EDIT: I should note here that the calendar needs to be easy to understand, so please do give more feedback on tweaks that should happen to make it so. We had an integrated calendar (it was part of the release schedule calendar) for testing last cycle, and it was very confusing to follow because so many events and timelines where trying to be convened on one page; I hope this is an improvement, but let's keep iterating!)
In general we as testers actually like bugs.. Bug counts are funny. A low bug count during the cycle doesn't mean a stable release (it could mean we're not testing!), and a high bug count doesn't necessarily mean the release is horrible (maybe we're testing really well). Now, the caveat with bugs is while we like them, we don't like them in the stable release -- in development though, if we find a large amount of bugs, I would consider our job as successful.
I feel you on the private and long-standing bugs, but we as a testing community have done our part on those by finding and documenting the bug. For the private bug, given the severity and longevity it would likely be worth asking someone to manually prune sensitive info from the report and open it, or ask the original reporter to merely publicize his info willingly if he is able to do so.
All that said, what can we do about high bug counts and longstanding bugs or regressions? If we've reported them and documented them well, we've done our part in helping get the bug fixed. From the development side, we need those folks to also address and work the bugs found. I did a post last year about bug shepherding, and it's important. I know many of you practice this;
you report the bug in detail, making sure it can be reproduced by others
you follow-up on the bug to make sure it's properly filed and can be seen by those who can fix it
you help test the fix if necessary
Beyond that, the actual bug fix is in the hands of the developers. We can and should do everything we can to help make sure the bug is fixed, but the fixes themselves rely on a developer.
