But it worked for me…

“It worked for me…”

As an IT professional, if you ever hear those words come out of your mouth, it is my hope that you are reading along with this blog post or citing Colin Powell’s book. Otherwise, take a deep breath, step back, and realize that those words are not going to get you closer to a solution, and may cause someone to become your new mortal enemy.

When talking about an application or a solution, “It worked for me” implies that the person coming to you for help is doing something wrong or is somehow less capable than you are. One or both of those things may be true, but you do not yet have enough information to leap to that judgment. At this point, you should seek to understand what the person was trying to accomplish, what he/she did, and what actually occurred. This is all standard help desk protocol.

This post is not about helping that person though, it is about preventing the person from needing help.

By the time someone approaches you with a problem, you have missed the first few chances to prevent the situation from occurring. The more time and effort you can put into testing before releasing a product to your general user population, the more likely you are to avoid having situations where you would be tempted to say that it worked for you.

These tips are not a substitute for a formal testing process under a system development lifecycle. Think of them as part of the final once-over before you declare a release generally-available.

Forget what you know about the product

The downside of having spent a lot of time in development is that we tend to follow only the same paths through the product in each test. If you have to turn the interface upside-down so you cause yourself to think about the interface and what you are trying to accomplish, do it.

Don’t skip any steps

Log out and log in each time. Select a different item in the drop-down from the one that is cached. Removed and add a printer. You get the point. You may have tested something two weeks ago and it worked then, but your regression tests missed it because it was too obvious.

Do things out of order

What kind of person would input the second line of an address before the first? Who enters the password before the user ID? What kind of crazy person would tap the Submit button five times in a row when the beach ball is spinning? You should be that kind of person; some of your users will be.

Have a novice test for you

Turn someone loose on your application or product who has never used it before. Watch them. Take notes. Record them if they’ll let you. Watch the recording. Read your notes. They may interact with your product differently than everyone else on your team. Even if they don’t break something, you may want to update your documentation to reflect the paths they took.

The more you test for the unexpected, the less likely you’ll be in a situation that something worked for you but failed for your user.

Oh, and don’t get me started on “Have you tried rebooting?”