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