| Date: | May 17, 2007 / year-entry #174 |
| Tags: | no-good-deed-goes-unpunished;other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070517-00/?p=26823 |
| Comments: | 18 |
| Summary: | There were several suggestions as to how I could avoid being tagged as the owner of an issue because I helped route the problem. Many of them involved assigning the bug back to the testers to "teach them a lesson". Punishing the tester doesn't help the product. Remember, we're all in this together. The goal... |
There were several suggestions as to how I could avoid being tagged as the owner of an issue because I helped route the problem. Many of them involved assigning the bug back to the testers to "teach them a lesson". Punishing the tester doesn't help the product. Remember, we're all in this together. The goal is to fix bugs and ship a quality product.† Being vindictive doesn't further that goal. Especially one suggestion which was to resolve the bug as "Won't fix" with the reason "Tester is an idiot." That may make you feel better, but it is a total disservice to your customers. It's almost certainly a sign of dysfunction in a product when the team members spend more time sniping at each other than they do actually working on the product. It's a team effort. Let's try to act like a team. †Pre-emptive snarky comment: "Hey, bozos! Why not try doing it for once!" |
Comments (18)
Comments are closed. |
Thanks for the laugh this morning.
You could always set the building on fire.
Hey, bozos! Wh… oh, never mind.
My suggestion: The first time it happens with some particular tester, help them out by reassigning it (with a "not my department" note of course). The second time, assign it back to the tester with a "not my department, may be department [X}" note.
I think that’s fair. The first time they made an honest mistake, but you’ve still clearly stated that it was a mistake, and the tester should be aware of this by the time the bug finally comes back to him/her for closing. If they couldn’t be bothered to actually read your comment and proceed to assign it to you/your team a second time, then you’ve already got a dysfunctional team and you need to take steps to correct it.
I think as long as it’s not done vindictively ("tester is an idiot") but rather helpfully in a noncommittal sense ("may be team X") then you won’t be making things any worse. But I could be wrong, maybe you have specific experience with this.
The thing is, if you reassign it for them, you’ll end up losing lots of time if they keep doing it. I like Aaron suggestion, and I don’t think assigning it back with a friendly note saying ‘I think you misplaced this, because … ‘. Remember, we’re all in this together. ;-) So I don’t think helping the tester to do a better job next time is punishing him (that does mean resisting the momentarily urge to type ‘Tester is an idiot’ obviously).
If they do it wrong so much that you become vindictive, well, there’s a bigger problem there somehow, in the people, their way of working or the organization…
I usually reassign the bug and then send email to the new assignee as well as whoever misassigned it in the first place. That way the new owner knows they’ve got a new bug (it drives me up a wall when people give me bugs and don’t tell me, especially time-critical ones) and the person who misassigned it in the first place is given a gentle correction.
I’m pretty sure the comment you link to was a jab at open-source development, not a serious recommendation on handling this kind of issue.
I think this situation also points to the inadequacy of the issue tracking tool. (all of them, really) These issue tracking tools are supposed to foster sufficient, traceable communications between teams that are involved in resolving issues, but there is communications overload typically, and the communications from the issue tracking systems end up being insufficient. In the case of a re-assignment of a bug, Why should we have to email the recipient of a reassigned bug under separate cover? Shouldn’t the tracking system provide meaningful notification to both the person you received the issue from and the person who is receiving the issue? It nominally happens in some, if you’re an IP, but I notice that the transfer blends in with all the other activity on the ticket, and more email is used to draw attention to transfer. A transfer reason should be different from other notes to the issue.
In the absence of ideal tools, in this case, transferring the issue back to the tester with a note and email under separate cover stating, "I don’t have the authority or knowledge to deal with issue; I sent it to X last time, but since this is a slightly different problem, maybe Y can help you out with this one." would probably be the way to go.
(By the way, howdy, non-Microsofter here, first comment to your blog, recent reader to the blog. I’m enjoying the tips and conundrums you’re posting about here, keep it up!)
<<It’s almost certainly a sign of dysfunction in a product when the team members spend more time sniping at each other than they do actually working on the product.>>
I agree it is a dysfunction, but it is often caused by managers (at least this is my theory :-)
One of the lessons for managers is that you cannot control what you cannot measure.
So they add bad measurement systems, with side effects.
For testers:
For developers:
number of bugs reported against them
number of bugs fixed
And it is also known that "you get what you measure for"
If testers get points for the number of bugs reported, and developers loose points for the number of bugs reported against them, you get internal fights.
Testers will report the same bug 10 times (getting to it in different ways, or for 10 languages), and will report bugs that are not bugs.
Developers will tend to try blame-shifting, push-back on bugs, regard QE as "the enemy"
Each "measurement system" brings with it other problems.
How to avoid the problems is another story (and there are full books on software metrics).
Only if your cubicle is moved to the basement first.
As well as the bug tracker, one would have to have a fake Subversion identity too to ensure that someone doesn’t use Blame mode to find who was responsible for the lines of code that are causing the problems.
But then it’s never our code that is, right? :-)
Mihai,
Joel Spolsky just wrote about exactly what you commented on. He calls it Econ 101 Management. He defines it here: http://www.joelonsoftware.com/items/2006/08/09.html
Legolas and Raymond,
You’re exactly on the ball with your response/post. One other option would be to use an alias in the bug tracking system. My old team simply used %TeamName%Triage and that worked wonders. I also really like the communication aspect that Legolas touches on since not everyone has or uses a real-time bug tracking system (anyone at MS in VSTeam listening to this?? Here’s a freebee) although we all desire them. Running repeated SQL queries to find your bugs is not fun. *AHEM*.
Thanks,
K
Organisations need to realise that being a good tester is just as rare and valuable as being a good developer (and indeed being a good anything).
Good testers are vital and should be paid what good developers are. Testers should be fully part of the development team, not in a separate testing team. Testing needs to be made a first class career.
I’m a big believer in this, largely because I’d like to think that I ascribe to the golden rule.
I suppose my thought process goes "If I fix someone’s problem, it just makes the sum total problems go down. Additionally, they’ll appreciate that I took charge and fixed something without having to get them involved."
To date, this has accomplished nothing. I still get people walking into my cube to berate me for something.
I’ll keep on doing it though, hoping that maybe one day we’ll all end up better off.
What the tester really found was a bug in the testing method. We find that all the time and enter a bug for that. Testing is, and should be, hard work, too. They can just as easily say, "The [Engineer/Programmer/Supervisor] is an idiot" many days a week but they usually don’t. Like you, Raymond, they are usually very nice and try to help us figure out what the problem is and try to help the customer.
Why isn’t your PM responsible for routing bugs?
I think the root problem here is that it is so hard to assign bugs properly. Assigning a bug to the proper team can compared to a postal system where there are no standard addresses (street, city, state, zip), so invariable someone else winds up with your mail. Best course of action is just to realize that because there is no "postmaster" everyone is going to be sucking up the job of routing stuff that gets sent incorrectly. Flip side of this is that if someone finds out that you are a better router, you’re going to get more traffic. They probably didn’t assign it to you because they thought you could fix the bug, it was probably because last time "stuff got fixed" and wanted to repeat that experience.
Want to solve the problem: create a better way to assign bugs than black magic and deep knowledge of source code. Design a bug filing system that is specifically targeted to tester’s needs (not necessarily devs).
Why not just adjust the "view" (in the sense of database) of testers in your bug-tracking application so records of "some action that the assigned user barely touched it"(such as "reassign" in your example) is hidden?