Tester-Developer communication

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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).

Answer 8

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.