Advice on Handling Dev Relationship?

Hi all,

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.

Cheers!
S

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!

1 Like

Hi hattori,

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.

Thanks for your response that really helped!

S

I’m not there, so I can’t read the situation, but here’s a few possibilities which may occur in part or combination:

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

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

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

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

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

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

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

1 Like

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.

1 Like

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.

S