Wednesday, 24 May 2017

Quaere, Heuristics, Mnemonics, and Acronyms

Don’t limit yourself to a set of attributes and words, seek more, develop strategies for identifying new concepts and ways of exploring them for then you have manifested the spirit of Quaere.

How might I describe the process of model building?

I was writing some notes on ‘Testing’ and trying to think through how I might describe the process of model building.

And I wrote down a few words:

  • Questioning,
  • Exploration,
  • Experimentation,
  • Analysis.
Useful words methinks.

Marketers ruin everything

And then my marketing brain kicked in.

“What if you made an acronym?”

Q.U.A.E.R.E - An Acronym I could Market

OK, well, “Q” requires a “U”

  • Usage?
And what else?

  • R? for Reasoning
And feed all of that into an online anagram solver:


“Quaere” a word “to seek”

The word “Quaere” coincidentally maps on very well to the process.

Since the word originates from Latin, to “seek, look for; ask”.

“Quaere” definitions:

Mnemonics and Heuristics

Clearly at this point I should own this and present it as a branded Mnemonic.

“Quaere”, which would lead you to the individual words: Questioning, Usage, Analysis, Exploration, Reasoning, Experimentation.

And how would you use those words?

I see many presentations of lists of words as Heuristics, but I don’t think of individual words as heuristics.

I think of individual words as words.

But I could have a parameterized statement that works as a Heuristic that says “Meditate on an individual word to think of ideas to improve your testing”.

And the parameter is defined as “an individual word”

  • “Meditate on [an individual word] to think of ideas to improve your testing”.

  • “Meditate on Questioning to think of ideas to improve your testing”.
  • “Meditate on Usage to think of ideas to improve your testing”.
  • “Meditate on Analysis to think of ideas to improve your testing”.
  • “Meditate on Exploration to think of ideas to improve your testing”.
  • “Meditate on Reasoning to think of ideas to improve your testing”.
  • “Meditate on Experimentation to think of ideas to improve your testing”.
I might think - what other parameterized heuristicesque sentences could I use?

  • “Have I performed enough [an individual word]?”
  • “Has my [an individual word] been good enough?”
  • “Did my [an individual word] cover everything it could?”

A Springboard for Ideas

As a springboard for ideas, word generation and cogitation can work well, I’m not knocking it, I just don’t think of a word as a Heuristic.

And I get nervous of lists in general because I have a tendency to view them as complete and never see the invisible “etc.” at the bottom which reminds me to expand them.

Don’t limit yourself to this set of attributes, seek more, for then you have manifested the spirit of Quaere.

Related Reading

Newer readers might like to read my earlier mentions of Stichomancy:

Friday, 19 May 2017

How to use JavaScript Bookmarklets to Amend Web Page Example [Tutorial Text and Video]

TLDR; When you learn to manipulate the DOM with JavaScript you can create simple tools and automate from within the browser and use bookmarklets to make the code easy to execute and sync across different machines.

Wednesday, 10 May 2017

Resolutions and Trends in Software Testing Xebia Meetup

TLDR; Map resolutions every day. Evaluate if you are living the purpose you set. Go deep with your current knowledge and it will allow you to adopt the trends when they become strong influences on your work.

I gave a short 20 minute talk (including Q&A) at Xebia in Hilversum in January 2017, the evening before TestBash Netherlands.

The aim was to discuss New Year’s Resolutions and Trends for Software Testing. I filmed the talk on my mobile phone (hence the strange angle).
  • How to keep resolutions
  • Figure out your ‘slogan’
  • Own your definitions
  • Build on what you know
  • Weak Signals and Strong Signals
  • Responsibility
  • Implement

Monday, 8 May 2017

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

TLDR; Map the TOTE (Test, Operate, Test, Exit) model on to TDD, Exploratory Testing, Design processes, Analysis, Learning, Decision Making and Problem Solving.


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 being 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 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

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. And 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 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)
  • etc.
And we Exit when our time has finished or we have covered our ideas or whatever other ‘exit’ criteria we started our testing with.


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 fail and write some code to make the test pass (Operate)
  • write more @Test code to flesh out the design (Test)
  • and 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
PS. If you want your own T.O.T.E model diagram then feed this into Graphviz or WebGraphviz

digraph G { 
  node [shape = "rectangle"];
  Test -> {Operate Exit}
  Operate -> Test

  subgraph { rank = same; Test; Exit}

  Exit [shape = "ellipse"];

Thursday, 27 April 2017

Notes on Structured Analysis and System Specification by Tom Demarco

TLDR; Time unfortunately has not been kind to this - it still has moments of well worth reading but it also has sections where you hope no-one follows the instructions lest they doom the project, but the chapter on estimation is well worth reading.

I haven’t read this book since University but I vaguely remembered it as one of the books that taught me system modelling, a skill that I still rely on to this day.

Wednesday, 26 April 2017

Do you know what your framework is doing? A quick use of WebPageTest.

TLDR; Frameworks implement an abstraction layer so we don’t have to bother about it. But, what if the implementation is doing stuff you don’t want? How do you know? Find tools that let you observe inside. does that for web pages.

Tuesday, 25 April 2017

Notes from Glenford Myers Advances in Computer Architecture

TLDR; Abstractions are not new, have never been easy, and have always been important when architecting our Systems.