The Ultimate Bug War: Developer Vs Tester
Well, all IT graduates know the basic definition of a bug. But when we specialize in our domains such as becoming a tester or software engineer or a developer, the same basic definition changes.
A Bug is..
For a Tester: An error in the code made by developer and found by me
For a Developer: Malfunction of the least important module of the software (ignorable)
Every company faces the dilemma of this invisible border line between the testers and developers’ teams which can be crossed only under serious circumstances.
A tester finds his win in identifying a bug which at the same time is a lose for a developer. But if we zoom out and see the larger picture, it’s a win-win situation. Because the developer’s code is bug free and tester adds the cherry on top by passing what the developer just made.
It is indeed a team’s effort to produce some high quality top notch product. This very line is so powerful that if testers and developers tend to interpret this right, they all will grow as a team.
Testers give themselves a good pat on the back for finding a bug and developers strive to deny the presence of bugs found. In this war, both the parties forget the ultimate duty they signed up for while joining the industry i.e. produce the best output.
Another thing that developers and testers ignore while arguing over bugs is the value of time that is being utilized in the unhealthy, unproductive quarrel for bug status.
Enterprises and startups need to take special measures to build a healthy developer-tester relationship in an organization to increase the overall productivity and quality of the product.
Few Ice Breaker Activities could be:
Practice team-building exercises. Don’t divide testers and developers in separate teams. Make pairs and put them in mini teams.
The lunch hour should be utilized for their networking and interaction which will help their team bonding.
Have a pop up quiz, put few questions in the box, everyone in the group must take a question, read it aloud, and offer an answer. The group should discuss, refine and agree the correct answer. (do not stall for long discussions, keep going)
Have office trivia every month, containing questions about fellow testers. These could be answered by the developers and vice versa. The scores will indicate the strength of their team. Encourage this with fun-filled office perks.
One practice we established at Virtual Force is to conduct a pre-release product dissection sessions. These are 1-2 hours intensive sessions of User testing done by the Testing and Development team along with couple of independent individuals in a neutral environment. Everybody runs the application to check for stability and combine their findings towards the end of the session. The results had been outstanding, especially in closing out that last trail of bugs that forms the long tail of the project closure.
Needless to say that having a good team consisting of developers and testers should have an open communication policy. Both are on the same team, that releases flawless software. Any bug found later will hurt the repute for both.