Some weeks ago I saw John Hockenberry‘s talk “We are all designers”. It really struck a chord in me. The whole concept of intent and what part it plays in our lives. I’ll quote some parts of what he said:

Design — bad design, there’s just no excuse for it. It’s letting stuff happen without thinking about it. Every object should be about something, John. It should imagine a user. It should cast that user in a story starring the user and the object.

Good design … is about supplying intent.

…

It’s as though intent is an essential component for humanity. It’s what we’re supposed to do somehow.We’re supposed to act with intent. We’re supposed to do things by design. Intent is a marker for civilization.

…

An object devoid of intent –it’s random, it’s imitative, it repels us. It’s like a piece of junk mail to be thrown away. This is what we must demand of our lives, of our objects, of our things, of our circumstances: living with intent.

For weeks now there is a blog post of mine unpublished. It is all around the small things that count in testing. But I wasn’t really happy with it. Something was missing or I wasn’t getting the point I was trying to make. Today it dawned on me what was missing. It was the INTENT John talks about above.

What he said about bad design and about things devoid of intent reminded me of what we commonly experience in the software development industry. The exact thing that I was getting at with my unpublished blog post. Especially in the (perceived) non-critical areas the lack of clear intent is the most obvious.

So, what does software do? Or better, what do we do when we create software?

Aaron Hodder describes it as “… software development: “A group of people who come together and help solve a problem for another group of people via the medium of computer software.” 

So software development is the act of taking a problem, a dream or an idea and filling it with intent. John’s father described it as “supplying intent“.

Have you encountered intent in your work-life before? Have you seen a document that says something like “Documentation of Intent for project XYZ”? Well, I certainly haven’t. A business case actually doesn’t do it justice. I see it closer to Simon Sinek’s Start with WHY.

For example, when Steve Jobs had his vision for the iPhone / iPad / Next / Macintosh / Apple I/II /…. I can’t really see him having sat down and written a requirements documentation à la “A phone should have a numeric keypad to dial a telephone number that…”. I think he had a clear vision and communicated only his intent. All else followed suit by inference.

So is intent completely lost in the SDLC?

I don’t think so, as it is the basis upon which we work but I do think we’ve lost the ability to recognise it and act upon it. We have forgotten that it is the origin.

As testers we usually come to the SDLC quite late in the game. We get the intent –or what’s left of it– in a form of a hand-me-down documentation called requirements, specifications or user stories. We soon discover they are full of holes, are poorly defined, too high level or not congruent. This then leads to the cycle of defects and change.

Most testers retrospectively try to re-engineer intent without knowing, that it is actually what they are doing. We collect oracles and the information they give us to construct a vision of the project. To find all the information we need to build a cohesive picture but done correctly we end up with the intent.

The context driven testing world (CDT) is on the right track tying everything back to the context. But what is that? How do I find THE context? I think context is clearly defined by intent. So we need to find the intent first and foremost.

Like the big-bang there is probably a single event, where intent was defined. From it all else emerged. So in a sense if we have the root intent we could deduce from that all reasoning and decision making. We can also see where the project runs awry or where we have gaps. Reading John’s lines above intent is fundamental we cannot ignore it or fail to mention it.

Intent Driven Testing (IDT) is what I call the process or journey back to the beginning. It extends the scope of our testing. It strives to see the project/system/software holistically. It is the source we need to be able to compellingly state our case for whatever we find in testing.

So the question is, how do we do IDT?

A lot of us are already on the right track. As mentioned before, Simon Sinek describes it as the Why. Keith Klain (TM, Barclays Global Test Center) in his talk  goes on to say that they focus on asking Why. Why – would often be the most direct route to elicit intent.

What I see is roots extending from that origin of intent right  throughout the project. Intent Driven Testing is more like the theoretical foundation around Context Driven testing. It completes the picture. IDT would be best visualised in tracing your steps, methods and thoughts back to the original intent. Your basis of risk becomes easily justifiable and in any contact with the business you can trace back to what is important (or not).

So far this idea is new to me and I haven’t actually put into a process/methodology around a project but will do so the first chance I get. That shouldn’t keep anyone else finding new ways to capture the idea of IDT in what they think is appropriate. If you do so or have any other comments that extend/detail this concept please add in the comments (or link to whatever you did). I’d be very keen to take this further.

Author: Oliver Erlewein