Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Speak Face to Face
There's no substitute for talking face to face with someone—asking questions, reading body language, and building a rapport are all helpful in creating open and effective project communication. Many times, when I encounter an issue that I think might be a defect, I immediately show the problem to a developer before I even write the defect ticket. This strategy helps in many ways:
The developer confirms that the problem is not some setting or incorrect configuration on my machine; it's actually a bug.
The developer has seen the bug, so it's compelling—much more so than if he tried and failed to reproduce the problem on his own.
The developer can reproduce the problem more easily after seeing the steps performed in detail.
The developer may already be aware of the problem and can indicate how it's being handled.
The developer can request inclusion of additional information on the ticket to help jog his memory: configuration file, version number, the developer's initial thoughts and reactions, etc.
The developer may be able to specify the person best suited to work on this problem.
By watching the developer interact with the bug, I may discover other areas I need to test that might not have occurred to me otherwise.
For all of this action to occur, the developer needs to be available and willing to help. In one of my past projects, I went through this process several times with a particular developer, and we eventually developed a way of logging bugs together. We also started holding quick developer/tester sessions in which we would further investigate a bug or try to find similar bugs in other areas of the application. Once I had the developer's involvement in the test process, he could easily pull in other developers and architects to provide information as we were testing (something that I could never get to happen as quickly on my own).
Engaging the developer directly helps him or her better understand what you're trying to accomplish. Once the developer sees how you look for bugs, he or she can attempt to make bugs of that type more visible when they occur; for example, by adding error messages to the log files. Most developers have no idea of the odd ways in which testers look for bugs.
NOTE
Several of the developers who reviewed this article commented that when they see a bug produced by a tester, it gives them more insight into the severity of the bug and allows them to glean some better ways to test their code before it even gets to the tester.
Finally, keep in mind that you may be disturbing or distracting the developer during a high-pressure time in the release cycle. If you approach developers frequently, establish some ground rules to avoid annoying the developers, and to avoid reducing their productivity at a critical time in the project.