Wherever you are, you can help Ukraine

Act Now! Flag Ukraine

Usability Testing: Worst Practices

TestFortExpert by TestFortExpert on 12/29/2014

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

We use cookies to ensure your best experience. By continuing to browse this site, you accept the use of cookies and "third-party" cookies. For more information or to refuse consent to some cookies, please see our Privacy Policy and Cookie Policy