James Bach and I have a thing that we do called “transpection“. It’s not at all new (you do it, Socrates and his interlocutors did it in Plato’s dialogs, and people did it long before that and have done it ever since) but I think James’ word for it is new. Transpection is an exploratory conversation aimed (or chartered) towards discussing and refining a particular idea. Transpection is a way to improve your own thinking by witnessing the thinking of someone else while not revealing your own thinking to them until the end of the session. The word is related to inspection (in which one examines and observes something) introspection (in which one examines and observes one’s mental or emotional processes) and retrospection (in which one examines the past). Transpection involves examining or observing an idea with another person. As James says, “Transpection basically means to learn by putting yourself in someone else’s place. The transpective dialogs I do are about using someone else’s knowledge, biases, and methods as a counterpoint to my own as I try to solve a problem for myself. As I do this, I generally don’t share my own thoughts, for fear of biasing my partner toward my own way of thinking. The essence of transpection is to get the maximum value out of seeing the world as the other person sees it.”
James and I often disagree on certain ideas, but through transpection we come to sort them out and sharpen them. At first, it seemed that we disagreed on testing and checking, but through a transpection session yesterday, we came to agreement and James provided me with a set of attributes whereby we can test whether something is a test or a check.
A check, then, has three attributes:
1) It requires an observation.
2) The observation is linked to a decision rule.
3) The observation and the rule can be applied without sapience.
See more on testing vs. checking.
Related: James Bach on Sapience and Blowing People’s Minds
I think I read about transpection on James' blog sometime in the past. I've found it to be a very beneficial activity.
I wanted to chime in to see if you consider this to be a "check" or not. The last rule throws up a red flag for me, because it seems that sapience is required for some checks, but I'm sure you and James already worked that out.
Scenario: I'm reviewing test cases designed by testers. I observe that they are not specifically going to stress the system. I have a decision rule in place "If testing occurs on a piece of software then check for stress testing opportunities." It doesn't seem to me that a non-sapient entity could even make the observation, because it requires the parsing of english sentences or models or napkins. The tester could choose to communicate this information in so many different ways, so I think a human should do this checking (checking for some basic levels of coverage) using tools like SFDPOT while also doing a qualitative analysis of the test coverage.
Are the things that I sometimes "check" for not really checks in your opinion or do you think that it is possible to make those observations without sapience?
-Joe Harter
I wouldn't say "based on" a decision rule, but rather "linked to" as in "If I see X, do Y."
Asserts in jUnit are a perfect example of an observation (result of function call) connected to a decision rule (if fail then…)
@joe: Yes. The design of a check is a testing activity; it requires sapience. The performance or execution of a check doesn't require sapience (by definition; if it did, it would be testing). Evaluating the result of a check is non-sapient, but ascribing meaning or significance to it, interpreting the result is again sapient, so an activity of testing. The distinction is based on this: could a machine make the decision after I had programmed it to do so? If Yes, it's a check; if No, it's a test. Another aspect: does it involve a value judgement, or is it a one-bit decision?
A check results in "pass" or "fail"; that can be a non-sapient decision. It requires a human to decide "Is this a big deal?" "Is the check, rather than the product, broken?" "Should we change the product or drop this check?" "Even though this check reports 'fail', can we still ship?" "Should we be doing any more checks or tests, or do we already know enough?"
One more thing, though. I don't want to enforce orthodoxy on speech; that way lies the ISTQB and the SWEBOK and all that. In casual conversation, it makes little difference what word you use. It's when you want to think critically about what you're up to that the distinction (and not the label) matters. "I want to check to make sure that these are good tests," is a fine thing to say, even if what you're doing is really very testerly, and far more than checkish.
@james: Yes, "linked to" is better. I've changed it above. The links are powerful enough that I'd contend that the observation is motivated by, even dominated by the decision rule. And that jUnit example is paradigmatic.
—Michael B.
This sounds a lot like Satsang to me – I'm surprised that no indian tester has pointed this out.
Wiki has an interesting definition of what Satsang is which seems to describe in slightly different words what you are doing. Replace "indian philosophy" with "software testing" and "guru" with "expert" and you're there.
Interesting discussion, just wanted to highlight this as it was an eyeopened when I spoke to my wife (a yoga teacher) about Satsang today.
[…] http://www.developsense.com/blog/2009/09/transpection-and-three-elements-of/ […]
[…] check, as James Bach and Michael Bolton defined, is characterized by 3 attributes. A check, then, has three attributes: 1) It requires an […]
[…] The problem with your approach to “Is there a Problem here?” is that you are discussing it only partially. At first look, I confess, it looks pretty convincing. But the moment one starts thinking that one would have to answer this question, the difference fades away. Michael: “I think Rahul’s notion that a test must pass or fail is confused with the idea that a test should involve the application of a stopping heuristic. For a check, “pass or fail” is essential, since a check relies on the non-sapient application of a decision rule.” […]
[…] Often when programmers are asked if they test, they hopefully say they do. But when asked about the type of testing carried out, it is mostly about writing and running automated unit or integration tests as they call it. Considering the discussions in the linked blog posts, these would really be checks. This is how Michael defines a check in the comments of Aarons post (original post): […]
[…] of interesting stuff on it (see James Bach’s post here, some Michael Bolton posts here and here, and Stephen J. Hill’s post here), so we asked Michael Bolton if he would be willing to give […]
[…] testing and checking [1]. He has since then elaborated more in the area and digged deeper into it [2], and continue to do so [3]. By clarifying what we are doing at a certain time it makes it easier […]
[…] Transpection (a form of testing) reveals an error in a designer’s idea. The conversation helps the designer to change his idea to prevent the error from turning into a design flaw. […]