Oh, hi, everyone. Excuse me whilst I remove my platform shoes.
More stuff on the differences between manual testing and checking? Argh. I wrote an entire blog (which was brilliant by the way – sorry you won’t be able to read it) on the topic, but decided not to post it as I wrote it. Damn Michael Bolton and James Bach anyway. If you haven't read their blog entries on this topic, you'll need to do that first, or this won't make much sense.
After reading their blogs, I sat around and thought about it for a while and decided my response was knee-jerk.
I understand the concept. It’s not hard to understand. I believe it likely James Whittaker and everyone else understands it too. One of the most offensive (and repetitive) statements made by James Bach infer that people who disagree with him don't understand him. In other words "anyone who disagrees with me is stupid".
Well, I understand, all right. I’m just not sure I care. Maybe that's how Mr. Bach's "rivals" feel too.
But I’ll make a concession.
There IS a difference, when contemplating manual testing, between what one might call “sapient” tests, which are being done for the first time and require concentration, analysis, and intelligence, and “rote” tests that have been repeated multiple times and where you are verifying a system reaction has been unaffected by changes or new code. The latter takes less attention than the former. The latter can be very boring. We try to automate the latter. We give the latter to people new to the function. We cut the latter where we can. So I concede that I have different strategies for handling these two categories as they have defined them. Same thing with automated testing.
But here’s the thing. I already have terms for those differences and I already have different strategies for handling them. But if this is the first time some people have ever recognized those differences, well, what can I say? This is old stuff to me, with new terminology. If it helps some bright people come up with new and better ways to handle “checks”, new techniques that cut time, resources, or costs without throwing away the knowledge and NECESSARY checks those “rote” tests provide, I will concede it was a Good Thing.
I do want to say however, that I’ve noticed that when the pickings get slim, someone who hasn’t thought of anything new for a while picks up something old and tries to MAKE it new. I can’t help wondering if it was either “checks” or comparing testing to raising ferrets.
I have to say that my mind isn’t blown. In fact, I’m kind of bored with this particular topic as it stands right now. And just as an inconsequential aside, I don’t think an on-line account to the OED (Oxford English Dictionary) is particularly “sweet” either. I think “free” is sweet.
Other (no doubt lesser) dictionaries define “manual” as involving and using human effort, skill, power, energy, etc. Or “done by hand as opposed to machine”. Overall, manual testing does not evoke the concept of unskilled physical labor. I encourage you guys to come on down from that ivory tower and join the hoi polloi. Those kinds of statements make me think you’re out of touch.
I’d also like to make the point that intelligence and sapience are two different things. You can be the brightest bulb in the pack and still continue to plug into the wrong sockets. Sapience requires some common sense.
So anyway, I’m “bracing myself for insight”. Maybe some will be forthcoming soon. At least some solutions to the issues of minimizing time/money/resources spent on “checks” would provide some benefit to the field.
Now, if you'll excuse me, I'm going to get my disco ball going...
Rock on.
Monday, September 21, 2009
Subscribe to:
Post Comments (Atom)

5 comments:
Linda, I wish you'd get off the fence and say what you really mean ;-)
Nice.
I haven't stopped examining this topic, yet (although it gains less of my attention span just now), but my initial trigger for looking was "if it's not broken why fix it?" - ie, what's the root problem here... I suspect that root problem might not be anything more than communication (handling and talking about those different strategies to teams, stakeholders, etc.)
Hi Linda,
I have to say when i read Michael Bolton's post of testing vs checking, I thought it was insightful. I liked the way it distinguished between the two.
I have no problem identifying with both types testing and checking and quite happily use both on a client assignment.
However, I find myself agreeing with you too! I can quite clearly see the similarities to 'regression testing' and checking and I wonder if this is not just a rehash.
So, I don't know where this leaves me. Either I am easily swayed or perhaps there is validity in what both you and michael write.
Anne-Marie
http://mavericktester
Actually,thinking about it, I disagree with you on this one Linda.
Regression testing requires combination of testing and checking.
First you 'check' the fix is made, and then you 'test' the application. In this way, I do see a difference to what you've written.
Michael also discusses automated testing and describes this as checking. I think that is a new concept too.
I never mentioned the term "regression testing" in my post (quite deliberately), and I was wondering if someone else would. I find it interesting that you did.
The term "check" is going to be confusing. To "check" can mean to investigate or test; not the definition the authors of this brouhaha were looking for, I think.
I don't think I view "checking", as it has been defined, the same way that you do. Regression testing would, to me, be a check. If a change/fix/enhancement came in that required an original test(s) be modified, I would no longer consider that a "regression test" and it would not, therefore, be a "check".
My perception of the term "check" is also somewhat broader than others; I can see cases where new, functional "testing" could also be considered "checks". I can think of several conversion projects I've worked on where this would have been the case.
As far as automation goes, the very nature of automated tests makes them "checks". I find nothing new in this concept. I believe creating those tests is a significantly cerebral activity, but the actual running of them; well, not. That's the reason we automate them in the first place. So human beings aren't wasting their time and brainpower on something better served by a machine.
I think the testing effort, with functional, regression, and automated tests, represents both "testing" and "checking"; I'm not sure I'd break down regression testing specifically into "testing" and "checking". For me, regression tests represent "been there, done that". Functional tests require investigation, analysis, and more of my attention.
I can't believe I'm even talking about this; I normally don't get involved in terminology discussions. They make me want to bang my head against a wall until my brains leak out my ears. Maybe that's the real meaning of "blowing one's mind".
Regardless, I can't really see any benefit to the concept, other than to add another term that everyone will interpret differently to a field that already has too much of that problem.
Thanks for the posts; agree or disagree, you certainly got me involved in spite of myself!
- Linda
I too am utterly bored of this particular "controversy." I'm a nobody in the testing world, and honestly, I like it that way. I do my job, do it well, and am compensated handsomely for it. So I risk nothing by saying that I read Michael's blog, and most of what he writes makes me think he spends a LOT of time thinking about "schools" and "theories" and "disciplines," and not much time actually testing or dealing with stakeholders.
There's more I want to say, but it's not particularly polite, so I'll leave it at that. Because my mama raised me right, that's why! ;-)
I do enjoy your blog. Please post more often.
Post a Comment