How to change the "us against them" mindset?

I work with two teams of developers and another tester, using the scrum framework.
When developers think they have finished their feature, they call us to make some tests on their machine before the pull request. We call it pair testing to make it short, despite it is not properly pair testing.
When they call us, they often make nervous jokes about the fact that we will find a lot of defects, we will break the system and so on. And we often do (not breaking the system, because it is already broken!), we often find mistakes and paths that don’t work as expected or that was unknown or that was not tested at all. That’s why this process is still useful.
The fact is that developers are afraid of that step because we show them that they did something wrong and they will have to rework on it. They see it as a “sanction”, as if we were the teacher at school and tell them they are idiots. It is the same with bugs found in production, when they have to fix them, they see it as “I made bad work and now the punishment is to rewrite it” (that is exactly what they told me).
In a perfect world, I would expect that they would be grateful and say something like: “thank you for helping me to deliver better features to the user”. Same for bugs, I would like that they would say “that’s cool, by fixing that, I will help to make the user experience still better!”. I said them that they should think that way and that it is far more positive, but they still have the “sanction” mindset.
All my team members are juniors or have never worked with testers before. And this is all about psychology. How to collaborate as a team, enforcing quality with other’s skills, instead of the usual thinking of “us against them”? Do you have feedbacks and experience where you successfully changed that mindset?

1 Like

Option 1: Offer positive feedback on a regular basis. “Yes, I found this problem, but the feature as a whole is AWESOME!” If our feedback as testers is only negative (telling the programmers that they made mistakes), then the system of feedback will be largely ineffective.

Option 2: Ask questions (even if you think you know the answer). “How does this function work?” This lets the recipient of the feedback know that you are interested in what he is doing and will increase engagement in the conversation.

Option 3: When working in pairs, let the other person control at least part of the process. Through questions and comments, you may help the programmer find their own issues, and the blame for issues is shifted less to you (you didn’t find it!).

Option 4: Find more issues prior to testing. Through checking the specification and design documentation, you probably know a few key places to check for bugs. Make sure that the rest of the team knows before they step into the trap.

Option 5: Talk about testability a lot outside of the test sessions. If your team starts to think about testability, the chances are that they will start running the tests themselves before giving you their work.

4 Likes

Hi Nicolas,

‘When developers think they have finished their feature, they call us to make some tests on their machine’

Does that mean your dev’s do not unit test their code & run their own regression testing (all their unit tests put together in a suite) on their local, prior to chatting with you? That is odd!

Yes I agree what you described is NOT pair testing.

I could never understand it when testers & developers made weird comments about each other. The truth is we need each other and we need to feel both the tester & developer has each others back.

I have always worked at getting to know personally all my developers (usually I was the single tester with 6-8 developers) by chatting at the coffee room, asking about their family/children/dogs/cats. Their birthday making a cake (that’s just me my passion is baking) or simply wishing them a happy day. I always said good morning to each and everyone of them by name EVERYDAY. That single action changed the team completely as no one said good morning before that. I try hard to create a relationship before I need to tell them something isn’t right with the code I am testing.

Second point… code to most developers is personal and artistic, so they are sensitive about it. I try to take the approach of working with them to produce a better product. If I find defects I personally chat to the developer and try not to make it public knowledge (if I do not need to), nor do I talk about it with other testers. I work with the developer around getting it fixed and retested. It’s about saving face and allowing someone to keep their mana (Maori language for kind of pride but in a good way). As a tester I worked tirelessly at breaking down those barriers and it sounds like you are doing that too.

When I first came on board on my first team I had to gain their trust and respect. Three years later when I left, as I walked out of the room all my developers stood up and shook my hand to wish me farewell. During that time I had made mistakes but what goes around comes around. The developers helped me fix it quickly and quietly so I could save face. That is what a team does, they have each others back.

As testers we need to break down those barriers of nervous jokes about breaking the system etc. My answer would be actually no I don’t want to break the system in fact I am fairly confident you write excellent code so I probably won’t find anything…

  • When you do find something I usually start with could you have a look at this I might of misunderstood what the AC was around this change?

  • Show them - Make very sure now you can replicate this and it does not meet the AC

  • Do not say anything else but wait patiently if its longer than 5 minutes ask the developer if they would like you to pop back to your desk and they can let you know when they are ready

  • When the dev asks you to retest execute the exact same test and when it passes you do not need to say anything further about the issue except excellent that is a pass.

  • Both you and the developer knows what has happened by not saying anything else face is saved

  • As you develop your relationship with the dev you will be able to talk more about what has happened.

I hope this might help you and btw my partner is a developer too. We regularly get wow your relationship must be “interesting” a dev and a tester hehe :grin:

3 Likes

First I’m assuming this is the case from their perspective as well. Sometimes a nervous joke is just banter from a nervous person - someone feeling that they’re supporting you by exalting your skills, but without the confidence to say so directly.

When you have people who want to (or feel that they have to) improve, have fewer problems earlier, build something to be proud of, and so on, then you can move on to improving your working relationship:

  • Ask for feedback on the service you’re providing them
  • State that you don’t mind finding problems - that you’re there to provide information, not find fault. If I hear a nervous joke about breaking things I sometimes say something like “I don’t actually mind if it doesn’t work, or if problems are fixed, as long as I can easily let you know what’s going on”
  • Provide them with some things you will be looking for. An insight into your test strategy. A checklist you may use, a test you may perform, a risk category you may investigate. This will help them know that you’re thinking about problems before they’re written, help them to know that you’re helping them write fewer problems, and remind them that you have to inspect their work at some point.
  • Talk to your line manager, PO, agile person, whoever about the problem and try to get them to support your endeavour to change things. Say why it’s good for the business. Maybe use the word “cost”. If the whole team supports the idea it’s easier to get other people to join in.

The way I find most effective, though, to communicate the idea that I’m there as a support role and I feel that someone hasn’t come to understand that is to tell them, tactfully.

Another factor may be that the culture doesn’t permit failure. When people are worried about how they look more than what they do they spend more time hiding and lying and covering their tracks than they need to. When people realise that a lot of bugs are often a symptom of a problem in a system rather than the skills (and identity) of one person they can then move on to find and treat the problem.

3 Likes

Have you seen the masterclass we did recently with @maaret & @franzi?

There’s also a post on here with questions we didn’t get to answer in the masterclass that might help you.

This ties in with a conversation I was involved in recently:

A developer was speaking about how he had learnt abit about the testing mindset - in his view it was the mindset of a pessimist - I countered by saying I thought software testers were more effective if there was a sceptical mindset at work rather than a pessimistic one.

He then followed up with the view that testers essentially criticise - in my view the role of testers is more to critique the product. This means that the testers are

  1. focussed on the product - not the developers
  2. evaluating in a constructive fashion

If the develpers are demoing to you - it is a great way to informally catch bugs and fix them fast - better than finding them later and having to raise separate tickets etc
Also discussing tickets at the very start of the sprint can be helpful - have a brainstorm with the developer about what is needed for this story - developing a draft test strategy can often help to flush out bugs before you get to the demo/pairing stage.

2 Likes

I feel one of the core problems here is that you’re getting involved with them when “it’s done”.

I find really helpful in our sprint team is being involved upfront, talking to developers about how we plan to test it - especially any gotchas. It helps build up the relationship, that we’re not here to undermine them, but we’re trying to trash this and build the best software we can, together.

Sometimes we’ll mention “we are going to test X”, and the developer will go “ooh … yeah, maybe I need to think about Y”. BINGO - job done.

3 Likes

Thanks everybody for all your feedback, it is very helpful and I will try some of yours tips in the next days.

I think that one of the root causes of the situation is that the tasks (user stories) are really poorly described by the product guys, often only with a sentence, with the technical solution, etc. They don’t want to spend time writing stuff and they do want to see perfect results… So, I am beginning an experiment: I will write all my test ideas in the Task, right below the description and just after the grooming meeting. So I will raise useful questions sooner and and developers will know what to except about the “validation” phase. Let’s see.

@heather_reid I did not see the video, but now it is in my todo list :slight_smile:

2 Likes