Answer: Michael Larsen
When bug reports are written as personal, then it’s possible that they will take them as such. While it’s tempting to look and say “oh, grow up, already”, that’s rarely a helpful course of action. Where possible, word your bugs to where you are focusing on the issue, and show that you are being an advocate for the issue being presented. Avoid antagonistic comments in your bugs, and stick to the facts. The developer in question may be a wonderful person, but unfortunately, there are mistakes in the code. Deal with the mistakes in the code, and provide solid feedback that helps to resolve the issues. Remember, it’s not the person that files the most bugs that shows they are a great tester, it’s the one that files the right bugs and then helps see to it that the right bugs get fixed that shows they are a great tester.
Answer: Perze Ababa
A bug is a bug is a bug is a bug.
Bug advocacy is a pain especially if the team doesn’t come to terms with what the actual problem is. Ask yourself if the developer is taking a ticket too personal because he/she does not understand the issue at hand? Is your bug report readable? Can it be understood in a single reading? Do you have enough information to replicate the issue.
If a developer is being difficult just for the sake of being a jerk then talk to your manager so he/she can talk to that developer’s manager and that developer’s manager can lay the smackdown on him. See, a manager is good for something.
Everyone in your team is PAID to do their work, there is no reason for them not to address an issue.
Answer: Paul Carvalho
There are many facets to answering this question. I would begin by trying to build a relationship with the developer and try to get know him better. What does he like? What are his strengths? His concerns? and so on.
Ask yourself if this person has a major problem receiving any kind of feedback or if it’s only when you report bugs. Maybe it’s the way _you_ report bugs.
When I discover _something unexpected_ (note I don’t use the word ‘bug’ at this time) in the AUT/SUT, I start by double-checking what I did to get the problem.
If I am pretty sure about what I saw, I approach the developer and ask him/her if they can help me understand the behaviour that I am seeing in the AUT. I approach the conversation from the perspective that I am seeking out their knowledge/expertise to help me figure out if I did something wrong.
Any good tester should always assume that they did something wrong – they configured something incorrectly or didn’t understand the functionality in some way. It is an application *in development* after all, so it is very likely that you didn’t understand something correctly.
This, therefore, is always the first thing I try to rule out. So, this is what I ask the developer to help me learn and understand about the system.
I walk the developer through the steps I performed, and describe my expectations based on the relevant Oracles. In the process of having the developer explain to me their understanding of the system, we come to an understanding of the problem – usually enhanced with the developer’s more detailed technical understanding of the underlying code.
At this point, I usually find that the developer is really quite excited to fix the problem as they have been a part of the process of identifying it.
When I have clarified what the problem is, I will return to my desk and log a bug report if that’s what I need to do. The developer usually asks me to create the report and put in the details that we talked about.
I have never been in a position where the developer has taken bug reports personally when I include them in the problem identification process.
Answer: Naveed Saleem
You need to convince developer, that bugs will help improving quality of his work, after he got your point. He will personally suggest you scenarios for expected bugs… 
Answer: Marc Morrell
A developers job is to create the functionality as required. The best kind of developer is the one who does a lot of unit testing before handing off to QA. Even with that, there’s bound to be something that QA finds. The developers that accept that as part of the job, and forge a good relationship with QA, are the best ones to have on your staff. For those that take it personally, they need a manager that puts them in their proper place. Get over yourself – it’s part of the job.
Answer: Adam Brown
Bug reports can be cold, hard and to the point documents. Are you just sending your developer a list of bugs at the end of the day? Talk to your developer before raising a bug in a way that says ìHey, this might be something that I’m doing wrong here, can I show you and we’ll see if it’s a problem?î They might react a bit better to this than saying ‘I’ve found X, Y and Z wrong with your application’.
Answer: Ajay Balamurgugadas
Try appreciating his work. I would say that building the relationship between you & the developer is important. At the same time, are you sure that your bug reports are not attacking him? Why not have a look at Bug Advocacy course at http://www.testingeducation.org/BBST/#tab4
No comments yet.