Friday, 11 April 2008

Software Testing Lessons from Brief Counselling and Therapy

Brief Therapy (and other therapeutic models) provides me with some useful 'heuristics', approaches and techniques to apply during my testing.

Brief Therapy - often called Solutions Focused Therapy concentrates on moving the client towards the 'solution' that they want to achieve through the therapy process. Different from problem focused therapy which concentrate on the problems that led to whatever situation and symptoms the client currently faces.

I have read a fair few Brief Therapy books in the past, but this particular blog posting comes after reading "Brief Counselling: Narratives and Solutions" by Judith Milner and Patrick O'byrne - not a great book but a solid and 'brief' useful overview.[amazon.com][amazon.co.uk]



In some respects we might immediately associate problem focused therapy as having closer links with Software Testing - since we often find problems. But we do this but exploring possibilities and opening ourselves up to new choices, experimenting and trying new things - the essence of solutions focused therapy.

The immediate parallels I see when comparing Software Testing to Solutions Focused Therapy include:

  • the desire to 'change' the client's state
  • the use of questions to change state
  • the use of contextual questions based on the surface language used by the client
  • the identification of 'what if' states and actions to get there
  • the use of 'exceptions' to 'problem' states

to see the parallel with testing we can replace 'client' with system

  • the desire to 'change' the systems state
  • the use of questions to change state - (tests ask questions of the system)
  • the use of contextual questions based on the surface language used by the client (product clues)
  • the identification of 'what if' states and actions to get there
  • the use of 'exceptions' to 'problem' states

Granted that when I apply the various techniques and models of brief therapy the 'solutions' that I pursue tend to consist of 'error states' rather than resourceful states. But I can live with that >:)

So what types of things do Solutions Focused therapists do that testers can make use of?

  • Metaphor
  • Possibilities
  • Resourceful presuppositions
  • Exceptions

Metaphor

The brief therapy Metaphor technique involves the 'client' naming their problem. Then using the language of that metaphor to describe solutions or identify new approaches to tackle the situation.

When approaching a system, or an area of the system, or a use of the system, can you identify any metaphors that you could use to describe it in a similar (yet different way). This may then trigger different thought processes about ways to use or misuse the system.

e.g. one metaphor for the file upload function for a web site I have used involved the entrance to a flat that I used to live in - we had a downstairs door, then a multi level stair case, then a tight door to get in to our flat, the stairs continued up to the flat above. Situations that can occur in this metaphorical situation:

  • clear path to the flat
  • something blocking the stairs
  • something too big to get up the stairs
  • something that gets stuck going up the stairs
  • someone going up to my flat at the same time as someone going to the flat above
  • going up to the flat and discovering I have no key and get locked out
  • someone unwilling to come in the front door into the tiny hallway

Each of these can relate to a file up load scenario

  • good file upload
  • previous bad file upload
  • big file upload
  • error condition during file upload
  • multi user conditions
  • server down conditions
  • locked file

Metaphor can act as a high level heuristic - I say high level because each metaphor itself acts as a heuristic, so we could view 'Metaphor' as a high level or even a 'meta-heuristic'. Or to avoid getting tangled in linguistic knots or a flame war - you could call it a technique of 'metaphor analysis'. I don't mind what you call it - just try it.

Possibilities

The Solutions Focused Therapist constantly tries to open the client to new possibilities - while utilising 'resourceful' past experiences to validate their reality in the client's model.

So the language that the therapist uses 'opens' rather than 'closes' the discussion.
e.g. 'instead', 'and then...', 'what if...', 'act as if...'

As testers we focus on possibilities, so adopting the possibility based language can help identify 'new' things to do.

Possibility focused language also helps introduce doubt into the absolute nature of a statement. And helps avoid falling into the time-bound trap of believing that we have 'done' everything that we can to the functionality.

"[agree tasks where the client] is invited to have a go or to experiment with them and keep track of any difference that is made. However, the invitation is a permissive one in that the clients can change the task or do something they have thought up or that might feel more useful. When they take notice of what difference is made, if this is valuable the task can be repeated, if not it can be changed."

from "Brief Counselling: Narratives and Solutions"

In exploratory testing terms, if we found it valuable we might pursue to the point of stressing the system or pursue 'variety' rather than repeat. But this reads like a description of Session Based Exploratory Testing to me. The therapist tries to get the client to 'learn' new behaviours and open them up to new choices and options.

Resourceful presuppositions

A 'brief' therapist knows that they don't have time to delve deeply into a past history to 'fully' understand a problem and draw lots of conclusions about it. They want to add value to the client as quickly as possible.

They also know that they don't need to. By focusing on the clients aims and working with the clients model of the world (rather than some sort of objective reality) they can start suggesting changes and experiments and observing progress towards that solution, building on steps that take them forward.

"It is not necessary to understand a problem in order to solve it"

Testers do not need to know everything about a system to test it. Testers bring a vast set of experiences and skills which they can use to generate options to try on a system.

The system presents its own model of the world to us, and as we observe it and learn more about it we identify new ways of questioning it and new experiments to have it try.

Exceptions

The therapist looks for exceptions. Typically the client furnishes these during routine questioning, but the therapist has to listen for these and remain capable of hearing and acting on them when they happen.

Likewise, testers need to observe the system well, spotting any 'exceptions' and then examining them.

  • How did you do that?
  • How do we know that happened?
  • What did we notice?
  • What difference did we notice? had the context changed? did we do something differently?

The questions tend to relate to mechanics - "how?", "what?". Rather than beliefs - "why?"

We also need awareness and remain critical of ourselves, asking ourselves "have we observed deeply enough? what have we not observed? what have we not listed to?"

In testing terms we might consider - did we watch what happened in the database or just view the GUI, could we monitor memory usage? What else could we observe?

Conclusions

A rich mine of questioning techniques and attitudes exist in the Brief and Solutions or Change focused therapy worlds. This short blog post hardly scratches the surface of the area.

I have written about this topic before in the context of NLP. I still actively explore and study this area so you can expect future posts related to this.

If I have hinted at anything here which you would like to know more about then let me know -either via comments or email and I'll create some future blog posts targeted at the aims you set met. Otherwise the information will spool out at the speed and pace which I approach it, and may remain as vague as I require to remind myself.

1 comment:

  1. How did you first stumble on the connection between therapeutic models and best software testing practices? Are you trying to make software geeks acknowledge their human side and improve their communications skills in the process?
    My attention was immediately hooked when NLP was mentioned. I actually read your paper, "NLP for Testers", with enthusiasm. I had forgotten "how" I became a good communicator and realized how much I ignore when I don't feel like engaging with others. You even mentioned how emotions affect communication without getting bogged down with it. Presuppositions and assumptions are a personal favorite because they're my frequent downfall in social situations.
    I found your blog from a Software Quality News link for today. Thanks for sharing something I could actually relate to.

    Hi Suzanne, thanks for taking the time to comment and to read the paper.

    I developed an interest in NLP and Therapy before I moved into Software Testing. I continued to study therapeutic models, as I started studying testing models more deeply. When studying both topics at the same time, I guess they just converged.

    I would like 'software geeks' to consider software development as a communication process and adopt any tools which aid that process. I use tools and models from NLP, Cybernetics, General Semantics, Visual Thinking, to name a few of my sources. Other testers I know adopt tools from Logic, Philosophy, Physics, Experimentation. I enjoy working in a field where I can apply lessons from so many disparate sources.

    ReplyDelete