Wherein the TOTE (Test Operate Test Exit) model is used to explore the nature of feedback and abstraction of test phases
In 1960, George Miller proposed a model of Goal driven behavior which he titled T.O.T.E (Test operate test exit). This essay, maps the T.O.T.E model to Software Testing.
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 twice?
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 tests.
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.
Some Variants of TOTE used in IT
BAD (malformed paths)
- OE (oh) - no testing involved, code it then ship it
- OTEA (oh dear), operate, test, then exit anyway
GOOD (well formed paths)
- TE -( tche!) - no funding project canned and deemed unfeasible
- (TOT)*E extreme programming, write the test, write the system, run the test