Closing the Gaps

[Previously on the Ministry of Testing, Nov 2014 – now only on the Web Archives]: 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.

The understanding of closure

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”.

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.

References

  1. Graph theory http://en.wikipedia.org/wiki/Graph_theory
  2. Fell in the trap of total coverage https://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. A Track down History
  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)

Bug Return Policy

We find bugs, irregularities, this that should be there, and things that shouldn’t. From that we create a bug report, and from that someone looks into it, and then it’s a wrap. Unless the information is not returned, an no-one is the wiser. A bug report to me is a representation of an observation of the system, usually something that’s wrong. Some tools and vocabularies calls this “defects”, “bugs”, “tickets”, “incidents”. A bug report can be an email, post-it, or even a mentioning in passing [2].

Here are some recent sample headlines:
– The design is unclear, please elaborate
– With this role, I can access this, which I shouldn’t
– When I compare the requirements to the delivery list, I find these ..
– There is no data here, but there should be
– We thought we wanted this, but now we want something else
[3]

Notice that a bug report usually originates with a person, making an evaluation. This person is the tester, no matter the functional hat (SME, SDET, PO, VP). This may be tool supported, coming from a log of automated checks, or from BDD or Jenkins or what not. No matter the amount of tools, a person is making an informed decision, and raising the bug.[4] Come to think of it, she could choose to do nothing. But something is bugging her [5].

Here are some recent replies to my bug reports:
– it is by design
– it works on the development environment
– that’s how the COTS (or framework or platform) handles it
– ok, got it. seems like an easy fix
– awrh, now we have to rethink the whole thing
– Defferred, FixedUpStream, Rejected,
– Hmm, I see what you mean. Let me look into it

These replies come from some other person than the tester – let’s call him the fixer. First of all the fixer evaluates the report – he makes a decision, based on his context and his available information. Sometimes it’s an easy fix, sometimes it cannot be reasonably fixed. Sometimes the fix have diminishing returns. And everything in between.

What is very important to me, is that the fixer communicates his immediate evaluation to the tester. As quickly and transparent as possible. The fixer, to me, does not have the option to close it [1] alone. Nor can he fix the bug without letting the tester know. In the end the tester calls whether it is resolved or acceptable given the updated information. If the tester and fixer cannot agree, then call for outside help. And only then, let the two people work it out first.

The bug report and “fixer reply” has to be returned to the tester. Either the fix has to be tested, or the no-fix has to be tested too. It’s all part of the game – and it’s all integral to improve the quality in the short run – by fixing this specific project. It is an integral part in improving the quality in the long run, by adding knowledge and collaboration to the solution of the bugs found. Every bug, every clarification, every wish from the test to investigate something about the product counts towards collaborating about the quality of the solution.

TL;DR: Always direct the reply to a bug back to the person who found it.

1: Closure http://www.ministryoftesting.com/2014/11/closure/
2: Mentioning in passing, aka “mipping” http://www.satisfice.com/blog/archives/97
3: 3 types of bugs http://cartoontester.blogspot.dk/2010/06/3-types-of-bugs.html
4: How to raise a bug http://cartoontester.blogspot.dk/2012/10/3-steps.html
5: Something that bugs someone whose opinion matters. http://www.satisfice.com/glossary.shtml#Bug

minecraft_creeper_wallpaper_by_lynchmob10-1440x900

Publications and Presentations

Presentations, Webinars & Podcasts

Articles for The Ministry of Testing, 2011+

  1. Robot Process Automation As A Power Tool For Testing [Ministry of Testing Dojo, Mar 2018]: While there are other power tools for web and API testing, the RPA tools are a class of their own, as RPA tools allow for codeless automation macros on the desktop. RPA tools can do some very handy things. They can be used for both test data and regression testing. In this article, we’ll walk through a real testing example and show how you can get started using RPA. [TOP 6 on the Ministry of testing 2018 article list]
  2. Testing is Shifting [Testing Planet 2017 by the Ministry of Testing, Mar 2017]: Change is the only constant, they say, but we still need to manage change – and cope with it. Coping not only means surviving mentally, but also adjusting to whatever happens and figuring out how to be productive and create value for our stakeholders when things change. [https://dojo.ministryoftesting.com/lessons/testing-is-shifting]
  3. About Closure [The Testing Planet by Ministry of Testing, Nov 2014] 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. Let’s look at ways to represent states and articulate the meaning of states. [Reposted: Closing the Gaps]
  4. The Daily Defect Count and the Image of a Camel [The Testing Planet by The Ministry of Testing, April 2014] Count the defects daily – the ones that are part of the project work load. The number goes up and down during the cycle – why and what can you learn? [Reposted: A Track down History ]
  5. The Day Testing Died But Didn’t [The Testing Planet by Ministry of Testing, Jan 2014] To play according to textbooks is fine, up to a certain level. Perhaps up to master level, but not to grand masters. [Reposted: Chess and Testing ]
  6. One Test Case is All You Need [The Testing Planet by The Ministry of Testing, November 2013] If you can come up with just one business transaction – that crystallizes why the customer will be kicking and screaming to want to use your application, then you have a very good understanding of your customer and all you need is that one testcase. [On WebArchive.org]
  7. Recognize and Acknowledge Your Skills [The Testing Planet by the Ministry of Testing, June 2013] What you know and what you do is an important part of being you. Often it is required to rethink: What do I know? What are my skills? How strong are they? [https://jlottosen.wordpress.com/2013/06/18/tying-it-all-together/]
  8. The Build-A-Tester Workshop [The Testing Planet by The Ministry of Testing, June 2013] A small social game of Build-A-Tester can be used in a team to open the discussion, less formally than with Belbin and MBTI checklists. [on WebArchive.org]
  9. A Little Track History that goes a Long Way [The Testing Planet by Ministry of Testing, July 2011] The purpose of this tracking tool is to collect just enough data to answer the frequent question “Will we finish on time” [Reposted; A Track down History ]

Other publications

  • Could Modern Testing Work in The Enterprise [Guest blog for Panaya, May 2018] So far I have mostly thought that “Modern Testing” of the A/B testing podcast would never work in an enterprise context. But it seems some tools and existing approaches in the enterprises already fits well with the ideas of the concept. http://www.panaya.com/blog/testing/could-modern-testing-work-in-the-enterprise/
  • DevOps is cool, but get involved in OpsDev for Test Environment Management too! [Guest blog post for Plutora, Oct 2017] The hyped mnemonic “DevOps” is equally true the other way around: OpsDev http://www.plutora.com/blog/opsdev-test-environments-management
  • Testing during Transition: Test Criteria for Outsourced Software [Sticky Minds by TechWell, May 2017] In the world of IT outsourcing, it is not uncommon for a company to have its applications and infrastructure developed or maintained by others. How would you design acceptance criteria of a transition trial so that it is testable and clearly communicated? https://www.stickyminds.com/article/testing-during-transition-test-criteria-outsourced-software
  • Using Business Decisions to Drive Your Testing Coverage [Sticky Minds by TechWell, November 2014] In a business setting, software testers have a great challenge: to articulate how they support the business lines. One way to approach this is by addressing the business decisions—and there are plenty around. Use them to drive your testing activities and increase the business decisions being covered by testing. http://www.stickyminds.com/article/using-business-decisions-drive-your-testing-coverage 
  • The answer is: Why – because the answer depends on context.[The Testing Circus,vol.6 2.ed February 2015]: When asked about testing approaches, the options are so plentiful, that the reply is often “It depends” – and followed by a range of elaborations. But in our eager to reply, we forget to listen. http://www.testingcircus.com/february-2015/
  • The Testcases Template Trick – Getting One Testcase To Call Another [EuroStar TestHuddle, Nov 2014]: When doing test analysis I often find that we need to do test some customer feature over and over again for a range of combinations. I recently found myself able to redo a trick I learned a long time ago https://huddle.eurostarsoftwaretesting.com/the-testcases-template-trick/