Conflicts with developers arise from the lack of patience and empathy; when a tester and developer forget that they are ultimately striving to reach the same goal.
Conflicts generally arise through lack of misunderstanding due to miscommunication. In my organization, this typically occurs when a developer closes a defect stating that it can't be reproduced. If this situation is not handled carefully, it can lead to conflict.
Conflict initiators are: 1) Tester did not provide a clear and/or accurate description of the defect. For example, the tester may report the error name or text and the developer might be looking for an error number.
2) Tester did not provide a thorough description of the defect. For example, tester may not mention that the defect was found in a particular test environment and the developer assumed it was caused in a different one.
3) Developer misinterprets the defect even though it was authored accurately, clearly and thoroughly. Devs aren't perfect. Under time constraints to reach milestones, they sometimes overlook key points in defect reports and end up closing bugs that should get fixed.
Conflict negators are: 1) Establish a standard defect reporting process and get Test and Development to fully understand and adopt it.
2) Empathy: Understand that everyone is under pressure to meet deadlines and we are all on the same team to reach a common goal.
3) Patience: Understand that nobody's perfect.
Above answer was rated as good by the following members: saruchakra
The Conflict arise once the bug is not accept them as Open from development side. Time constraint also makes the reason for the Conflict. -Late Build/Short Test Time. -Giving Build and ask to test at end time of work day.
Conflict almost always arises through bad communication. If by user for example you mean tester then perhaps we can better answer your question. But if you mean user as in end user of the product then I would be surprised they come into conflict with each other. One of the roles as I see it of a tester is to be pedantic for example if in the tech spec or user requirements it states "click button A to print report. " Then that is what must happen. There is a bug if a) the report is printed without clicking and b) if clicking doesn't print a report. Now how do we communicate this to the developer? If you say hey your program is bugged it doesn't work then you are likely to have a conflict. If you say Hi on page 3 paragraph 4 user requirement XXX it states we must click button to have report But in fact this is not the case then your are more likely to make headway!
We often have conflict with the developer regarding the bug exists or not.
Sometimes bug itself is the not considered and fixed cause of estimation and budget constraints of the project.
Sometimes communication between the developer and tester are not setup properly cause of that developer may not able to interpret the bug properly.
And sometimes the inputs given by the testers are not enough for the developers to interpret and find the solutions so they seek for more information from testers.
Sometimes the developers says like the bug should be mapped to few requirements and if it is not mapped then it is not valid bugs. etc.
There may be several reasons of conflict with the developer. The following are scenarios where conflict can be arised:
1. Developer is too busy so s/he does not understand the defect properly. 2. Insufficient/incomplete information given at the time of defect logging. 3. Developer is not reproducing the defect in the environment as mentioned in the defect. 4. Developer could not understand whatever the defect is stating.
Conflicts with developers arise from the lack of patience and empathy; when a tester and developer forget that they are ultimately striving to reach the same goal.
Conflicts generally arise through lack of misunderstanding due to miscommunication. In my organization this typically occurs when a developer closes a defect stating that it can't be reproduced. If this situation is not handled carefully it can lead to conflict.
Conflict initiators are: 1) Tester did not provide a clear and/or accurate description of the defect. For example the tester may report the error name or text and the developer might be looking for an error number.
2) Tester did not provide a thorough description of the defect. For example tester may not mention that the defect was found in a particular test environment and the developer assumed it was caused in a different one.
3) Developer misinterprets the defect even though it was authored accurately clearly and thoroughly. Devs aren't perfect. Under time constraints to reach milestones they sometimes overlook key points in defect reports and end up closing bugs that should get fixed.
Conflict negators are: 1) Establish a standard defect reporting process and get Test and Development to fully understand and adopt it.
2) Empathy: Understand that everyone is under pressure to meet deadlines and we are all on the same team to reach a common goal.
The issues have a lot to do with approach and personality. Conflict happens not because you are a tester and he or she is a developer. Conflict happens because of bad communication.
Communication is any interaction around any person. So for example if you are thinking about your developer when you are on the way home from work you are in communication with your concept of this person. I have seen situations where communication has broken down completely because a developer had a pre concieved notion about how a new tester in the company should behave. Unfortunately they came for different cultures spoke different languages and managed to use the wrong terms while trying to be diplomatic. Each one ended up insulting the other. The problem then became huge because of pride. The tester almost lost his job because of the pride of the developer who had the managers ear.
The problem is both were striving for the same goal both had the same view on productivity the tester had more life experience and the developer had more computing experience. The result was terrible.
1 
0