You Cannot Be Everywhere

A key lesson with the whole situation is, that there is no Nirvana, no steady state nor closure to everything. The only constant is that life is ever changing. Coming up around the corner is a new change – some can be planned for and others not so much. Imagining that things can be different is the first step to dealing with change (Thank you, Virginia Satir).

There will always be more things needing attention. Sometimes it’s based on the fear of missing out (FOMO) and the urge to be involved in everything. You will very easily find yourself stretched too thin – and needing a way to scale the effort, both professionally and personally. Clocking more hours will only work in the short run. Remember, it’s ok not to scale – sometimes it’s actually the best solution.

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, they could choose to do nothing. But something is bugging them [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 them the fixer. First of all the fixer evaluates the report – they make a decision, based on their context and the 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 their 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 they 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