Testing vs. Checking ... my 2 cents.

I was pleased to see Michael Bolton's series on Testing vs. Checking. If you haven't been following, what I consider to be the central thread of the topic (and the unfortunately inevitable fallout that seems to happen in "testerland" almost any time someone says something that makes sense).
From Michael:

• http://www.developsense.com/2009/08/testing-vs-checking.html
• http://www.developsense.com/2009/09/transpection-and-three-elements-of.html
• http://www.developsense.com/2009/09/pass-vs-fail-vs-is-there-problem-here.html
• http://www.developsense.com/2009/09/elements-of-testing-and-checking.html

From James Bach:

• http://www.satisfice.com/blog/archives/358

From Scott Barber:

• http://www.perftestplus.com/resources/014PeakPerf.pdf Original, ST&P Magazine, 2005
• http://www.logigear.com/newsletter/investigation_vs_validation.asp Reprinted by Logigear, 2007

See, I hopped up on the "test vs. check" soapbox back in '05 when I got sick of being asked for performance requirements and test cases that start with "The system shall [x]" and "Verify that the system does [x]" (I provide much more detail about my distaste for Performance Test Cases in my Chapter of Beautiful Testing, due out in October). I used the terms "investigate vs. validate" in the hope of getting people to focus on what I was saying instead of arguing about whether or not validating (or checking) is "testing". It didn't really work. Instead of discussing/assessing/debating/enhancing the value and usefulness of the distinction, I found myself endlessly fielding question about whether I really *meant* to say "verifying" not "validating" because "At my company that's what we call it."

So I guess I'm jumping on the bandwagon, but it never hurts to have more supporting references.

As an aside, I cannot express how tired I am of hearing "At my company we call that...", "Well, that wouldn't work at my company", and "We don't do that at my company" used as a dismissal in response to almost any idea that requires thought, consideration, or (gasp) change. Ya'know what folks? The entire world is not like "your company." And if it were, then what, exactly, do you expect to find in training courses, magazines, blogs and conferences that will be of value to you? Seriously, if you think you know it all, stop being so greedy and start sharing it so the rest of us can catch up. Otherwise, what harm would it do you to actually take a moment to understand and consider what others have to say instead of being so rudely dismissive? Maybe what others are saying is appropriate for "your company" and maybe it's not, but how can you be sure when you're spending your energy dismissing the possibility rather than considering the possible applications, implications and derivations that *just might* be valuable or useful to "your company," or maybe even "your next company".

Honestly, to me it feels like testing, on the whole, is simply afraid to change. I don't get it. The rest of the software industry is changing constantly, but the overall state of testing seems to be bolted firmly in place. This isn't true for every individual, nor every company, so please, if this description doesn't fit you, don't take it personally. But if you don't believe this is the general state of affairs, go to testing conferences -- once every three years or so will do -- and tell me if you see any significant advancement (other than an amazing advancement in folks ability to repackage old ideas as new ones).
However, if you are contributing to testing's fear of change,to the fear of having to admit that someone else might have come up with something potentially or situationally valuable, or to the inertia that appears to be the root of why many testers are unwilling to consider ideas different from their own, then do the industry a favor and stay out of training classes, stop reading blogs, and above all please stop spending your time deliberately derailing discourse among those who actually want to collaborate thoughtfully in the hope of advancing the state of software testing beyond the '70's. When you're ready, come back with an open mind, your thinking cap on, your experiences at your side and you'll be welcomed with open arms -- at least by me.

This is just another case of the same 'ole debates resurfacing every few years. Maybe someday we'll advance beyond outdated ignorance and inertia, but in case that doesn't happen soon, I'm marking my calendar to republish my Investigate vs. Validate article in 2013 (with links to these discussions, and enhancements to encompass what I learn between now and then.) If the value, applications, and implications of thinking about the distinction doesn't catch on this time around, maybe it will then.
 
--
Scott Barber
Chief Technologist, PerfTestPlus, Inc.
About.me

Co-Author, Performance Testing Guidance for Web Applications
Author, Web Load Testing for Dummies
Contributing Author, Beautiful Testing, and How To Reduce the Cost of Testing

"If you can see it in your mind...
     you will find it in your life."