Hey ThoughtWorkers,
So at TWU we learned about a ton of different ways to test software: Unit Tests, Functional Testing, GUI Testing, etc. Here’s my question:
What’s the point of a tested tool that the user (or perhaps customer, if you prefer) finds difficult to actually use? What about Usability Testing? How about testing to see if your deliverables meet the problems found during analysis? Where do these kinds of testing come in?
Sincerely,
Josh
The ‘ton of different ways to test software’ you probably learned about were, probably, tons of ways to test software in an automated fashion.
While usability testing or similar things under the same sort of umbrella certainly have lots of value, they can’t yet be done automatically, at every build, and kind of rely heavily on human input and psychological factors.
That said, figuring out how your users/customers are using the software you’re building is the easy bit, and can be done by analizing logs, clickpaths and such. The tricky bit is interpreting that information, as badly designed UIs tend to hide the fact that users are stumbling around a lot without getting much done.
For reference, try accomplishing somewhat simple tasks like searching for that e-mail you got from John Doe in November last year in Lotus Notes – a lot of clicking around, but not much getting done. Then try the same in, say, Outlook or GMail.
While I agree that usability testing can’t be done automatically (and never, ever will be), I’m not sure it needs to be the sort of thing done at every build. Why would we need to look at it at that level?
Analyzing logs and clickpaths also don’t tell you where people are running into problems…and badly designed UIs tend not to hide bad usability at all, imho, that’s why most people are constantly complaining that they’re “not very good at doing things on computers.”
Leave a Reply