Usability testing is done for roughly the same reason as other kinds of testing: To discover new knowledge about the system under test. In this case knowledge about how users work with the system.
But Usability Testing is a very different discipline from ordinary system testing.
In my opinion, the one thing that makes usability testing different from system testing is, that it never discovers absolute facts about the system.
Instead, a usability test will only say something about how the system works in relation to someone – and this someone is a person – or persons. And as you have probably experienced several times in your life, real persons aren’t absolute, predictable, or static – they’re quite dynamic and you never really know what to expect. Usability testing is a bit like integration testing against a remote system, which keeps changing, even while you test it!
Another aspect is that it’s much more important, yet also more difficult, to describe the context in which the system is to be used and the test is executed in.
I’ll illustrate that with a basic example: Many corporations implement systems for internal use which are not really user friendly, but since the employees get paid for using them, they don’t mind this – and once they’ve used the system for a few weeks, the system may have become an efficient work tool. An opposite example is most computer games, which are deliberately designed to be inefficient, but are usually easy to learn and use. These two systems or applications may be used on the same day by the same person, but in different situations, of course.
Setting the context is not always possible, though. For example is that most people will only respond to things which they understand: Chances are that if you had tested Facebook on users in 1995, they wouldn’t like it at all because they would not understand what it was to be useful for.
Essentially, I feel that the tester must be much more conscious about what he is doing and how it is affeting the test results. I actually believe that the description of the context itself and the way you describe it is as influential on the results you get, as the system and the users themselves.
Yes, testing usability can be very challenging!
Month: November 2010
WordPress used to have a tagline saying “code is poetry”, apparantly Microsft has used it too. I don’t know who came up with it first, but I agree. I wrote my first piece of BASIC code almost 30 years ago, my first machine code program more than 25 years ago, and learned C also about 25 years ago. Code can be as meaningful and meaningless as poetry, so the analogy is correct. To me at least.
Now, many years later, I’m a professional tester. I find problems with other peoples business processes, architecture, software designs, and implementations. I don’t write code any more (except when I’m using it to test something).
But where’s the poetry? Is testing essentially a non-poetic activity?
I don’t think so. Yet, it doesn’t make sense to say “tests are poetry”. They aren’t. Then, what are they?
Natural born tester
When I was still a child, I could not have a new toy without starting to find out how I could get inside and find out how it was built. It was often distracting me away from the intended use of the toy.
I was annoyingly courious! I don’t know when it started, but I know that I have never found a cure for it. I played with LEGO’s a lot – I think that satisfied my constructive instinct – but couriosity was always there: I dismantled mechanical and electronic toys, the old alarm clock, vacuum tube radios, loudspeakers, computers…
Couriosity can lead to new knowledge or to destruction – or both. I didn’t always find out how things worked. For example, a vacuum tube does not itself reveal how it works like a gear and a spring can do. So my couriosity was sometimes not really satisfied. That didn’t turn me down, however. I kept on taking things apart!
I’ve “sharpened my pencil” a lot since then and now have a much better understanding of product development and how to use my couriosity in a way that is not destructive at all, but usually very constructive. I am a professional tester and I’m able to quickly and effeciently discover facts about new things that nobody knew about (some of these facts are called “bugs”). My job is to pipe those facts back to the developers who can use them to improve the software they are responsible for.
That’s what a tester does. Whether you’re “natural born” or has discovered the techniques later in life isn’t important. Couriosity is important!
Software is based on technology and software engineers love it. The most popular subject of discussions between programmers is which platform to choose for the next project, what tools to use, and what development methodololgy to use.
New technologies and methods are heavily accompanied by marketing campaigns that promise many good things if we base our new product, project management, testing etc on this great new invention. They don’t even have to be commercial products: There are people in our industry who advocate common paradigms and free tools very firmly without any kind of focus on their limits.
During my career, I have found that technology fascination alone usually leads us nowhere in terms of business value and making a different to users.
In this series of blog posts, I’m going to point out why we have to pay specific attention to this pit-fall, and why we must repeatedly to evaluate the technology we’re using against its influence on the result of the project: The product.
I’m going to suggest a product focused software development paradigm.
Focusing on the end product (and knowing how to focus) in software development projects, will lead to better products.
Even with years of experience, I always feel I have to look somewhere to become wiser. To learn. To develop.
In 2009, I spent one happy day at Agile Testing Days in Berlin. A wonderful venue, great conference. For personal reasons, I could only allocate that one single day, and I promised myself to return for the full conference this year.
Unfortunately something came in the way, and I started looking for something else. Something that could refresh me. And I came across Micahel Bolton and James Bach’s course on Rapid Software Testing and found that it was being held in London – and the time actually did fit in my calendar.
The course was excellent – just what I needed – and my tester brain has been re-fuelled.