You are on page 1of 2


E - Test, Operate, Test, Exit for Software Testing

In 1960, George Miller proposed a model of Goal driven behavior which he titled T.O.T.E (Test
operate test exit).

Fig 1: The TOTE Model as a Graph
My understanding of TOTE is very simple. For this model to be valid we have to accept that the
stimulus behind behavior is the achievement of a Goal. In order to achieve the Goal, that goal has to be
defined thoroughly enough to allow us to recognise when the goal has been achieved so that as we
move towards the achievement of that goal (operate) we can assess (test) if that goal has been achieved
and then Exit.
George Miller intended this to be a model of behavior, not a model of IT. Is it possible that I am trying
to forcefully overlay one model on top of another just because it has the word "test" in it, not once but
Possibly, I do that, I like to test and try things out and when they work I justify it with the term inter
disciplinary research, or some such nonsense. But this does seem to me to be a valid operation to try.
And if it fails my reading test then I will learn something about the difference between the two models.
I will learn something that makes one model unique and then I'll exit stage right just a little wiser
pursuing some other idea.
Software Development can be viewed as a single TOTE. In that we first of all decide that we want a
system to allow us to do things so we list those things so that we can assess how close we are to having
the system we want (test), we build the system (operate), and if the system allows us to do the things
we want (test) then we call it complete and release it (exit).
Software development has a life cycle with a slightly more detailed lifecycle than that and as we look
at it in more detail we see that the software development cycle is actually a sequence of interdependent
TOTE feedback chunks.

Fig 2: System Development TOTE Sequence
In fact every single aspect of software development, because humans do it and it becomes subject to
behavioral analysis can be viewed using the TOTE model. The process of constructing a test itself is
subject to TOTE, the process of writing every script step is subject to TOTE.
Facetiously, this model may help to explain why companies are so reticent about doing System testing:
We specify the system (test)
we build the system (operate)
we unit test the system (test)
why can't we then ship it? Surely adding independent system testing to the mix can be
perceived as OTT.
Well, no. System testing executes the system from a different level than that of unit testing Unit testing
often works from within and system testing from without. Unit testing can start before the system has
been put together, system testing cannot. Unit testing must know how the system has been constructed,
System testing doesn't. Both have different sets of goals and therefore a different set operations and
User acceptance testing waits for the development testing (unit and system testing) to be complete. The
goal being to fit the system into their business process.
An IT development model that has unit testing, followed by system testing, followed by user testing
isn't OTTT, from a distance it is simply OT. We, as IT personnel, have simply taken the T chunk and
split it into UT, ST, and UAT to make the most of the parallelism that is available with multiple levels
of validation conducted by different people.

Fig 3: The Parallelism of the development cycle
TOTE is just a model. But Quality Software Development is a goal that most development teams set
out to achieve, they cannot do that without knowing what they mean by quality and without checking
to ensure that they have achieved it.