Dealing with Bugs across Teams
One of the biggest challenges my team faces is getting the bug to the right person. This seems like such a simple problem. You just properly isolate the bug, and enter it in the bug database. What could be easier?
Just about anything when you are dealing with dozens of products, at least that many shared technologies, and now, more than ever, a number of services which are on an entirely different product cycle than all of the standard desktop products.
I got a chance to work with an amazing intern who recently became an employee on a new tool to make version of components and products easy to verify and detect problems with as it became impossible to do manually with any accuracy. Now, if only I could make it crawl our bug database and detect when any bug was sent to the wrong person or team, we could save major money. But the problem is, with a lack of consistency, there is a twisted web of logic to follow.
Who owns this problem? The first step to finding out is isolating the bug. Can you try it directly on the server? Does it happen from multiple products/paths? How about multiple operating systems/browsers? Other software that is released? Did it happen in earlier versions?
How about coordination? What if the service update on the staging server isn't testable live until well after you ship a product that it should work with? What will the experience be? What if that item is delayed? It's easy to let another team know that you'll provide no testing and call it a day, but ultimately, you need to know what your customer will experience if your product interacts.
So, here are some things I find useful in getting a bug to the correct place.
1. When in doubt, ask in email to all of the QE owners for the possibly responsible product/technology/service, and set the bug status as awaiting information if it is not urgent. You can network this way and learn how they isolate where the problem is happening. You may find that they have a tool that you don't.
2. If urgent, write the bug for the part that ships first and email the dev responsible. Be as factual about the impact and isolation information as possible.
3. Ask how they determined where the bug was so that your skills improve at routing the bugs and you can save time in the future. Sometimes "there is no way to tell without more access" is the answer. If they choose not to give me access, they get a few more emails.
4. The bottom line is now the top line. Be concise and link to the information for all of the details. If you are going with the product that ships first as your default in cases of urgency to be the best possible customer advocate, you are putting your reputation on the line. Waste as little precious time as possible and make it count.
Just about anything when you are dealing with dozens of products, at least that many shared technologies, and now, more than ever, a number of services which are on an entirely different product cycle than all of the standard desktop products.
I got a chance to work with an amazing intern who recently became an employee on a new tool to make version of components and products easy to verify and detect problems with as it became impossible to do manually with any accuracy. Now, if only I could make it crawl our bug database and detect when any bug was sent to the wrong person or team, we could save major money. But the problem is, with a lack of consistency, there is a twisted web of logic to follow.
Who owns this problem? The first step to finding out is isolating the bug. Can you try it directly on the server? Does it happen from multiple products/paths? How about multiple operating systems/browsers? Other software that is released? Did it happen in earlier versions?
How about coordination? What if the service update on the staging server isn't testable live until well after you ship a product that it should work with? What will the experience be? What if that item is delayed? It's easy to let another team know that you'll provide no testing and call it a day, but ultimately, you need to know what your customer will experience if your product interacts.
So, here are some things I find useful in getting a bug to the correct place.
1. When in doubt, ask in email to all of the QE owners for the possibly responsible product/technology/service, and set the bug status as awaiting information if it is not urgent. You can network this way and learn how they isolate where the problem is happening. You may find that they have a tool that you don't.
2. If urgent, write the bug for the part that ships first and email the dev responsible. Be as factual about the impact and isolation information as possible.
3. Ask how they determined where the bug was so that your skills improve at routing the bugs and you can save time in the future. Sometimes "there is no way to tell without more access" is the answer. If they choose not to give me access, they get a few more emails.
4. The bottom line is now the top line. Be concise and link to the information for all of the details. If you are going with the product that ships first as your default in cases of urgency to be the best possible customer advocate, you are putting your reputation on the line. Waste as little precious time as possible and make it count.
You have raised an important point. Getting the bug to the right person is a critical step in the process of bug fixing and the correct deployment of the bug fix. I would like to mention a couple of points below:
Who owns the problem? The owner of a product/ service owns the problem too (if I have an automobile and it develops a problem, I should be the one to drive the process of getting the problem permanently fixed). It is possible that the product inherited the problem from another product and/ or passed on the problem to other product(s). If the product owner has an ongoing project under which the problem can be resolved, the problem could be taken up in that project. In such a case, the project manager could look at the problem and figure out the best resource to resolve the problem. If there is no ongoing project under which the problem could be taken up, the problem could be stored for resolution in a future project.
The problem might exist in multiple products. It is possible that the product owner is one individual. In case there are multiple product owners, all of them own the problem and they could plan the best way to address the problem (and similar problems).
How about coordination? This can become complex when a number of teams are involved in a bug fix and deployment. Unless it has been agreed otherwise, the owner of the bug (the individual who raised the bug in the first place) should track the bug fix in development, staging and live. This would most likely happen in collaboration with other teams.
Reply to this
Waste as little precious time as possible and make it count. This post is excellent. What comes to mind is problem of communication. There are two problems in software development; the first is communication and second is communication.
From my personal experience also observed a sense of ownership. I read this in one of your former great write ups. Make a mistake, apologize, fix it and make it better next time. It's about being responsible and feeling responsible for ones activities and not passing the buck. People enjoy taking credit for work someone else did and not admitting their own mistakes. Not all, obviously. Take it like a man. You screw up: apologize, fix it and do it better next time! FxCop.
Reply to this