I’ve spent the last 8 months or so leading a QA transformation supporting a DevOps initiative, It’s been a great experience and I’ve learnt loads and I wanted to write it all down, before I forget the journey that I have been on.

So the intention is to do a series of blogs to get this all down.

This work was fundamentally about changing the way that testing was perceived, which was that it was a manual activity and took place long after development has completed and helping people come to the realisation that testing should be carried as early as possible and automated.

Now I am not going to trying to explain how we automate testing, because what I want to do is describing the actual journey we went on not the the detail and to be honest all I did really was to go with Lisa Crispin’s books¹ and especially the Automated Testing Pyramid and Testing Quadrants, which formed the basis of our test strategy.

Now, I must admit I had some preconceived ideas about the way automation should work, because I’ve been here before and I’ve seen it done very well and so obviously I knew how it all should work, obviously!

Fortunately I’m also a massive fan of Cynefin, which provides me with the ability to question what I am doing and not fall into making false assumptions and bad decisions, well not that often anyway.

If I ever needed a solid lesson to reinforce the need for having a good understanding of the current context and backstory before doing anything then this has served and I’d say that this is probably the single biggest take-away I have.

So these are my thoughts on context

To Begin at the Beginning.

Sadly you can’t predict the future, despite what you may be told there is no secret sauce, no magic recipe that you can simply employ to make things work, no magic pixie dust, no tooth fairy, no guarantees.

We live and work in a complex environment, one that is ever changing, where there is no direct link between cause and effect, except in retrospect, hindsight is indeed a wonderful thing.

So whilst complex systems are not causal, they are however dispositional, we can say that they are predisposed or likely to work in a particular way and this provides us with the ability to make a high level guess or prediction of where we believe we are likely to go, our probable direction of travel.

We just need to be mindful that there are no guarantees, that’s all and handle this risk appropriately.

Due to the uncertain nature of change in the complex space we approach this journey by describing where you are right now, the “here and now” and where you would like to go ” the destination” and come up with a rough idea of how you will get from A to B, “the strategy” and then start your journey, get going.

Think of it this way, when you start a journey the starting position fundamentally effects the journey itself, the journey to London is dramatically different from New York than it is from say York, the commonality is where you want to end up, not necessarily how you get there, although it might be.

We may very well want to end up in the promised land of constantly executing automation tests, but the road to this Promised Land is very different depending where you started.

It’s important to understand that any journey is unique to its starting position, which you’ll hear me refer to frequently as context and as such the journeys are different and not wholly interchangeable.

So if you start in York then your strategy might be to go via the A1(M), but on your journey conditions change, as they have a habit of doing. So something that was considered easy or trivial becomes hard and unpleasant, think of running into an accident on the motorway and being diverted via the back of beyond, could you have predicted that, no not really?

However knowing that the journey is prone to changing circumstances you could have looked to handle the risk of this happening. We may choose to do this by checking our position in relation to our desired destination and course correct if things aren’t going how we expected.  On a car journet use a SatNav with real time traffic information to do this, in the IT world accomplish this by doing small things quickly and then checking if the outcome was what was expected and then doing something different if it wasn’t, in other words we experiment, inspect and adapt.

We also have to be aware that in the course of our journey the destination may change as we learn more and who’s to say that the final destination is not better than where we thought we may want to go in the first place, which is why  a journey in a complex system is dispositional, but without guarantees.

This all sounds like a lot of words, but simply speaking what we need to do is, build something then:

“Get it in, Get it working, Make it better”.

So once we understand our starting position (context) we next need to broadly understand our destination, we do this by describing a vision of where we believe that we would like to end up

¹ Agile Testing: A Practical Guide for Testers and Agile Teams