Simon Morley posted a very interesting post about Challenges with communicating models about two weeks ago. Mental models are what we unconscously use to understand a situation, and communicating models to others is an interesting challenge: “[…] models do not transmit themselves – they are not necessarily understood on their own – they need the necessary “synch’ing” to align both parties to achieve comprehension, communication and dialogue”, as Simon summed it up in a comment on the blog post.
Simons post and the very good discussion he and I had about it started me thinking on the psychological perspective and how important empathy is: The “synch’ing” relies on empathy.
I really liked Simons blog post because above all it highlights the subjectivity of mental models. Models are not something you can implement in an organisaton just by e.g. e-mailing them to all employees. If you want someone to ‘get’ your model, you need to actively communicate it. Which is not possible without empathy.
Empathy is something that we associate with friendship and love, but it plays part in all communication processes between human beings, including those we as testers engage with at work.
From time to time we come across people who seems to have a total lack of understanding of what we’re doing: Colleagues, managers, customers. Most of the time, people who don’t understand need only a good explanation of the situation and our point of view. But sometimes, an explanation isn’t enough: Some people just don’t seem to want to understand.
People under pressure or in stress can be like that, and we often associate this with aggressive behaviour, rudeness. Or maybe we just see the rudeness, and only later realise that maybe there was a problem with understanding.
Empathy seems to exclude this behaviour. Empathy relies on a cognitive ‘feature’ of our brain which attempts to copy thoughts and feelings of other people: It tries to decode what those who you interact with are thinking based on verbal as well as unconscious ques, e.g. body language. It’s quite obvious that having ‘a notion’ of what someone else thinks and feels can make communication much more successful – if you feel sympathy for the other persons feelings and thoughts.
This can work both ways: Loss of empathy in a situation can mean that you think everybody else thinks and feels the same as you, and it can cause quite a lot of confusion and frustration when you realise that other’s are’nt thinking the same as you.
It can happens to all of us: The brain is not a perfect and consistently operating machine, but rather a very adaptable and flexible organ. For example in situations of crisis, empathy is one of the first things to go. A person in a crisis shift from being a social creature to goal oriented and focused, typically on survival – at any cost.
There are people who don’t want to understand, e.g. due to politics. But there are some people who involuntarily just aren’t able to get to ”the other side” of the argument, for example because they’re having ”a bad day”.
(Some people with autism and ADHD can be characterised by having problems with empathy. This is a quite severe handicap for them, since not only do they have problems decoding what other people think og feel, they can also have problems seperating their own thoughts and feelings from what other people are thinking and feeling. The sad situation for empathy impaired people is that they often don’t have a choice: Even when everything is good is it extremely difficult for them to decode other peoples thoughts, feelings and intentions – and therefore extremely difficult for them to communicate and interact successfully. Noticing how successfully others interact often just makes them feel plain stupid. This can lead to severe depression.)
Month: July 2012
Categories
Turning up the Heat
– What are you doing?
– I’m turning up the heat. To see if anything catches fire. It’s an old CID trick.
Detective Chief Inspector Jack Frost in the TV series “A Touch of Frost”
In the follow up post after my presentation at Let’s Test, I concluded that the next step in my work on black swan testing should be on operationalisation. This post introduces a a testing heuristic which I’ve successfully used myself. I call it “Turning up the Heat”
The basic idea is that odd things happen when a system is put under pressure, and that we can learn stuff about the system by doing so.
There are basically three ways to do it:
- Load testing, i.e. putting the system under exceptionally heavy load for a period
- Soak testing, i.e. loading the system lightly for a long time
- Destructive testing, e.g. crippling subsystems by disabling or forcing malfunctioning
They can of course be combined.
In the quote above, heat is a metaphor for the psychological pressure Jack Frost is subjecting suspected murderers to, and here ‘load’ is also a metaphor for any environment changes that can have an impact on the way the system works. It could be a high data load, e.g. 10 or 100 times the normal rate of requests to a service, but it could also be something quite different, e.g. a 10 degrees higher than normal temperature in the server room. The black swan domain is the systems domain, so any component in the complete system is a valid target for putting load on.
Likewise, ‘crippling’ is a metaphor here for doing something to a subsystem that will cause the subsystem to work differently from normal: It could be as simple as just removing a component, or bugs could be deliberately introduced. In fact the target doesn’t have to be one single subsystem: Changing the same thing in several subsystems, e.g. compile all software modules with a buggy version of some widely used library, can be a simple and efficient apporach.
As testers, we often don’t have direct access to the tools needed to load and cripple subsystems and complete systems. I find that in order to practically “turn up the heat”, I often have to rely on the help of others, e.g. developers and system administrators. This leaves me with a communication and cooperation challenge which should not be taken lightly.
There are no right or wrong approaces in testing, but there’s a risk of wasting time: I.e. spending time on preparations and never getting down to the actual testing – thereby not learning. That’s one of the reasons I usually prefer simple techniques rather than planned approaches.
In one project I’ve worked on, the testing tool we used had a simple load testing function. I managed to crash the test environment completely by just running the tool off my own pc, and this eventually gave us some important information about a vulnerable subsystem (the root cause of the crash was not what anyone expected when the system stopped responeding). I spent less than an hour on this test – though getting the problem diagnosed and the environment recovered involved somewhat more work afterwards by the system admins, I’m afraid.
This actually points me to another point related to cooperation: While load testing or soak testing is normally non-destructive, only do it if the project can afford repairing what might be affected by possible malfunctions of the system. This could include other testers not being able to complete other testing activities!
The illustration below is taken from an old book, I’m reading (*):
Fig. 3 shows a desert land which will be cultivated by irrigation, i.e. the artificial application of water. Fig. 4 shows the amount of fertile soil available. Now, the farmer can decide to spread the soil all over the area, by which the layer of fertile soil will be so thin that nothing will grow in any part of the land. That is not a good plan and all the work involved will be fruitless.
But there’s an alternative: The soil can be spread over a section of the land, for example the area marked in fig. 3. This way the layer of soil will be thick enough to ensure that there will be exuberant growth and good utilization in the smaller area. This is obviously a much better plan.
This scenario not only applies to farming: It illustrates a problem we often face in testing, where the amount of functionality being developed is much larger than the what we can cover in a decent way. It is my experience that it is always better to focus testing on sections of the system than to try to check everything: There will be areas of the system which will be left untested, but what you test, you will cover well.
As a decision maker, I’d much rather have in depth knowledge about parts of the system, than to know very little about everyting. It will give me much better foundation for making good business decisions.
*) The book is Holger Paaskesen: “Vi lærer for livet?” from 1968. It’s English title would be “We learn for life?” and it’s a book about school education.