Looking for some advice on handling a developer relationship Iāve not encountered before and wondered if anyone had any pearls of wisdom to share.
Backstory - Me; perm tester of 3 years, testing large data migration project. Devs: 2 consultants drafted in for medium-term while recruiting permanent devs. One junior/associate shadowing another, who is more experienced.
Iāve been working with 2 developers in the situation described above. Basically, the quality iām receiving just isnt very good, iām reopening the same defects as many as 3-4 times and finding that hardly anything has changed with the fix iāve received. Theyāre asking me about the literal implementation of the fix for the problems iām describing, and theyāre not seeking help from experienced team members except if i really steer them into it.
The difficult part about this is, theyāre both really nice and the experienced developer is quite a nervous character so i feel really guilty about escalating this. I feel as a contract resource they should really be better though. Iāve hardly been able to progress in the week weāve been working together because whatās been built simply wonāt run, despite multiple times being handed back as fixed, and that in itself is really frustrating. In the past with these kinds of problems the dev in question has been really eager to get help and be better, or in some cases has been difficult and so escalation was kind of a no-brainer, but weāre in more nuanced territory here.
I kind of know that the answer is i just have to escalate anyway, but any advice or anecdotal personal experience would be appreciated.
Hi Sophie,
This is a tough one. You donāt want an escalation to spoil the working relationship, but there is a responsibility not to jeopardize the project. I would offer the following questions to consider if and when you decide to escalate.
Is a week long enough for a new person to learn about and contribute to the project? Contractors are expected to come up to speed quickly. On the other hand, data migration projects can require detailed knowledge of the system.
Are the attempts at fixes improving? For example are the specific problems youāre seeing getting fixed and replaced different ones? Or are the deliveries repeated attempts to solve the same problem?
Do the contractors have the resources to test their work before delivery to you?
Is it possible/advisable for you to talk with an experienced team member (without/before escalating) to get advice? or assistance in getting the contractors going?
If it is clear that you need to escalate, donāt delay. Prepare to tell your management (if asked) what you would recommend for the project staffing needs.
I hope this helps. Good Luck!
Thanks so much for your reply, I know thereās no real way for anyone to solve this for me but i really appreciate the support!
For your first point (with a couple of other points merged in), theyāve had a few weeks before this, getting up to speed and developing, this week is when theyāve released their development to me for testing sorry just to be clear. It was clear from the off the solution just wasnāt going to work though, and a lot of rework has had to be done which hasnāt so far been successful. They do have the environment to test in, which makes me think they havenāt been unit testing or unit testing well at least. Honestly, either way the time theyāve had wouldnāt have been enough for me personally, but i think they should have been more realistic in their estimate.
Second point - no to be honest, for the more minor defects so far thereās been 5 different ones where iām retesting and finding exactly the same error multiple times (with long stretches between it being released back to me). At that point i think you have to go and ask someone for help, which theyāre not doing unless i more or less point them at who they should ask
Third point - possibly the best course of action - and I think your point about assistance may be key - I could frame it based on the timescales being unrealistic given their lack of experience and based on what Iāve seen so far, and request more support or encouragement for them to seek support sooner.
Iām not there, so I canāt read the situation, but hereās a few possibilities which may occur in part or combination:
Nobody is managing your team.
Whose responsibility is it for a team member to get help from more experienced people? Do they have a buddy who helps them? Are they considered responsible? There has to be a solid working culture for a team to thrive. People are working out who does what and what their roles and responsibilities are. The guidance for this may come from the team, or a manager, or the loudest people, or a process document at the bottom of someoneās drawer. Or a mix. They need to know whatās supposed to be happening (if they donāt already), and so do you. Nobody can play the game if nobody knows the rules. If itās not your role to teach them then you need to find whose role that is or take it yourself. Donāt think of it as escalation - itās best for you, and them, and the client, and the company that you all work well together.
Your software doesnāt work because your team are building software that doesnāt work. Someone really should care about that. Is someone aware of it?
You are the parent of the team
You may be pleasant, confident, dress professionally, have a commanding voice - I donāt know. Coming to you with problems may be new additions trying to find their way through a system they do not understand.
They have no idea you are frustrated
You live in a perspective of understanding the culture and processes involved and your frustrations with dealing with your work are clouding the fact that they honestly believe they are doing the right thing and following the correct processes.
They donāt understand your bug reports
If they arenāt fixing the bugs you report, and they are asking about how to fix the bugs you report, it could be that they donāt understand your bug reports. Asking how to fix something could be their way of forcing a solution from a problem youāve described that they donāt understand. Iād consider bringing it up with them. With tact and understanding and a sense of responsibility that if you havenāt communicated a problem to them, in a way that they understand, then that is probably mostly your job to fix. I find that programmers are pretty receptive to being asked how they want to be involved and communicated with.
They donāt know anyone
Some people fear people. They donāt want to bother them, or they donāt want to make work for someone. Thereās a few ways to help this, such as social events with colleagues. A good way is walking someone to a person that can help them, introducing them by name and job title with a smattering of history, and giving a headline to the problem. āOkay [Newbie], this is Carl Carlington, head of widgets. Heās been here longer than anyone I know, heāll sort you out, Iām sure! Carl this is [Newbie]. [Newbie] is having a problem with widget cranking, I wondered if you could help them?ā. Something like that, but with charm and stuff.
People can be great at what they do and rubbish with social interaction. Which is a bit silly as social interaction is the bedrock of any system where more than one person is needed to get a job done. But if someone can hold their hand through the social bits they can do a great job. I am sometimes like this.
They are not very good
They might just not be very good. Not your fault, but not every hire is a winner. Is there a review process? Is anyone watching their work? Did someone hire a temporary employee and then assume all would be well? Where is that person?
Your process, metrics, methodology and wallpaper donāt work for them
You may have an enforced process, dogmatic measurement system, archaic methodology or poor working environment. Itās harder for non-permanent staff to get on board with any of these things, because why should they get invested in a poor system over a temporary job? Nobody gets into programming for the paperwork or being measured by the number of bugs they ācreateā. If they know theyāre going to leave, and nobodyās watching, and they have not been assigned any responsibility or given any guidance on how to integrate into a new teamā¦ theyād have to be a saint to want to improve that situation.
People donāt do the right thing, they do what the want. So we have to hire people who want to do the right thing. They might not want to do the right thing. They may not know what the right thing is.
Just some ideas. As you say, itās nuanced, but maybe some of these will spurn ideas you can use as a jumping off point to make things better. Hope thatās helpful in some way!
Hi @sscho
In this unpleasant situation I would try to ask devs what does they expect from you. Maybe sit in a meeting room with review feature status agenda, show bugs statistics and ask this question. Try to get as more details as you can. I believe they are intelligent people. And as soon as they say in voice their point of view, they can understand how much they put on you.
Another trick that I use - ask them for help (the best time - after they explain what they want from QA). Help to describe behaviour or expected results, help to understand root causes etc.
I hope it will help.
Second point - no to be honest, for the more minor defects so far thereās been 5 different ones where iām retesting and finding exactly the same error multiple times (with long stretches between it being released back to me). At that point i think you have to go and ask someone for help, which theyāre not doing unless i more or less point them at who they should ask
The ālong stretches betweenā a release caught my eye. The time between the construction and evaluation of new or changed code might be something to consider. When it becomes long, possible defects remain in the product and compound, or become more difficult to detect. Might it be possible to review new and changed products closer to their construction? In this manner, tester and developer work together towards a quality product.
Team relationships have as much impact on quality as the definition and construction of products. Iāve recommended to testers that they establish good rapport with developers early in the project. While you may not be early in the project, I believe you can still establish effective working relationships. The comments from @kinofrost are very good and it may be that some icebreakers may help to address some of those items.
The descriptions of the interactions give me the impression of physical or mental separation between the development and testing teams. Perhaps a few lunch time icebreakers could help to create more familiarity with team members, and create an atmosphere where product construction, from definition to implementation, is more collaborative.
Thanks all for your help. Thanks @kinofrost for your extensive list, made me think.
Weāre making a little more progress now, iāve kind of embraced managing the fixes - directing the guys to the help they need, and some cases making more suggestions for fixes than i would do usually to get the ball rolling, i think this may be a little out of my purview but i also think this maybe be the best short term solution.
Having said that, I think this treats the symptoms but not the cause (probably a combination of 1-7). I wonder how good our on-boarding information is also based on this. I also think it may have been a tragedy of the commons situation, where everyone thought everyone else had helped them with this or that when in reality no one had. I think they should have taken more ownership of this rather than struggle with the same issue for days at a time, but I guess they must have had a reason for not wanting to ask for help more. Iāll raise these questions with my manager.
What you said @devtotest about relationships was exactly the issue - we have a good social relationship currently and the guys are really nice, and i guess the question was about how to address the professional issues we were having without damaging this.
I guess thereās an innate āus and themā by the fact that we have development and test teams but i always try to minimise this as much as possible, no point in being adversarial when weāre all aiming for the same goal.
All good experience - thanks a lot for your help guys, the support was much appreciated.