Introduction
Psychology – the scientific study of the human mind and its functions, especially those affecting behavior in a given context.
Question – a sentence worded or expressed so as to elicit information
For me, a key skill in testing is asking questions. As testers, we should be asking questions about the requirements/design/system at every opportunity we can: Who will be using it? Where? What happens if…? How does it work? How should it work? Why…?
These are all good questions, but the focus of them is to get information about the product being tested. Maybe we should be asking other questions? Not about the product, but about ourselves and of our peers and colleagues. And not to just elicit information either, but also elicit a desired response or behavioural change.
As testers, we sometimes find ourselves trying to deal with difficult situations and/or people. The natural response is try and find a solution to the problem or overcome the objections. Instead, maybe we should be asking more questions to challenge the problem faced until an agreement is reached?
What questions should we be asking of ourselves, peers and colleagues, and how?
Start of a journey
I did a presentation at the Agile Tour in Dublin last year on the rewards of collaboration when transitioning to an agile based approach. One of the points I raised about what didn’t work was when I tried to share my tests with the developers in the scrum team. There was still a ‘them and us’ attitude, and the developers wanted to keep their work separate from mine. Having been to a few seminars and workshops, I knew this was not the way we should be working but I didn’t have an answer to their response.
It was only after I had finished the presentation and was having a beer afterwards as the adrenaline wore off, that I realised I shouldn’t have been looking for an answer but be asking more questions. But what?
Look inwards first
I didn’t have an answer to the resistance from the team, because I hadn’t challenged myself first. In this context, I should have asked myself first: “Why did I feel it was important to share my test ideas?” and “What was I trying to achieve?”
I was aiming to build a shared understanding of what the team was delivering. So my response to the team should have been a question like this, “Do we have the same understanding of what we are trying to deliver?”
In a later sprint, I did have success when asking the same question. Using my tests (in the form of a mindmap) I was able to guide the unit testing approach to the algorithm engine that was a key part of the functionality being delivered.
Re-phrasing the same question
I also realised that some members of the team would still not have reacted positively. So what questions should I be asking them to get them to collaborate? In this case, they were more concerned about bugs raised. So I think this would have got their attention, “Will you help me reduce the number of bugs I raise by reviewing my tests with me?” i.e. I would be appealing to their base nature.
Using psychological techniques
(I go off on a bit of a tangent, but please bear with me.)
To me this is the ‘dark side’ of asking questions – something we shouldn’t have to do but sometimes need to. Now it was around this time that ‘The Force Awakens’ had just been released, which triggered a whole new train of thought:
‘Dark Side’ -> Star Wars -> Using the Force -> Jedi mind tricks -> STOP!
If you strip everything back, what is a Jedi mind trick in essence? It’s a way of influencing people and getting them to change their behaviour – in other words it’s a psychological technique.
After a bit of research, I found three ‘real-life’ psychological techniques which we probably use but at an instinctive level:
- Why Not: when refused, ask “Why Not….?” This should only be asked after you have asked yourself “Why?” and you are clear in your objectives.
- Foot in the door: start off small and build up.
- Door in the face: make a large request then follow up with a smaller request if the first is refused.
In effect, from being rejected initially to being able to work on the unit tests for one part of the application was following the ‘door in the face’ path – I just didn’t know/realise it at the time. Looking back, I should have followed the ‘foot in the door’ path by starting off small to start with. I.e. focusing on what we were delivering each sprint and building up the shared understanding incrementally.
Sharing the load/love
Why should it be just testers asking questions?
I recently joined a team of developers and testers that is collaborative in nature, but not sure on how to get the testers more involved as there is a mixture of general support and project work. So I took the ‘foot in the door’ approach to get testers more involved and at an earlier stage of development.
I started by asking myself why I thought it was important and what I was aiming to achieve. I then put a proposal to the team that we all ask the following questions when starting a piece of work:
- What is the technical and/or business risk with the change? Is it well understood?
- Impact to the test team – does the change have a fundamental impact?
- Value – could the testers add value to the process or will the get value from it?
This has led to testers not only being involved during development and being included in the design discussions but also being able to play a greater role in the projects from inception. Thus using the psychology of testing can help you.
Summary
- Don’t always look for an answer first when asked a question or face a challenge.
- Ask questions of yourself first – you can’t win an argument if you haven’t challenged yourself first.
- Re-phrase the question to suit your situation – different people respond in different ways.
- Remember there are different psychological techniques that can be used.
