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?
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.
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
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.
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
- focussed on the product - not the developers
- 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.
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.
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