You are watching me and a machine interacting with the same system. Our actions are, to the extent that you can tell from your vantage point, identical and the system is in the same state at each point in the sequence of actions for both of us. You have been reassured that the systems are identical in all respects that are relevant to this exercise; you believe that all concerned in setting it up are acting honestly with no intention to mislead, deceive, distort or otherwise make a point. The machine and me performed the same actions on the same system with the same visible outcomes.

Are we doing the same task?

This is a testing blog. You are a tester. You have been around the block. More than once. You perhaps think that I haven’t given you enough information to answer this question with any certainty. What task is being performed? Are the visible outcomes the only outcomes? To what extent does skill and adaptability form part of the task? To what extent does interpretation on the part of the actor need to happen for the task to be completed successfully? What does success mean in this task anyway? Was the task completed successfully in the examples you watched? What does it mean to be the “same task” here? And from whose perspective?

This is a testing blog. I am a tester. I’ve also been round the block. More than once. More than twice. I’ve recently finished reading Harry Collins’ The Shape of Actions and, while I’ll say up front that I found it reasonably hard-going, it was also highly thought-provoking. This post pulls out just one fragment of the argument made in that book, but one that I find particularly interesting:

Automation of some task becomes tractable at the point where we become indifferent to the details of it.

There’s probably some task that you perform regularly that was once tricky. Maybe it’s one of those test setup tasks that involve getting the right components into the right configurations in relation to one another. One of the ones that means finding the right sequence of commands, in the right order, with the right timing, given the other things that are also in the environment.

As you re-ran this task, you began to learn what was significant to the task, which starting conditions influenced which steps, what could be done in parallel and what needed a particular sequence. You used to need to pay attention, exercise skill and judgment, take an active role. These days you just punch keys as efficiently as possible until its done. You don’t look at the options on dialog boxes, you don’t inspect the warnings that flash up on the console, you don’t even stop checking Twitter on your other monitor. Muscle memory drives the process. Any tacit knowledge you were employing to coax your setup into being has been codified into explicit knowledge. You just need it to be done, and as quickly as possible.

You have effectively automated your task.

As a manager, I recognise an additional layer to this. Sometimes managers don’t care (or, perhaps, don’t care to think about) how a task is implemented and may thus mistake it for a task which can be automated. But the management perspective can be deceptive. Just because one actor in some task doesn’t have to exercise skill, it doesn’t mean that no skill is required for any aspect of the task by any actor.

Which reminds me of another Collins book, and a quote that I love from it: distance lends enchantment.