Re-Cognize to Avoid Mental Errors

A little story to talk about some of the ways our inattention can lead us to miss some mistakes.

For years, I’d heard about an awesome British television program that, although it aired on PBS and had not reached popularity among mainstream Americans certainly got its discussion amongst the tech crowd which tends to favor BBC programs that air on PBS. The show?

Downtown Abbey

Or so I thought. I had seen discussion of the program on the Internet, as I mentioned, and and I watched the introduction to it seven times, and I saw it on a Roku menu many times. I even started a Twitter hashtag called #DowntownAbbeySpoilers to demonstrate my particular brand of wit and to flaunt my ignorance before the Internet. It was only in the seventh episode, which includes a scene at the Downton train station clearly labeled as such, did I discover my error.

Downton Abbey, not Downtown Abbey

I was chuffed, to say the least.

I’d read the word as Downtown at some point, maybe a misspelling or a bad pattern matching on my part, and every time I saw the title, my brain filled that Downtown instead of Downton. Every blooming time.

I started planning this post in my head, I encountered a misspelling in the application I’m testing. Although I’ve hit the screen a number of times, I’d missed the misspelling every time I saw the page previously until just yesterday, when I happened to look at the extraneous letter in the middle of the word. Other times, my eyes had skipped right over the defect like a smooth stone over still water.

The way to avoid these types of oversights, as I always have said, is to slow down and to look at everything with fresh eyes as often as possible. Take some time to read every word and to test every control in different combinations. Focusing on the higher-level functions of an application is very important, but focusing on individual parts of it at a very atomic level will find a number of problems that your users will eventually find if you don’t (and fix) first.

Now, onto the second error: trusting the context.

My UK readers and many of the Downton Abbey fans here in the US and elsewhere might be chortling about what I said above: I was chuffed, to say the least.

It sounds like a combination of chagrined and maybe huffed, doesn’t it? You’re forgiven if you assumed it meant something like that from context. But chuffed means pleased. I was not pleased at all.

This kind of oversight comes when you trust the context of something, generally in terms of application behavior. When you click that button, of course it does that. It’s not crazy enough out of whack to be an obvious bug, so you let it go. This happens a lot in two cases: if you’re testing something in an industry or vertical in which you’re not already steeped, like counting DIDs for a telecommunications company’s order scheduling software. If the number of DIDs doesn’t match the number of telephones and never has, will you notice it as long as you can save the order and make sure it displays properly on the technicians’ tablets? Maybe not.

The other place where you can get into that sort of trouble is after you’ve tested an application for a long enough period of time that its evolution gets a little mixed in your mind. Did that used to work? Did it used to do something different? Should it do something other than what it does?

To try to minimize these style oversights, don’t trust the context. Try to learn why the context is the way it is. If something seems strange, ask. And if the person you asks says, “Just because,” “Trust me,” or “It’s always been that way,” open your defect tracker. Because QA has always been that way, just because. Trust me.

So the lessons are, again, slow down and learn as much as you can while you’re testing something to test it most effectively, and not to trust yourself or your context because you’ve been wrong before. Or at least I have. AND I AM NOT CHUFFED ABOUT IT.

Comments are closed.

wordpress visitors