Way back at the start of my career in software, I had a boss who was great at doing QA. He was notorious for being “able to break anything” – and I’ve never forgotten my lessons from him. (Thanks, Barry!)
He taught me to test everything a few different ways:
- Use the feature the way it was designed to be used.
- Use the feature, but pretend you are from Mars and have no idea what it’s for.
- Use the feature, but pretend you are a malicious jerk – feed it garbage on purpose.
- Use the feature as if you are a jaded, experienced power user looking for a shortcut or to hack the system.
Most often, people test the first way and don’t invest time in additional ways. But those wacky testing methods are the ones that give you the most return in terms of improved quality.
I’m From Mars – What’s This Gizmo Do?
Pretending that you know nothing about the feature or the application can help you spot things that are confusing or hard to see. This method will help you find usability flaws. Your application might function just fine, but be hard to learn without a manual, or be confusing in some situations.
If you struggle to put your hard-earned knowledge aside, recruit a friend or relative who really does know nothing about the system to spend 15 minutes clicking on your tool. Bribe them with a snack if you have to! Watch what they do, and ask them to think out loud as they use your feature.
In addition to adjusting things to make them easier to find and to learn, you can also help inexperienced users by giving them clear, specific error messages when they make a mistake. This Usability Geek article gives a good overview with illuminating examples of good and bad messaging. And let’s face it, even our experienced users are occasionally distracted and need our help to prevent and correct mistakes!
LOL, What Happens If I Paste The Encyclopedia Britannica In This Field?
Pretending to be a malicious trickster can be the most fun way of testing. For any given field, give it input that is too long by a little, too long by a lot, too short, the wrong data type, full of carriage returns, whatever kooky thing you can think of. I promise that some user someday will try it, on purpose or by accident.
Load up your application in a tiny window or actually on a real phone and see what happens.
Leave fields empty and click submit anyway – be reckless! If that’s allowed without error, should it be?
Put some real data into the application, not just your fake test data, and see if anything is too big, too small, too dull, or otherwise flawed.
This checklist from UX Planet is a solid starting point and might help you think of new ways to break your feature.
Or check out this collection of ideas for the Worst Volume Control UI in the World, reliable for laughs, and guaranteed to help you think of a new way to break something.
Oh No, Not THIS Again
What happens to your new feature once everyone is used to it, and the shiny is worn off the new toy? Are there mistakes that can happen because users aren’t as careful as they were early on? Do those two buttons look too much alike?
When the users are doing this task in their sleep, over and over every day, does your feature take too long to use? Are there shortcuts or batching options that you could offer to those users?
You might not choose to implement changes like this right away, but it’s always good to get a little advance notice on a potential issue. I like Rands In Repose’s “blue tape” analogy for managing changes/improvements, prioritizing the essential ones first, and letting the other ones marinate a little while to see if they’re truly needed.
Or, taking a slightly different flavor of “power user,” what happens if someone knows quite a lot about your application and your data structure and then decides to do something nasty? Or what if a hacker were to take an interest in your application? Would these bad actors be able to find any backdoors or vulnerabilities in your system?
Result
No QA process ever finds every single flaw in software. Sometimes you just have to use the thing in real life and see what happens. But trying on some of these approaches to break your software in advance will definitely improve your quality – and perhaps make you as notorious as Barry for your ability to break anything.
Do you need someone to take an objective look into your QA process? Our team may be able to help. Contact us to learn more.
