Nick Riviera

Usability Testing: Worst Practices

Usability matters

Let’s face the facts. There will eventually come the time when your software will be used (wrongly mostly) by various different users. They are indeed a tough crowd. World’s most strict critics are no match to a user with several followers and internet connection. And this does mean any solution requires tough usability testing before going live. So let’s get to the chase with what you are NOT to do when testing usability.

  1. You DON’T want to be late with tests. It’s a common practice to get into usability testing after all code has already been written. Other people are confusing it with acceptance testing. This is determined due a foul belief that if usability test is interrupting development it will take more time for the product to launch. What does practice have to say about such approaches? A defect is easier to fix after it was just made and not after it is covered with 76 layers of code. If testing is done on late stages of development it may (and will) take even more time than expected due this simple and seemingly obvious reason. Many features will even have to be rewritten in the worst scenario when, if tasted in smaller portions fixes would require way less effort.
  2. You DON’T want to test wrong. Meaning using inappropriate methods without required tools. There are several steps you are to take here for all to go smooth:
    1. Make sure the tool used for data collection is doing a great job. It has to be easily used and testers are to be familiar with it.
    2. Actually it would be great if all involved have some time to get acquainted to all of the software they will be using on this project.
    3. Don’t use yes/no questions for testing giving advantage to the ones requiring more open answers.
    4. Don’t guide participants through testing. Avoid the temptation of tipping them with what should they do.
    5. Prepare a list of possible issues that may occur during testing and ways of overcoming them.
  3. You DON’T test software with people who are not related to your target audience. Surely the easiest way is to grab some friend from a Friday night at a pub, show them your product and see what they are finding of it. It’s even worse when they are either related to the project or possess any development/QA skills. Such tests will simply be of zero value unless you are developing a solution for programmers/QA engineers. What is the right way of preparing for this step?
    1. Gather all required info of who will be using your software.
    2. Find a blend of different people with different skills and a shared goal they would try to gain from your product.

And you are probably set to go now without following mistakes of others.

Image via Matt Groening


TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.


no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017

×