Hi,
It is sometimes so hard to have a proper conversation with the developers because they kind of hate us because we found there bug 
2 Likes
Welcome to MoT @ms.salona ! 
It’s true… not all developers are happy when you report bugs, you basically criticize their work. Imo that makes them bad developers. A good developer is a team-player who cares about the quality of the product.
They are humans, they make mistakes, everyone does so to me it’s pretty normal that they code bugs.
If only they would see it like this… 
What sometimes helps is when they made a fix for it or when they developed something nice, you can compliment them on it… and do it often. This way you can start to build up a connection between yourself & the developer, which will make them less hate you.
5 Likes
You actually made it sound so easy 
I guess i have to work on communicating in a better way. Thank you for taking the time to write abt it. Means a lot 
2 Likes
No problem at all 
It actually is! 
Some tips:
- Create a separate chat-channel for “compliments” only. Here people can give compliments about anything to anyone, even include marketing teams! (if you are a smaller company :D)
- At the stand-up: If you are the scrum master or if you are pointing out who’s talking, after one single person is done talking, just say ‘good job’ or ‘I like the way you handled it’ – anything really goes, it will give them a boost to work even better.
- After a bugfix or the development of a feature, just randomly say ‘hmm works good’ or ‘looks good’ or ‘I like the way you implemented this’
Anything goes really, communication is the key to happiness and that’s not only in our private lives! ;-D
3 Likes
I liked the idea of chat-channel for compliments. I didn’t think about it this way. Thank you once more
2 Likes
Hi @ms.salona . Well, it’s possible to start out a bug report with vague language like
“Is this supposed to look like this?”, or a “Not sure what causes this”, and even “Minor issue xxxxx”. This might feel like being gentle. Sometimes these trigger developers by being almost trolling, or just being low on facts. I like to think of myself as a lawyer, defending my bug report.
- Stick to facts, keep it clean and state why you think the observation is a defect. Example “When a user wants to forward an email, they must first authenticate, but it cannot if…”
- Bug title and component assigned. Always assign the bug to a feature or to the correct component. Having a short but descriptive bug title that points to where an issue is helps prevent “bug tennis”. Be clear about exactly what needs changing.
- Check if it’s a regression first. If the same bug was not there in a earlier version, divide and conquer to find the version the bug first appeared in. Developers will love you for that extra legwork. If finding the point that a regression occurred at is hard to do, use it as an opportunity to work together with developer to find ways to make it easier for you to nail down the date and/or the branch that caused the regression. You are a part of the team after all.
- Consistent language. Either stick to using customer personas and user stories to frame a defect, or if it’s a test that failed, make sure the bug description makes clear that a test case is failing. Always be consistent, for example describe the environment if you are unsure that environment is relevant. Give the developer a chance to teach you something too. Be open.
- Detail: Include only the relevant logs, don’t attach irrelevant files that add noise to a ticket. A well composed screenshot is very often enough, but your context may vary so be prepared with a backup plan. Maybe a local zip file of all the artefacts just in case they do ask for more logs later. Always note the version numbers.
- Own the bug, be prepared to accept an early build of the fix and test it and give feedback quickly if it resolves. When the bugfix makes it into Master, thank the developer directly @kristof has pointed out so many reasons this is vital.
Lastly, try to randomly join a few developer meetings as are relevant, daily standups, any high level design meetings, triage meetings and sprint planning meetings. These give you a chance to hear about possible bug areas early on, and give you a place to give feedback on not just bugs that are closed, but also on ongoing bugs. These days a lot of us are working remote, so meetings are online, and easier to join and just listen-in without participating if you are able to listen and continue working.
3 Likes
Thats really a useful set of tips. Everything you said are useful things specially about finding more details of bug could actually be helpful for developers. I’ll work on this too. And also trying to get more involved with developer, I liked this one aswell.
Thank you sooo much. I really appreciate each and everything you mentioned. I’ll definitely work on it.
2 Likes
Hi @ms.salona ,
I can give you the view of a developer - maybe that might be usefull to you 
Personally I get really good along with the tester of our team and even though it is for sure not the only reason one reason is that we get along good also on a personal level. So my first tip would be do not underestimate how important it is to have a coffee or beer (after work ) with your workmates from time to time.
Having said that here are some ideas how you potentially can improve the relationship to your fellow developers:
-
When you create a bug make sure that all necessary information like relevant logs are included.
I find it pretty anoying if someone may it be a tester a developer or anybody else creates a bug with just one sentence of description and no further information. At the end that creates more work for both sides. -
Be very careful in your communication.
Sadly some developers can not deal well with criticism which a bug in fact is. For instance when you talk about the bug try to avoid talking about the developers fault and concentrate on the failing piece of software.
- Let the developer come up with solutions - don’t do their job for them.
This of course depends also on the situation. However if you do that be aware of the danger of a misunderstanding. You might think “I have this cool idea and I want to help you…”. He might hear “Ah ok he thinks he is better in my job than I am…”.
Hope this helps 
4 Likes
Hey,
Thank you for responding. I wish every developer had the same cool attitude like yours. Well yes the idea of catching up with them out of the work could be helpful to build up the relationship. I’ll try that. And giving the relevant logs of the bug also is an good idea indeed.
Thank you so much. I got more insight about this. 
2 Likes
Lots of valuable insights above. I’d like to add some small things that helped me deal with my peer devs.
- If it is possible, demo what you are observing. I developed the impression, that then raised issues are easier accepted. Because the dev has seen it happening.
- Asking questions instead of stating something wrong. Sometimes I’ll start with ‘What if,…?’ , ‘What is to expect in the case, that…?’. By that I learn more about the system, keep the conversation going, and sometimes the dev realizes itself.
- And if they want to show some of their work, like source code, let them do. You do not need to understand everything, but you can ask questions. I noted some devs feel more comfortable and open up when they can show the code they’ve worked on.
7 Likes
I always record gifs, so they can actually see what I’m doing and they can see it “breaking down”
Which helped me a lot in the communication betweens devs & myself also, nice tip!
5 Likes
My dos pesos on this topic:
- Developers seem to be most annoyed by testers reporting trivial issues especially if someone is constantly asking them when such an issue will be fixed - us testers need to know who to prioritize and to pick our battles, sort of speak.
- The more technical a tester is the more respect will they get from a developer, developer are primarily technical folks and if you can explain the issue by including technical details (not just by quoting some spec and saying that the feature is not build according to the functional requirement) will make your collaboration easier. This also can help you in your automation efforts, you will be able to explain to the developers why you would benefit from having IDs on UI elements to make the code more testable, for example.
3 Likes