It's natural for there to be tension between software testers and developers; after all, the job of the tester...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
is to find flaws in the work of developers, among other things. To help ease that tension, here are four tips you can use to help create a peaceful, effective relationship with software developers.
Tip #1: Don't editorialize the bugs you find.
This was a pretty lame mistake, and the developer groaned as soon as I reported the bug.
It might be tempting in situations like this to lambast the developer about making such a stupid mistake or to laugh about what an idiot the developer is at the water cooler. Don't do it! It's immature and amateurish. Instead, take a minute and remind yourself about all the pressure a developer is under. They face difficult technical challenges, often estimated by someone else, with unreasonable timelines and little room for experimentation and thorough design. Software development is hard and even the best developers make simple mistakes sometimes.
Tip #2: Stay in sync with the development cadence
Two years ago I started working part-time on a project that needed testing help. The project was already under way when I joined, and there was a mostly-working version of the application available for me to test, so I got started testing right away.
The first thing I noticed was that the user interface was pretty bad. There were all sorts of usability issues with it, from the way it was laid out to the navigation between fields. I started filing bug reports right away.
A week or two went by and I noticed that all my bug reports related to the interface were being ignored. Other bugs were being fixed; but these were obviously shelved. So I stopped reporting interface bugs and focused on the type of bugs that were being fixed: application errors.
This turned out to be a wise choice. A few months later the team added a graphic designer to the project and he overhauled the interface, gave it a cohesive, attractive design and effectively made all the user interface bugs I had already reported a moot point.
This is an example of how a tester can fall out of step with the rhythm of the development team. My user interface bug reports were counter-productive because they were ill-timed. I could have figured that out by simply asking a few questions or spending more time observing the type of work that was being done. Either of those things would have made it obvious that the time for testing interface for usability and design had not yet arrived.
Developers generally read all the bug reports. In fact, it's not uncommon for them to get an automated email every time you submit one. If you make the mistake I made and submit bug reports that are out of sync with the development cadence, developers will soon learn to ignore you. Worse still, they will begin to see interacting with you as a waste of time if you don't correct this behavior quickly.
Tip#3: Isolate bugs effectively
Don't you hate it when you submit a bug report and a developer rejects it because it works for them? Guess what? Developers hate it even more. They had to read the report, attempt to reproduce it and then reject the report, knowing full well that after they reject it you are going to spend some more time isolating the bug so you can prove to them that it is really happening.
You can burn a lot of development time by submitting bug reports that are difficult to reproduce, inaccurate or are really caused by some mistake on your part setting up your test environment. If you do, developers will resent the time they have wasted on you and they may begin treating you with contempt or disrespect.
To avoid this problem, make sure each bug is properly isolated and described when you submit a bug report. Any time you file a bug report, you should ask yourself the following questions:
- Have I found (and described) the simplest possible path for reproducing the problem?
- Am I testing on the right version of the application?
- Have I ruled out local configuration issues as the root cause?
Tip #4: Sleep on bug reports
I tend to test in one-hour blocks. I take notes while I'm testing and review them after I've finished, highlighting places where I think I might have found a bug. Then I go through each potential bug and attempt to reproduce and isolate it. If I still believe I've found a bug after all that I will submit a bug report. Sometimes I find myself slipping in this discipline and developers aren't able to fix bugs based on my report alone. When this happens, I add an additional step to my testing regimen: sleep. Instead of submitting my bug report right away, I will fill out the report and save it locally. Then I will step away from it for a day or two, just long enough to let my brain forget all the details of the problem. Then I will come back to my report and try to use what I have written to reproduce the bug. If I'm able to do it, then I submit the report. If not, I start over and try to do a better job isolating and describing the bug. Follow these steps, and you should find your work with developers becoming more productive. While doing the tips above, also remember to adopt a good attitude. You can get along with developers if you respect them and appreciate the difficulty of creating software that works well. Be positive and do your best to make a meaningful impact on the project, and you will find that developers will respect and appreciate you in return.