Working with a new team, they all thoroughly buy into the idea that QA (quality advocacy) can assist in building confidence in the changes they are making. i regularly have chats with devs and help uncover areas they have forgotten or misunderstood. however there is one developer who only involves me when they are not confident in their current solution and feel that involving me in everything is process overkill.
Often when I talk with devs about their work they are confident there is nothing to be found, but then we regularly find ways to increase the quality. I donât want to be overbearing and impose myself onto this developer, but also eager to get opportunity to show the benefits i can bring to the team.
At the moment my best approach feels like trying to build a better relationship with the dev in general conversation, whilst working more with the rest of the team to show the value i can bring and biding my time.
how have other people worked through this problem?
How long have you been working in testing? And for how many companies/customers/teams?
What you are speaking about is indeed a very common issue. It has a lot to do with overall âteam dynamicsâ and the psychology of testing.
Our job is to question what other people did (or are going to do) in order to increase the overall quality of a product. Some people see us as partners. Other people see us as dangers, who will question their work. Some people just think we are useless because they feel that the product they are building does not need improvement (and this last type of people is really hard to work with!). Other testers will probably have other types of colleagues to add to the list.
During my carrer I worked with all types of developers, from people who were so enthusiastic about my work that it was freaky, to people who were downright hostile every time I tried to work with them. It is okay. Promoting our work is part of our job. Many developers have never worked with a tester before, or worse, they have worked with âbadâ testers. Testers who would despise them and make fun of their mistakes. Testers who were former poorly skilled developers and were moved to a QA position in a bet from HR to âmake something usefulâ of them. Testers who would not do their job properly, and give a GO to products that were simply not ready.
You need to earn the confidence of this developer, for whatever reason. It can be done directly, by showing your worth, or by proxy, by involving another person who is enthusiastic about your work (you know, the fanboy who asks you for help every time he makes a commit?). In order to achieve this, what I found useful is to have a chat with another developer who has a great work relationship with the developer I was trying to âreachâ. Do not be inquisitive, just ask how he/she sees the job, what that person thinks about quality, check if he/she may have had bad experiences with testers before⊠And so on.
Persist! If you do earn the trust of this developer, in the future, he/she might become your best ally. And you will probably learn a lot of useful things in the process.
Iâve been in the industry for a good number of years and many different teams, iâve encountered this problem plenty of times, but iâm always looking to learn new ways to connect with the diverse spectrum of personalities that is the developers.
Sounds like we have similar approaches, build a relationship and display value with everyone in the team that you can. Iâve also gotten involved in the past with a âcan you show me how this worksâ approach, as itâs as important for us to understand what they are working on and how it effects other tasks as it is to ensure the work is quality.
In that case I suppose you tried all the usual strategies. There is a last one that worked for me with really reluctant developers - but it is âriskyâ and requires development skills. Letâs call it the technical legitimacy joker.
I picked a really âbadâ ticket that had been there for months and passed to a few people. Used intuition to pick something that I could solve all by myself, without help. Took a deep breath and started to dig until I could solve the bug.
Once it took me one week (not full time!). The second time it took me two days. Both times it was a sound âhitâ - I had proven my technical worth and made allies in the process.
Rather than convince someone you can add value, it might be easier to achieve the same result through different ways.
Your goal might be to help the developer find things they might not find on their own but if they honestly believe they are fine and donât need your help, maybe you can get the developer to âhelp youâ.
In all honesty, when I talk to a developer it is a two way exchange. There are things all developers can learn from me but there is also things I can learn from the developer. Often just the act of communicating with someone results in me learning something new, something I never thought Iâd learn.
So Iâll often approach a developer letting them know they can help me as much as I might help them. The reality is that they probably donât want your help because they like being the person who helps others. If you appeal to their desire to look smart and help others, it could work. Iâll often ask developers questions. Sometimes I know where the conversation is going but Iâll play dumb and let the developer feel they are discovering the issue on their own. Sometimes it will take a long time for them to realize I was playing dumb but sometimes Iâm happy to always let them think they solved it without me.
I actually had one incredibly bright developer say to me one day, âYouâre actually quite smart. You could be a developer.â I smiled and said, âMaybe some day.â
There is a danger to this approach however. I once worked at a very small company. I had to trick all the developers including the CTO. They figured they found and solved all the issues. So they didnât need me. I was laid off.
I used to say âIâve been a developer, but I like testing moreâ. These days, I usually say something like "Youâre actually quite smart too, so maybe some day youâll make a good tester ".
Since âbeing smartâ at one thing doesnât mean being smart at everything, âdeveloper smartâ and âtester smartâ can co-exist perfectly within a team. And saying something like the above seems to remind the team members that we each contribute our different skills, and all can be useful.
Regarding the approach of asking them to help you: I wholeheartedly agree. Developer overconfidence, in my experience, is in many cases lack of (complete enough) understanding. And asking to explain what they built to you (âas if you were fiveâ), helps you both find out if it is confidence or over-confidence. So I find that âasking for helpâ becomes a great test
The way Iâve won people round in the past is by showing an interest in what theyâre doing. Asking them to talk through the code theyâre writing and asking âwhat if someone does this?â or âhow does this code handle this scenario?â This can help you catch some scenarios the developer may not have thought of.
The best way to convince people of your value is by demonstrating it. If you raise a few unconsidered scenarios or highlight a few assumptions that the developer has made then your developer should see your value pretty quickly!