If you’re a trained software engineer (or purport to be one) responsible for a certain area of code along with team members, and you encounter a problem while testing some related area, have the decency to follow the following steps (in order):
- Gather all pertinent information, at least in your head. You’re a software engineer and should be more familiar with the area than a key op tester would be. So, whether you’re going to debug the problem yourself or ask someone to, you should have a much better idea of what kind of data to collect in order to triage the problem. Don’t just assume your teammate will be happy to reconstruct what you were doing and where logs, etc. might be. We may have to act like detectives sometimes, but it doesn’t mean we like to.
- Try to identify the problem yourself. Even if it’s probably not your fault (and it never is, is it?), what’s stopping you from looking into the problem a little and seeing if you can identify the bug. Hell, if it’s simple enough, fix it yourself. That’s why you’re on a team.
- When describing the problem to others, be detailed. Your teammates are not mind-readers. You know how frustrating it is to get a bug-report from a non-engineer along the lines of “the feature didn’t work,” so don’t do the same to your teammates, or any engineer you’re asking for help from. Personally, I react very poorly to someone showing up in my cube and saying “X isn’t working. What’s broken?”. A corollary to this is if you’re asking another engineer to look at your code (informally or in a formal review), give him or her some background as to what the code does, what you changed about it, and why. Just throwing some code listings in my face and asking me to look at it is probably going to garner a “looks good… whatever” from me, or at least force me to ask you explain yourself (if I’m feeling charitable).
