10 Responses to “Transpection and the Three Elements of Checking”

1. Joe Harter says:

   September 4, 2009 at 8:16 pm

   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
2. James Marcus Bach says:

   September 4, 2009 at 9:55 pm

   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…)
3. Michael says:

   September 5, 2009 at 6:58 pm

   @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.
4. Thomas Ponnet says:

   September 16, 2009 at 12:39 pm

   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.
5. The Testing vs. Checking Paradox | thoughts from the test eye says:

   March 29, 2010 at 6:21 am

   [...] http://www.developsense.com/blog/2009/09/transpection-and-three-elements-of/ [...]
6. Automated Testing, so called - Automation Beyond says:

   April 14, 2010 at 1:45 pm

   [...] check, as James Bach and Michael Bolton defined, is characterized by 3 attributes. A check, then, has three attributes: 1) It requires an [...]
7. All Testing is Confirmatory – Part II | Testing Perspective – Rahul Verma's Website on Software Testing says:

   August 26, 2010 at 8:27 am

   [...] 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.” [...]
8. Good programmers check, Great ones test as well « Happytesting says:

   April 2, 2011 at 10:52 am

   [...] 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): [...]
9. What happened at DEWT1 doesn’t just stay at DEWT1 (May 11, 2011) « Test Side Story says:

   June 21, 2011 at 6:55 am

   [...] 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 [...]
10. Some initial thoughts on checks | thoughts from the test eye says:

    January 1, 2012 at 3:32 pm

    [...] 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 [...]