Usability Testing: Worst Practices

by TestFortExpert on 12/29/2014

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.

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.
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.
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 Work With

Having one outside team deal with every aspect of quality assurance on your software project saves you time and money on creating an in-house QA department. We have dedicated testing engineers with years of experience, and here is what they can help you with.

Software is everywhere around us, and it’s essential for your testing team to be familiar with all the various types and platforms software can come with. In 21+ years, our QA team has tested every type of software there is, and here are some of their specialties.

There are dozens of different types of testing, but it takes a team of experts to know which ones are relevant to your software project and how to include them in the testing strategy the right way. These are just some of the testing types our QA engineers excel in.

The success of a software project depends, among other things, on whether it’s the right fit for the industry it’s in. And that is true not just for the development stage, but also for QA. Different industry have different software requirements, and our team knows all about them.

Full-Cycle Services

By Platform

By Type

Industries