DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • When a Coding Agent Fixes the Test Instead of the Bug
  • Testing Java and Spring Applications With Kotlin: Low-Risk to Adoption
  • Your Visual Regression Suite Is Mostly Testing Anti-Aliasing
  • From Issue to Reviewable Patch: Build a Sandboxed Coding Agent With Deep Agents and Automated Tests

Trending

  • DZone's Article Submission Guidelines
  • How to Submit a Post to DZone
  • Designing Memory Architecture for Stateful AI Agents: Short-Term Context and Long-Term Persistence
  • Part 4: Multi-Agent Orchestration — Pairing Goose With Quarkus Flow State Machines

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Testing, Deployment, and Maintenance
  3. Testing, Tools, and Frameworks
  4. TOTE Model For Testers - Test, Operate, Test, Exit

TOTE Model For Testers - Test, Operate, Test, Exit

Learn to map the TOTE (Test, Operate, Test, Exit) model onto TDD, exploratory testing, design processes, analysis, learning, and more.

By 
Alan Richardson
·
May. 11, 17 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
5.8K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

tote

in 1960, george miller, presented a model of problem solving which he called the t.o.t.e model :

  • test, operate, test, exit.

the notion is that you loop around a [test, operate]* cycle and when your test is complete, then you have done enough operations and you can exit. it was a model of problem solving, or decision making. i wrote about it a while back on the blog and in my nlp papers

you can find george miller’s book plans and the structure of behavior on archive.org. he describes the tote model in that book.

tote in action

showing t.o.t.e in action. i drew this dynamically to make the point that it is a cyclical process and we test to decide if we continue to operate, to exit the process, and to change what we will operate.


you can see the 9 second version on instagram .

we test to build a model, and sometimes we exit because things are good enough, but we still need criteria to determine what good enough means. sometimes we operate to learn if something is good enough.

tote for learning

at the time that i explored the tote model previously, i didn’t make the connection that the arc from operate -> test was also a feedback process.

in the tote model, the test learns from operate, which we can easily map on to exploratory testing:

  • we come up with an idea to explore ( test ).
  • we explore ( operate ).
  • we learn from that ( operate -> test ).
  • we derive new things to explore ( test ).
  • et cetera.

we exit when our time has finished or when we have covered our ideas or whatever other ‘exit’ criteria we started our testing with.

tdd tote

i’ve also written a lot more code using tdd, and i know that my tdd process very often resembles a tote process:

  • write some @test code ( test ).
  • see if it fails and write some code to make the test pass ( operate ).
  • write more @test code to flesh out the design ( test ).
  • repeat.

until our design is complete, or our review of our @test and code can’t come up with anything new, and we have compared it with our statement of intent, etc.

tote learning

we could view this as a completely well-defined process of evaluation where at every ‘test’ point we know exactly what we are deciding upon and use the pre-defined evaluation criteria.

we could also view the operate process as a learning process which feeds into the test process and explains the cycle. each time we ‘do’ something (operate), we learn something which we feed into the test process.

i missed the learning process inherent in the operate -> test arc first time around.

i won’t do that again, and that makes tote an even better model for the type of work i do.

a model worth investigating.

see also

  • instagram.com/p/btnqhiqagr0
  • www.instagram.com/p/btpdkssaz0k
  • the 2002 blog post
  • nlp for testers
  • george miller’s book plans and the structure of behavior
Testing

Published at DZone with permission of Alan Richardson. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • When a Coding Agent Fixes the Test Instead of the Bug
  • Testing Java and Spring Applications With Kotlin: Low-Risk to Adoption
  • Your Visual Regression Suite Is Mostly Testing Anti-Aliasing
  • From Issue to Reviewable Patch: Build a Sandboxed Coding Agent With Deep Agents and Automated Tests

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook