The stories regarding the relationship between a developer and a tester has been told since the very first bug was discovered, and with all the sleeves up, they are always on the verge of breaking a conflict. The developer is always complaining about the reported bug and is hesitant in accepting it, while a tester stand strong on the view that reported bug is correct and wants it to be fixed on priority – neither of them is ever ready to listen to one and other.
And hence, the relationship between the two has never been ideal – in most cases 🙂
Over the last four years, I have experienced that the conflict between the two is inevitable mostly due to the difference of opinion. However, there are ways by which we can reduce the chances of such a conflict to happen. And for this, the tester has to take the initiative.
In my opinion, a good approach to reach a solution oriented resolution to this conflict is by the management of bug Severity and priority. In order to understand my point of view, we need to understand what they are:
It is the classification of the bug based on its impact on the operations of the system.
- Blocker: The bug that appears within the functionality of the application and will not allow the user to use the system.
- Critical: The bug that does not have a work around, however the occurrence of it does not halt the operations.
- Major: The bug that results in the termination of one or more component of the system.
- Moderate: The bug due to which incorrect, incomplete or inconsistent results are produced.
- Minor: The bug that does not cause any break-down of the system and has an easy work around.
- Cosmetic: The bug related to the User Interface is a cosmetic bug.
It is the order in which a defect should be resolved:
- High: The bug that needs to be fixed immediately.
- Medium: The bug for which a developer can take some time.
- Low: The bug with no functionality impact like spelling mistakes that can be fixed any time.
Once the difference between the types of severity and priority and the relationship between the two is understood, the order for setting these in the correct manner is just a child’s play for tester.
‘This is not a bug!’ is just a 5 words statement by the developer, but believe me; a tester cannot digest these 5 words easily. Hence, it is better to report the bug in a manner which does not allow the developer to make such a statement.
The second and the easiest way in which the conflict can be avoided between a developer and the tester is for both to be humble and polite and raise the level of their argument and not their tone.