Communication Heuristic: Use Cases

In the last year I've been working with different aspects of software development - many aspects related to Continuous Integration and Testing, but also other areas. Part of this work has involved developing new ideas to test, reflect on and potentially spread. A common challenge I've had from a number of colleagues when I'm talking about an idea or concept is:

"Can you give me or describe it in a use case?"

People want to relate to the idea. Sometimes a user story is really meant, but that doesn't matter. The real power here is the invitation to a discussion and dialogue about the topic, concept, way of working, product, etc. It's a way of saying. "let me understand your idea in use".

The use case doesn't necessarily describe the entirety of the idea but it starts the discussion - at least from one angle.

It's not always easy to do either - because sometimes it generates discussions in unexpected areas. This might be because people interpret the need differently. Or they've framed the problem differently. But that is good, and indeed useful, to generate such a discussion. It helps weed out misunderstanding.

When people (and groups) have worked with (or thought about) the idea then they will naturally develop new ideas about it or generate new questions. Some of this is testing the idea or concept, sometimes it's information gathering and sometimes it's clarification. Usually the testing of the idea explores ways that it could be misunderstood or produce unwanted results.

This is a very useful tool not only for product development but communication in general. It is common to use this in product specification and requirement capture, but it's also very useful in concept/idea discussion.

It is a heuristic approach to communication.

Does this all seem abstract? I used this heuristic recently to discover that I didn't have a common understanding - at least via use case - for the usage of the word "checking".

Potentially Related Posts
The Conway Heuristic
Testing. What was the question?
Framing: Some Decision and Analysis Frames in Testing
Thoughts around the label "Checking"

Thoughts around the label "Checking"

Observant readers of twitter and my occasional (6) blogs related to checks, testing and checking will know that I have done some head-scratching over the term "checking".

Some of My Heuristic Triggers
Why, what has triggered this for me? I have a number of factors - mainly these heuristic sources:

Are You're Lights on? [1], Reason for testing (term usage) [8], Framing testing terms [9]
--> My questions: What problem are we trying to solve? And does this succeed?

Weinberg's Rule of Three [2] and the Conway Heuristic [5]
--> My questions: What alternative interpretation is there? How could this be interpreted, or what consequences might it create (unintended or not)? How could it be misinterpreted?

Communication, Exploring Requirements [3], Dialogue & tacit knowledge [4], Understanding Arguments [6] and Heuristic wear-n-tear / refinement [7]
--> My questions: Do the statements & arguments stand up? Does something get lost in interpretation?

Towards Clarity (for me)
These are usually with me in my toolkit as aids - some more than others. So, I read Michael Bolton's recent post [11] on checking and what isn't checking - this got me thinking on this topic again.

As I stated on his blog - after a challenge for clarity from Thomas Ponnet:

Checking "... is a label that should only be used (imo) for an observation of something that is happening or has happened. It’s a post event rationalisation (it’s “a posteriori” knowledge).  

If you state your intention to include checking in your activities you are really describing your testing – because the intent, analysis, selection and discussion of results is testing – even if checks were used. 

Then I would find it more accurate to talk about the testing that /will be/ aided by checks. Afterwards it might be accurate to describe the testing has included checking. Planning checking, intending checking is by implication testing – and I (personally) don’t see the added value and I question it’s accuracy. 

But, that doesn’t, of course, stop anyone using the term however they want and in ways they find useful."

I am making an assertion for how checking might be used in a less-ambiguous way.

Shallow-Agreement?
I was challenged that I might be in shallow-agreement with the RST meaning of checking. Of course, this is always possible - I went and re-read the testing-checking-refined [10] and Michael's post [11]. I didn't find any examples of the usage of "checking" (as of 23 April 2016) - i.e. examples of how it would be used in speech or written form.

Thus, there is a risk for shallow agreement with something that isn't demonstrated. Whether that is small or high, how would you know?

A couple of questions then occurred to me: 

• What's the guide for shallow agreement on the definition and use of "checking"? 

• What's the accepted form for agreement when the main post doesn't demonstrate it?

Does it matter?
What have I been doing? I've been testing the concept of "checking" - trying to understand ways it will work and risks associated with its usage. I've given examples (in the blog [11]) of potentially unintended consequences of its usage.

Would examples and the above guide for "checking" help? Maybe, maybe not. It might be that the problems I have highlighted "don't really matter" or isn't a "high priority issue". That's fine, I can live with that. It's possible I'm getting stuck in the semantics... Oh!

My context/background: 
I started writing, questioning and exploring these issues in September 2009. I was one of the vocal parts of the discussion that led to the re-drawing/refinement of the diagram in the testing-checking-refined post [10].

I've called out and questioned people - typically on twitter - that might be using "checks" and "checking" in unsafe ways. I don't typically use the word "checking" in my work - partly due to some worries I've seen in misunderstanding - and also that I can distinguish between testing and checks without "checking".

Not using "checking" myself doesn't mean I can't usefully "test" it, its usage and risks associated with its usage. Can you? And if so, what heuristic guides would you use?

References
[1] Are Your Lights on? (Gause, Weinberg)
[2] The Secrets of Consulting (Chapter 5; Weinberg)
[3] Exploring Requirements: Quality before Design (Gause, Weinberg)
[4] Dialogue, Skill & Tacit Knowledge (Göranzon, Hammaren, Ennals)
[5] Tester's Headache: The Conway Heuristic
[6] Understanding Arguments: An Introduction to Informal Logic (Sinnot-Armstrong, Fogelin)
[7] Tester's Headache: On Thinking about Heuristic Discovery
[8] Tester's Headache: Testing. What was the question?
[9] Framing: Some Decision and Analysis Frames in Testing
[10] James Bach: Testing And Checking Refined
[11] Michael Bolton: You Are Not Checking