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