About Closure

When I’m in a testing activity I want my test cases [Passed], my user stories [done] and my coffee [black].  Stuff may have a start point, some states in between and an end state. Lets look at ways to represent states and articulate the meaning of states.
One way to illustrate status about the product being tested is to model the activities we have with states. An agile user story may be [ready], [in progress] or [done]. A document may be [final], [approved] and a mind map may be iconified etc. States are so common that we sometimes forget the theory behind the model, and what benefits we have from the theories.


The representation of closure

For instance we can look to computer science graph theory[1]  to help us understand and control the states diagrams. It is the same graph theory that brings us state machines and state-transition diagrams, but that is another story[2] . In a graph theory state model we want one unique start state (Like [To do]), and one unique end state (like [passed]), everything in between is intermediate.


A (single) end state helps prevent the state machine from going on forever[3] , and us from going on forever too. [Deferred] and [Rejected] are temporary states to me. Setting [Rejected] back to “detected by” will aid that the tester reflects on the reasons. The reasons are then tested (in the brain). Sometimes it’s a “my bad” but quite often also the tester finds that issue is simply not “rejected” with more data and examples.


I walked my first testing shoes in large v-model enterprise test projects – with test cases, test steps and many defects to follow[4] . Our best practice was partly illustrated in a swim lane and “pixie book” with guiding principles regarding closing things that I still rely on. All roles get a few states to monitor, and a few states to “set to”:

  • The tester that found the defect had the right to set it from [ready to test] to [closed]
  • The tester that found the defect had the right to set it from [rejected] to [closed]
  • Developers monitor [Open] and sets [rejected] or [ready for test]


Mandatory values:

  • New – Newly discovered defect
  • Open – A defect assigned to a Sub-Contractor.
  • Rejected – Defect not accepted.
  • Ready For Test – Fix has been deployed, retest can start
  • Re-Opened – The fix has not removed the defect
  • Pending – Defect is postponed or awaits further investigation
  • Closed – The fix has removed the defect

Optional values:

  • Fixing in Progress – Developer has taking action to fix it
  • Fixed – Developer has fixed it, at tested it locally
  • To Be Fixed – Defect accepted, Est. ready for test provided
  • To Be Deployed – Awaits deployment/installation
  • INSERVICECENTER – End2end-defect has been registered in Service Center
  • CLOSED.POSTPONED – The fix has been postponed for a future release.

The understanding of closure

What we did then was both to have a swim lane illustration and a guideline. And the guideline was the imperative one. It listed some states as the main flow, others as optional elaborations – i.e. [To Be Deployed] and [Fixed]. As the flow had to be used in many situations you could change from one state to any other, because the guidelines elaborated towards a shared understanding.
Similarly the agile “Definition of Done”[5]  and “Definition of Ready”[6]  helps the agile team phrase when the task is to change state, sometimes it’s explicit, sometimes it’s implied. The understanding of terms (the semantics) are usually more imperative than the syntax (the rules and representation). Sometimes it’s necessary to “connect the lines”.

closure law

There are a two related psychology theories on closure. One is the Gestalt law of closure[7]  – that is that we tend to self-organize items into an orderly structure. As the image above isn’t really about triangles – it’s about our human tendency to connect the dots. The other psychology part is the desire to close stuff to gain controllability[8]:

The need for closure is the motivation to find an answer to an ambiguous situation. This motivation is enhanced by the perceived benefits of obtaining closure, such as the increased ability to predict the world and a stronger basis for action.

Management and stakeholders often want a “firm and unambiguous” answer from our testing investigations. And this is often the business justification for setting states to our work products; that we have states to illustrate work progress in. Sometimes loose representations and a strong shared understanding goes well, sometimes a more strict representation and elaboration is required.

The syntax of states may be easily explained and codified (and checked), while the semantics and perception is less direct – and needs analysis (and testing). All work products (even for mind maps and test charters) have states and we must articulate both the syntax and the semantics to the team and stakeholders.


  1. Graph theory http://en.wikipedia.org/wiki/Graph_theory
  2. Fell in the trap of total coverage http://jlottosen.wordpress.com/2012/11/05/fell-in-the-trap-of-total-coverage/
  3. Finite state machines http://en.wikipedia.org/wiki/Finite-state_machine
  4. The Daily Defect Count and the Image of a Camel http://www.ministryoftesting.com/2014/04/daily-defect-count-image-camel/
  5. definition of done https://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done
  6. definition of ready http://guide.agilealliance.org/guide/definition-of-ready.html
  7. Law of closure http://jeremybolton.com/2009/09/gestalt-design-principles-the-law-of-closure/
  8. Closure (Psychology) http://en.wikipedia.org/wiki/Closure_(psychology)

About the author

Jesper Lindholt Ottosen is a Test Manager at NNIT in Denmark. He is a promoter of context-driven testing and member of the ISST. You can follow him on twitter at @jlottosen and on his blog: Complexity is a Matter of Perspective.

You might be interested in... The Dojo

Dojo Adverts-05



  1. About closure | I'm a tester - November 10, 2014

    […] Lindholt Ottosen has written an article about closure. He […]