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