A presentation of my interpretation of context driven testing, particularly to non-testers and what they can expect from their testers when the testers become context driven.
Presentation to be delivered at the North London BCS 16th March 2005
There are 3 pdfs:
- Draft paper .pdf.
- Slide Handouts .pdf these are the presentation slide handouts
- Long presentation slides .pdf Slides for the long presentation version (not delivered)
Some basic ’things’ which have come out of preparing this paper, for me, are summarised below and are hopefully clearer in the pdfs.
I’m focussing on the ’no best practices’ notion. Partly because I was asked to talk about best practices, and partly because that seems to arouse most discussion in conversations I’ve had about context driven testing.
At times it was hard for me to distinguish between thinking in terms of a ‘context’ and thinking in terms of the ‘situation that we work in’ as a system with sub systems. Thinking in terms of a context focussed my mind on how to analyse the context, and thinking in terms of a system allowed me to think around the impact of what we do and the relationships between the items in the context.
When we work with the context, we only ever work with our perception of that context. Never an ‘absolute’ context. As such the context is going to change as our perception changes - when we learn more, when we do more, when we relate more to the people involved. The context will change for other reasons, but at the very least we can expect change, just from our learning.
I’m making statements that practices are generally not well defined enough to communicate to each other without ambiguity (we often just use the names of practises “unit testing”, “end to end testing” and assume the other person knows what we are talking about). This alone makes the use of ‘just a name’ inappropriate for consideration of the practise as a ‘best practice’.
Sometimes ’testing’ make life hard for themselves by imposing a process on a development approach that simply isn’t up to it (i.e. a ‘structured’ approach in a non-structured development situation) and ’testing’ then has to do a lot of rework and maintenance. I make that statement to, hopefully, open up testers to the notion of context driven, if they were not before.
I’m trying to explain that there is a difference between context-aware or context-based, and context-driven. I think that context driven involves coming in with no baggage of approach (but lots of tools and skills), and basing whatever we do on the context as we identify it. Context aware is about knowing something is not right but not really doing anything about it. And context based is about selling in something in a tweaked form.
I make the point that, whatever we do, will affect the context, as we are part of the context. This also relates to the notion of the context as a system. This also makes the context harder to identify as we are an observer-participant and our prejudices will filter our ability to analyse the context.
I’m trying to explore what other people will see context-driven-testers doing differently from non-context-driven-testers. And I can only really do that by looking at how I behave when I am at my most context driven:
- asking questions that explore the context, to derive information about the aims and objectives, not just what documents will be produced and when they will be produced.
- changing my mind and doing something different when I perceive the context differently
- justifying what I’m doing in terms of the context and not in terms of ‘calls to authority’ - although I might do that too (I’m flexible)
How other members of the development process can help context-driven testers, and to help make the process more context-driven. By stating ’needs’, not ‘wants’. By being more context driven themselves (even being context-aware would help).
I’m recommending General Semantics and NLP as study areas - since that is what I am most familiar with and use most (I think) for exploring context. I mention other studies that I have seen mentioned here.
Books that have proven useful for this talk were:
- “Scoring a Whole in One” by Dr Edward Martin Baker amazon.co.uk amazon.com
- “Adaptive Software Development” by James Highsmith amazon.co.uk amazon.com
- “Lessons Learned in Software Testing” by Brett Pettichord, Cem Kaner, James Bach read our review here
Useful web links are:
- context-driven-testing.com
- Cem Kaner pdf The Ongoing Revolution
- Brian Marick - Classic Testing Mistakes
- James Bach
- Bret Pettichord - Four Schools of Software Testing (pdf)
