thriller

The Right Way Of Usability Testing: A Thriller Based on Actual Events

Knowledge comes with experience

There are lots of various situations that are occurring while you are performing Usability tests. People are different. You will never be able to prepare yourself to all the possible challenges, yet you may be ready for as much as 95% if you put your mind to it. Sure true knowledge comes only with experience but who told that experience has to be yours?

This is the part that is actually based on events that took place a while ago. There was this adorable senior guy I’ve came across with in one of my Usability Tests some time ago. And I was really surprised with what was going on next as his knowledge of computers ended somewhere around the part when you need to turn the machine on. His knowledge of the Internet was not even nearly as good. Thus we did have a pleasant chat, he was a war veteran by the way and had quite a pack of interesting stories. Stories that had like zero value to my testing. Thus I ended up being a ‘great lad’ as I was told and that is pretty much all I’ve gained. I’m not even sure if the experience was unpleasant as I actually enjoyed the company, yet I’d love to avoid that in further testing-related duties. So how does one prevent such and other similar happenings? The following will be based on actual events as well.

The questions you have no answers to

There once was a day in my life when I was (seemingly) done with quite a bit of testing thus I was reporting to the stakeholders. And you can’t even imagine my surprise when I was asked things I had not even a clue about. They literally were shooting with various stuff straight at my face with approximate speed of 197.8 questions per second. Questions I believed never had any value to the project whatsoever thus they were not in my list I’ve used while testing. What I actually did was picking out the main areas of the app and asking users the pretty same questions about those parts only. A bad way of mobile apps testing.

What I should’ve done? I had to ask the stakeholders first with what they are actually interested. Thus you are to answer questions that seem important to the people you are testing for. After all, that’s not your app. If the questions seem weird or useless be sure to get some extra info from the stakeholders on the matters that are interesting you.

Great feedback, foul results

If you are testing a website be sure the users don’t know which one is yours. Give them several pages to play with and you will get the honest feedback. There was once a project on which I’ve made a crucial mistake of spilling what exactly I am testing. It may, sometimes, be quite challenging for people to tell you the bitter truth for various psychological reasons I’m not too much into. And you will be gaining credit for things you that are actually awful. That is one major way of ruining a test. A great trick here is to make participants to actually look at your competitor’s websites first and you will even have some feedback on how they are good in a king and what people like and dislike about them. Implement the best and avoid the worst. The approach is a bit dirty, yet successful.

Here is some experience I’ve been through at a certain point of my life and I truly hope it will help you in your path. The best of luck to all you, guys.


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

×