“You can observe a lot by just watching” — Yogi Berra
I’d just joined a newly formed software team. After a kickoff meeting, we all headed out to eat. “When did you get back from the East Coast?” I asked one of my new coworkers while we were browsing the menu.
“Huh?”
His puzzlement was understandable. We’d just met. I knew nothing about him. I didn’t actually know that he’d been on the East Coast. But I did know that 1) he worked for a consulting firm and traveled quite a bit, 2) that the newly-formed team was having lunch in San Francisco, and 3) that his watch was set for three hours later, East Coast time. I explained my observations and conclusion.
He looked stunned. “Yesterday,” he mumbled.
Testers naturally notice details. Not only do we notice, but we think about what we noticed, we attempt to interpret our observations to explain why things might be that way, we ask others if they noticed, we question our assumptions, and we poke and prod at things to see if our understanding is correct. We use our observations to inform us, and in doing so discover underlying causes and effects we otherwise might miss.
One person testing graphically-intensive programs reported that he’s often noticed a little glitch, a pixel or two that just weren’t right, and had it turn out to be a symptom of a major bug. He discovers these things because he doesn’t just notice the glitch, he follows up on it. He makes the glitch happen over and over again. Having understood the circumstances surrounding the little visual glitch, he then experiments to see if he can make the glitch worse in some way: bigger, longer, more frequent. He hypothesizes about what might be causing the glitch, then finds ways to experimentally confirm or deny his hypothesis.
Testers don’t just look for anomalies. We listen for them too. Others have told me how their ears have alerted them to problems.
I’ve had a bug like that once: I was working late testing some software. The room was dead silent, so silent that I heard the quick whiiirrr whenever my hard drive spun up. I noticed it was spinning up every minute or so. I wondered why my disk was spinning so often. I investigated. It turned out that the software I was testing was causing the hard drive to spin up. That little side effect behavior might not have been such a big deal, except that it meant that our software would prevent laptops from going to sleep. For the software I was testing (a little utility that should not interfere with normal machine function), that was a major no-no.
We might have caught the bug by looking for it, if we’d had time to run all the tests including the laptops-go-to-sleep tests. But the software I was testing was a last minute patch. I felt very lucky to have spotted (or heard) the bug.
The point? When you’re testing, look and listen for surprises: anything that seems out of the ordinary, no matter how small or insignificant. Those surprises may well alert you to a far bigger potential problem than you ever imagined.
