Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

While a lot is written about developer-developer, developer-client, developer-team manager communications, I couldn't find any text which gives guidelines about tester-developer communication and relation.

Whether testers and developers are separate teams or in the same one (in my case, I am a lone tester in an agile development project), I have the belief that how testers are perceived is extremely important in order for testing to be well-accepted, and to serve its goal in enhancing the quality of the project (for example, they should not be viewed as a police force).

Any advices, or studies about how a tester should communicate with developers?

Update: Thank you all for your answers. They all confirmed what I had in mind. As for now, my team was very receptive of my role and we ended up making real progress. I could have chosen more than one as the answer but I had to make my decision.

share|improve this question
1  
When you find a bunch of bugs, it is a good idea to ask how they should be filed, also whether a bug should be failed or spawned as a new one. The perception of a developer by others matters. Every time you fail a bug, it potentially reflects badly on him/her. Ideally you should be sitting within 9 yards of that developer and talking, or else you are not really doing scrum. –  Job Feb 2 '11 at 3:59
add comment

8 Answers

up vote 11 down vote accepted

The easiest way to improve communication is to work together with your developers (and designers and architects etc) and slowly breaking down those silly roles and eventually realize that we all are testers, except that some of us are have more experience than others.

For agile, just do it "by the book". Testers are part of the team and not just some external entity that you hand over stuff to when it's done. Your valued expertise is put to use during the whole development. First when creating user stories you help derive acceptance tests and make them automated. These tests are then used by the developers in their work. You also spend time daily to with exploratory testing of partial and completed work, and talk with the PO to clarify and improve your tests continuously.

That is what I mean when I talk about "work together". I am completely sure this is how communication in a team should work. This article explains it very well btw.

Opposite to this, many organizations like to handle development by putting all testers (and DBAs, and designers and programmers) in separate departments. This works against communication and only serves to cements the idea of phased development. Trying to improve communication in such a situation is possible, but the minor improvements you can expect is not worth the effort. At least not compared to actually putting people in the same room and creating cross-functional teams.

share|improve this answer
    
Most of the time, it's hard for both to communicate, as they have a different vocabulary. Sending annotated screenshots (for example with Usersnap) saves a lot of time and helps developers understand the testers even better. Additionally, meta information like the used browser, screen resolution and operating system are provided automatically. –  Gregor Aug 21 '13 at 13:06
add comment

I firmly believe that good communication between developers and testers is critical. As for the best way to do I'm sure that there are many good approaches but here is what has worked best for me.

Direct/Personal communication! I have found that personal, not email, communication always works best. It allows the developer and tester to form a personal relationship. Once you have that things seem to work better and tend to flow. They never have problems running a special test or going the extra mile for you. The same goes for the developer and I always take the extra time to look at things that they need help on or are having an issue with. In my experience it makes solving issues go faster, there is less wasted time.

share|improve this answer
add comment

The number 1 tool I've found that I, as a tester (SDET), can leverage to improve dev-test relationships is honest flattery, especially in the form of seeking mentorship from devs.

Hopefully, the developers I work with are betters developers than I am. They aren't perfect, or I wouldn't have a job, but there are a lot of things they know better than I do. They've been pure development, while my attention is partially focused on testing. I note those things that they do better, and I mention them frequently. When I read their code, I note elegant details or neat uses of design patterns and bring those up in conversation. I imitate the developers, using similar coding conventions when possible, and integrating components from production into my test tools when appropriate (e.g., logging). I recognize their expertise, and as a result they are happy to acknowledge mine. Mind you, if I think there is a better way to do things then I absolutely do speak up - but I aim to give more positive feedback than negative, overall. Generally, I try to make negative feedback more formal and impersonal (e.g., bug reports) and positive feedback less formal and more personal (e.g., conversations in person).

Giving positive feedback about quality as well as negative feedback and asking for advice changes the relationship from being contentious to being about teamwork and mutual learning and lowers defensiveness. The developers know they can trust me to always say more good things than bad, so they feel comfortable listening to me. Also, asking insightful questions about development raises their opinion of me and breaks through the "SDETs are failed devs" stereotype (where it still exists).

share|improve this answer
add comment

I never used to believe that there is always a level of disagreement between developer and tester but I had to face this situation when one of my best friend got tester role in the company I was working and to my surprise he was assigned same module to test that I was developing and so it was real FUN working with him and I must say that it is very important to understand other person's opinion in such situation and have control over one's own ego, this helped me a lot and we guys gel well on our professional commitments as well as personal friendship level.

share|improve this answer
1  
Was there an HR violation at the end? –  Job Feb 2 '11 at 3:57
    
No there was not HR Violation as such. –  Rachel Feb 3 '11 at 20:29
add comment

Since you stated you are a sole tester in an Agile environment (assuming Scrum) perhaps leveraging the retrospective meeting as an open forum to define the process of communication may be in order.

As you know the restrospective meeting is to address wrinkles within the Scrum process. These could be items like allowing developers hours X-Y of uninterrupted time, email only communication on Mondays and verbal the remainder of the week, whatever suits YOUR team; as communication is never a one size fits all approach.

As a developer I appreciate a tester who shows initiative. They don't draw lines...they want the defect resolved; regardless of the root cause. Developers and testers have to separate feelings from business. Defects are part of the business since humans are involved. The best approach to defect resolution is an aligned team set to resolve the defects holistically. When lines begin to surface and borders are laid out; communication will break down.

Take advantage of your daily stand-up meetings. Become involved as much as possible; not just with the testing but with the product in its entirety. At the end of the day a developer and a tester are working on one goal and should always keep that in focus.

share|improve this answer
add comment

A tester should be very clear and precise with developers when communicating about errors and testing. A detailed list of steps to reproduce the error, screenshots if necessary... Vague descriptions of errors that cannot be reproduced or have unclear steps to reproduce will very quickly sour the developer-tester relationship.

share|improve this answer
2  
+1 - and I'd love to give it +1000. Developers are great at building software, but often aren't experts in using what they build. When you're a developer who's under the gun to fix a bug, and the bug report doesn't have clear, easy to follow reproduction instructions, and the tester who did the report isn't available, life is hell - and that's true whether your doing Agile or any other methodology. Write your bug reports as if your grandma had to do the reproduction, and life will be good. –  Bob Murphy Feb 2 '11 at 5:50
add comment

I prefer seeing testers as part of the same team. In that regard there is no issue of communication.

Whenever a tester has to speak to a developer or the other way around just come and let's have a chat. Just a routine of everyday.

However, both parties have to respect each other and do their job properly.

Testers need to provide thorough details on the bug conditions and not report something as a bug while it is by design. Especially when it only takes to ask the guy over there about something which suspiciously looks like a feature.

Developers have to take a bug report seriously and investigate in deep not just close the issue if you don't reproduce the bug in five clicks.

Professional attitude is all it takes.

share|improve this answer
    
"I prefer seeing testers as part of the same team. In that regard there is no issue of communication." Being on the same team does not mean communication issues will not surface. –  Aaron McIver Feb 1 '11 at 17:20
1  
@Aaron: You're right. However if you decide to see testers as a lower layer under your feet communication issues will arise guaranteed. –  user8685 Feb 1 '11 at 17:35
    
..I take the tact..."Have you hugged a tester today?" It works wonders. –  Aaron McIver Feb 1 '11 at 17:48
add comment

I am a firm believer in ANY kind of communication between dev and test.

Too many times I've seen bun fights between each team, petty back and forth ("closed by design", followed by "reopened" etc).

I always tell testers I work with to come and speak to me if they have any doubts at all.

One thing i truly HATE, is developers who get all arrogant about testing and talk down about it, so anything I can do to foster good relationships with test teams, I try to do.

share|improve this answer
1  
What are "bun fights"? :) –  Marcie Feb 1 '11 at 14:56
1  
+1 I work very closely with the QA lead on my current project, and I find it to be extremely beneficial to my productivity. I'm lucky that he is also a fully-qualified developer, and he often suggests solutions to defects that he uncovers. –  Adam Crossland Feb 1 '11 at 14:59
1  
bun fight = fighting over buns.... bun = cake –  Ozz Feb 1 '11 at 15:26
2  
Cake is the only thing worth fighting for at my office. –  JeffO Feb 1 '11 at 18:06
1  
.... There's cake? –  Dan Ray Feb 2 '11 at 13:23
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.