Friday's Musings - Heads up you guys: sending bugs your way

As a tester, when we find bugs we are trained to log them. There are industry standards out there on how to write a good bug and what details need to be included. What we forget after we log a defect is: Now what?

What I always do is call or email my software engineers. No not to show off or blow my horns but to give them a "heads up". I always call them if its the right time (have a few offshore and wait till its a good time for them) and tell them this is what I found, this is what I was doing and this is what happened (especially if its high or critical issue).

Why do this?

1. The heads up gives them a chance to react to it before the bug triage/defect review meeting. You are giving them an opportunity to research it and be ready when questions are asked in meetings. This way your team is already a step ahead in trying to answer the questions like "How critical is it?" or "How easy is it to fix it?" etc.
2. When we give them a heads up immediately they may ask you to look for additional information and you will still have the system available to help them trouble shoot. If its days later and if you have had builds deployed or other test data changes you may not be able to help them replicate defects as easily as you would want to.
3. You are being a team player. You are not catching them by surprise in review meetings and they will return the favor by sharing information and helping you to when needed.
4. Gives an opportunity to learn. Several of these calls to my developers have lead to more questions and then into discussion sessions to trouble shoot. They ask for details and information and this has helped me take notes on things that they are looking for in bugs. I use these tips/notes to write better bugs. So the next time I call them I have answers to a few more questions that I had the first time I called them to report a bug.
5. You are saving time. Instead of waiting till the defect or bug get to the review meeting and then being assigned for analysis and then wait till another meeting to decide if the bug has to be fixed or not you are giving opportunity to react in the first meeting itself with information from software engineers.

I am tagging this under Change Leader. Why? Because you can start small changes and lead the team to do better. I call these small changes as signs to build better teams and as a result better products for our customers: internal and external.

Do you have tips on saving time, building teams or help testing team, please share?