- My fuel gauge is on empty.
- I don’t want to stop, but pull into the gas station.
- I tell the children to stay in the car.
- I get out of the car.
- The children are asking me questions from inside the car that I can’t hear well enough to understand.
- I swipe my credit card in the pump’s card reader.
- The pump responds by prompting me to “SELECT WINDOW OR OUTSIDE“.
- The children are still talking to me. I still don’t understand.
- I pause and stare at the keypad.
Is there a problem here?
- I pause to think for a moment.
- I hear the children asking me questions that I still don’t understand through the closed car windows.
- I scan the keypad again.
- I cant find the “OUTSIDE” button.
At CAST last week, Pradeep Soundararajan gave a Lighting Talk about the importance of testers being able to recognize a bug. Tests may be of little use if the tester doesn’t recognize the bugs triggered by the test.
Sometimes bugs are obvious. Sometimes bugs are not clearly violations of requirements documents. This is especially true when it comes to human computer interaction problems.
Requirements are not always clear and objective.
So, do you recognize why I may have paused when I read the prompt on the gasoline pump? It wasn’t the price of the $4 per gallon fuel. It wasn’t because I had to think about how I wanted to pay.
I paused because I didn’t see a button labeled “OUTSIDE”. Plus, I already swiped my credit card indicating that I wanted to pay at the pump. And even if I were to pay at the cashier window, I would still be outside.
I wonder how many minutes are wasted each month prompting customers to select where they want to pay after they have swiped their credit card. I wonder how many other people pause and read twice in search of the button to indicate that they want to pay outside.
The developers and testers of the software in this pump may have not recognized this problem. Maybe the makers executed test scripts — either automated or manual — and were blind to the problem. Or maybe they didn’t deem it important enough to change.
Sometimes familiarity with the technical details of a system can hide problems that are obvious to those that don’t know the technology, the requirements documents, and the test scripts. As testers it is important that we be careful not to let our familiarity with a system make us blind to to bugs — things that bug our users.
Will you recognize a problem if you see it?