Sometimes following process bites you in the ass. Or maybe i mean that sometimes following process just bites. Doesn't mean it's not still the right thing to do, it's just sometimes hard. By example...
We use Jira as our issue tracking system at work. As with most issue tracking systems, if you're not incredibly (arguably impossibly) diligent at upkeep you end up getting a number of cases that languish forevermore in an uncertain state. It's just the way of things. there's bugs that you're not going to fix...bugs that didn't make any sense...bugs that got fixed through some other issue but never got cross related...bugs that simply aren't applicable any more because that entire system has been deprecated...and...the list goes on. If you can follow strong process and make sure that every single bug that you get in is cross-referenced properly and categorized well then it minimizes it but i simply don't believe that anyone out there has no issue with growing languished bug lists. My opinion is that you try hard to have a good categorization scheme, strong workflow built into your process and your bug tracking system and make your best effort. And then every couple of years you devote some time to clean-up.
So fast forward to week before last at my company. One of the Dev managers decided that before we start some fairly major re-design efforts that the backlog of languishing bugs should be sorted and dealt with so that when we start the design we're not only taking into consideration the requirements and issues that currently rest in the forefront of everyone's brains but that we also make sure we're building upon lessons learned in the past. A very good and honourable intent. I wasn't aware that she was making this effort...at least until i started to see it's results.
So, as QA manager i have it set up that any bug that gets updated, entered, closed etc in Jira sends me a notification. Daily i read all of these updates, generally less than 50 on your average day and it only takes a few seconds per case unless there are issues. It keeps me in the loop on a lot of things and when i spot issues then the time spent has been invaluable. It's a good process to follow for me and as i'm still pretty new, an important one. Jira has a few annoyances along this line in that standard process for closing bugs for some of my team gets me 3 notifications back to back. But i've learned to recognize these in the first case and just mark the next 2 read and move on.
Well one day a couple of weeks ago i started noticing quite a lump of cases coming from the Dev manager. As i was processing them i noticed that they were all old (some of them 4 years or older) and that they fell into three basic categories;
a) 'no longer an issue, closing the bug,'
b) 'probably not an issue, please retest and confirm,'
c) 'still an issue,' additional categorization added.
So i started to process these cases myself. And by process i mean read. A couple, and only a couple of the close ones i grabbed and asked for re-test instead because i wasn't sure and most of the retest ones i assigned to a particular resource. It was all good. Fast forward again, this time until i've processed over fifty of the things and i go to find out what's up. She tells me what she's doing and i think it's a good idea and i resign myself to some extra work for the next few days. When it hit a 100 or so i realized that although i was seeing about a 25% rate of ones marked for closing i was never actually seeing any bugs being closed.
So i went and asked the Dev Manager if she was closing any, to which her response was that she wasn't because Dev's don't close bugs, QA should. Which i think is a great response and really how it should be. I objected to the use of the term in the bug 'closing the bug,' and she agreed. We discussed and since i review all bugs, even those that have been closed, and since she had some 750 of them to process for this short period she was going to close them as well and rather than my having to read the email notification and then open the bug and update it she would just do that part.
This sounded like a good, safe solution to me. Until she emailed me 15 minutes later saying that she didn't have the rights to close bugs.
Here's where proper process bit me in the ass. It's pretty standard to have this process as well. It's common to only allow QA's to close issues so that you don't have the devs making decisions without knowing the full story. It's good process. I don't argue this fact at all. However, when i went home that friday i still had a queue of about 100 to go through, when i came back in monday, i had 385, the dev manager worked until 8:30 PM on a friday night going through the backlog.
Here's where the DDoS (denial of service) title of the blog entry comes in. All last week i tried to find time to process this stack but all i had was this ever-increasing list of notifications to process because she was finding more time that i could. When you have 400 notification emails most of them with the same sender name beside them, it becomes difficult to see the new updates from other team members. Each scrum that week i mocked the dev manager for her DDoS attack, and each time she apologized. I indicated it was ok but that i was still going to mock her for the attack. It was my method of releasing the annoyance of the task.
Because, everything else said, it's still an important task. Two people processing all the cases seems from some standpoints to be silly but in the end, clearing out the backlog is great. It's going to provide excellent information for the new design work and i'm learning a ton about the system as we go. And i've caught a dozen or so that i wasn't happy with the action taken and altered it to be a little safer.
Sometimes process hurts.
If it's good process though, it always helps.
When i left this friday i still had 100 in the queue. But i had started sorting and ensuring i was going through the new ones first every day. And she's through all 750 now, so 100 is all i should have left.
No comments:
Post a Comment