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?
Elisabeth,
One time, I went to the doctor. That is amazing in and of itself but is not the point of my comment.
I had gone to have a mole looked at. The nurse, who was busy running all the setup routines in anticipation of the doctor, quipped that it probably was cancerous. “Most people develop some kind of cellular anomaly in their lives”, she said with all the cold and callous concern a butcher might have for some hamburger meat.
Part of my proficiency for testing is my predilection for pessimism. Her “diagnosis” did not bode well for me. It caused all sort of undue stress and anxiety. My mind ruminated on all the tearful activities that awaited me; saying goodbye to friends and family, what music will they play at the service, etc. Mind you, the doctor hadn’t even SHOWN UP yet!!! When he did finally show up, he allayed my fears with a more educated diagnosis – “you’re just mole-y. Why are you crying?”
That nurse by virtue of her position/location brought to bear the air of authority. She certainly said all the educated words. And given the circumstance all that my mind heard was, “you’re gonna die.” How was I to know?
I love to break thing so I can see how they work. And when something breaks, I view it as an opportunity for me to observe the thing’s inner-workings. But I’ve been able to avoid freaking customers out by not doing such diagnoses in front of them. I save that conversation for the developers lest I come off as an authority. Or much worse – the nurse that said, “you’re gonna die”.
Still very much alive,
Zach Fisher
My thought is that you took the nurse’s comment personally. This can interfere with being present and observing the true nature of the social context. Which in turn may lead to personal conclusions versus an analytical evaluation. The medical context has it own “way of doing thing” – a culture unto itself. If you were the nurse how would you have handled the situation? Thanks – Herb