I’ve just arrived home after a whirlwind trip to London for LEWT (James Lyndsay’s London Exploratory Workshop on Testing). Great fun discussing testing with a fabulous set of people! And since I was only in London for 48 hours my body didn’t have a chance to adjust to the time difference. Result: no jetlag when I got home. Yeah!
Anyway…about LEWT. The topic of LEWT was diagnosis. Our discussions included such questions as “How do we do it?” and “Should testers even be doing it, or is it a developer responsibility?”
In the context of testing, I interpret the verb “to diagnose” to mean “characterizing the conditions that lead to a failure.” So I most certainly believe that testers should diagnose. So should developers. Everyone on a software team should have a hand in understanding bugs well enough to fix them and prevent them in the future. But I think the “should we?” questions arose because the word has connotations from a medical context related to identifying diseases and prescribing cures. And I don’t think testers typically ought to be prescribing cures, or pinpointing the line of code that needs fixing, unless those testers are also developers on the team, responsible for writing production code.
However, I digress.
What I REALLY wanted to share from LEWT are James Lyndsay’s marvelous black box testing machines.
For years, James Lyndsay has used little Flash programs in his Exploratory Testing courses. Most of his machines have colorful buttons that you click, and your task is to understand how your actions are related to the machine’s responses. Sometimes the connection is straightforward. In other cases the relationship between the input you give the machine and what it does is downright puzzling. That’s why James refers to his machines as “crosswords for testers.”
Given that it’s the week right before the holidays, and you probably aren’t going to get much done at work anyway, why not hone your testing and diagnosis skills on James’ machines?