How can software testers work effectively with developers?

Questions
#1

This topic came up today in our MoT Slack. Where conversations often seem go into the direction of assuming that testers are not technical.

Often developers will explain things in child like ways because they assume testers don’t understand enough.

Or testers won’t get included in certain conversations because they are assumed to not be relevant, or are unqualified.

How can software testers tackle these situations in a positive way?

Some ideas I have are…

  • Make connections: grab a coffee, team up or sit together (virtually or not)
  • Create conversations: look for excuses to have conversations, name drop things you are working on, make a point of skills and knowledge you have
  • Make your work visible: show people what you are working on, stick things up on the wall
3 Likes
#2

I’d like to extend the question…

What if the tester is actually:

  • Has no prior technical/dev background
  • Not qualified for technical/architecture conversations

How can he -the tester- tackle these situations in a positive way?

#3

I actually covered a fair amount of this in the series I wrote for the Dojo a while back, Blazing New Trails: Tips for the Lone Tester. That series was mostly aimed at people who found themselves as the first and usually only tester in a company, but the section on communicating with developers applies here.

There are still plenty of developers who have never worked with testers who do more than rigidly follow a detailed test plan - the testers who are sadly discouraged from any sort of exploration of the software they test. If this is what they’re used to or all they’ve ever heard about, of course they’re going to assume testers don’t understand the technical talk.

The methods I’ve used include:

  • In discussions, using the technical terms I’m familiar with and then phrasing them in a user-friendly way for customer support purposes to make it clear that I understand the technical side.
  • If I work on test automation, demonstrate what I do and ask for code reviews.
  • Where it’s reasonable and I know the developer in question will respond well, I will point to the line of code that causes a problem (particularly handy when debugging complex Javascript on web pages - but only if the developer I’m working with is comfortable with me making technical comments).

Initially, I aim to build trust in my abilities and my work. Once I have the trust, I start to slip the more technical information in.

I’ll also mention any technical qualifications I have, just to seed the idea that yes, I do have technical knowledge. (“Oh, yeah, my first programming language was Java, so I have trouble working with languages that use pointers, but the others I can generally pick up pretty quickly” “I’ve worked as a developer. I prefer testing.”)

It’s always going to be a slow, steady process unless I get lucky with a new team, but it works. We don’t have control over the way developers have worked with testers before. There are too many places that still expect a waterfall lifecycle with developers tossing code over the metaphorical wall for testers to follow a script any robot could follow to guarantee that we’re going to get developers who have had the good fortune to work with our kind of tester - whether that tester is “technical” (which usually means “can code” even though all testers are technical in the sense that we work with technology and have our own body of knowledge) or not.

4 Likes
#4

he - the tester. Or she - the tester. :slight_smile:

1 Like
#5

Become an indispensable and visibly useful part of the team. Support the coders in their endeavours. Give them reports on the work you did and the problems you did not find - showing them that you’re willing to put effort into making them look good and positive feedback on good work. Bring them snacks and suggest cool games to play with them. Show them your Pokeman card collection. Whatever it takes to show that you are useful and an actively willing support role for the team. Then you have the equity built up to ask for process changes and conversations.

If people are talking to me like they think I don’t understand I use enough technical language back at them to prove my level of understanding. If I don’t understand I say something; done enough times this will train people to know that silence infers a level of understanding. I also convey that I know what I’m talking about when it comes to testing, to prove that I belong in a team full of engineers.

Usually the inclusion and conversations follow naturally once my position, knowledge and attitude has been established. I’m lucky to have been a fairly young male with a large build which helped me to be taken more seriously. I also found that people listened to me more if I wore a collared shirt.

#6

both :slight_smile:
I do believe in capabilities and what someone can do, not in gender

#7

Which is why I personally prefer “we, the testers”

#8

While I have a degree in computer science, I did find that I still had to prove myself. I didn’t go around saying “I have a degree, you know!” lol
Some things I did early in my career to help me get traction w/ respect from software engineers:

  • attend user groups for software development (I started at .NET user groups because that was what we were all working in)
  • keep up on news/forums etc of relevant areas of software development. This way I could have a knowledgeable conversation about those things out of the blue, or contribute to a conversation
  • work more closely with one or more of the engineers. I found that if I got the trust/respect of one of them, it was easier to get it from the rest of them.
  • pick up odd jobs that are technical. I learned AWK to maintain a script nobody had time for. This was before we were doing automation. I not only got some respect from that from the devs, but automation tasks from my manager as well
  • geek out with them about something - gaming, whatever - and get into technical details about it.
  • dig into the technical details of bugs and add those details to the bug reports. This one can be tricky - some devs I worked with loved that I could pinpoint the line of code where a bug happened, others didn’t want me treading on “their territory”. Either way, giving as much relevant information as possible that included how the architecture or data flows affected this particular bug
  • if process flow or architecture diagrams are missing, I created them. I’d start from what I knew, then ask for some devs to review. They’d see that I know a lot of technical details from that, and the diagrams helped everyone gain a shared understanding
  • work with support folks. They often have the technical skills needed to dig into issues, and are less likely to be territorial

Now, I feel comfortable and respected among testers and software engineers alike - they’re both my “community”. I attend dev conferences as well as tester ones (and speak at them, of course)

3 Likes
#9

@amratya just to give you context to the comment/situation…

@cookhazel93 highlighted the he / she thing because the original discussion on Slack ended up pointing towards gender bias, not in favour of women.

It may seem like an insignificant thing, but the constant use of ‘he’ for referencing people in tech is quite draining for all those that aren’t male, or identify as male.

Just clarifying, but don’t want to drag away from the original conversation nor make a big deal of it. :peace_symbol:

1 Like
#10

You have just described me in that I am not a developer nor do I have a lot of experience technically BUT I build relationships. I have found every developer I have worked with (I am always the single test resource embedded with developers) are very happy to take the time knowing I am asking relevant questions to make their life easier. I also do not waste developers time with silly questions that I could google myself.

Example tonight I asked a developer how would I go about using AWS S3 to store data I was going to stream from a raspberry pi to video my dogs while I am at work. He gave me all the how to’s step by step and links for me to learn.

Testers start building relationships and break down any walls. Take the first step and all the rewards will come.

I wrote about my experiences in my blog have a read see what you think.
https://wordpress.com/post/testingsoftwarerecipes.blog - Testing the Adversary Profession!

1 Like
#11

That’s awesome @g33klady they are all excellent points I like the one about flow diagrams. I agree if they are not there or incomplete work on them not only for your own system knowledge but for the ones coming after you so they can on-board faster. Nobody likes documentation so the person doing it becomes a very valued team member.

1 Like