December 3, 2009

Why External UI Testing Matters

I'm not a UI/UX person, nor do I have a degree in human-computer interaction. I'm a programmer. And today, a client is going to yell at me.

Long story short: a web application I created a while back was supposed to automatically save user-entered data, which it did - but only if the user followed a specific interaction sequence. Of course, this specific interaction sequence made perfect sense to me, our QA group, and our client's beta test group, as not a single person reported having a problem with saving data prior to the application's commercial release.

Now, almost a year after release, complaints are pouring in from our client's customers about issues with data saving. After looking at all of the potential causes of such a failure I found the cause: user interaction sequences that were not captured at any point during the design and development application, and thus do not trigger data saving.

Of course, since these alternative sequences were discovered we've added the appropriate code to save data, and the application is working well. But, that isn't going to keep me from getting yelled at by our client.

So, what have I learned from this experience?

I've learned that sometimes, no matter how thorough an internal QA team might be, they're just too close to the project to be able to see all of the potential problems that might occur on the end-user side of the application. Thus, I've concluded that on applications such as this one it is important to conduct black-box testing with users who have at most minimal familiarity with the project's deliverables. I'm confident that if we'd had someone external to the project sit down and go through the application without any prompting or coaching, the problematic UI sequences would have been captured and addressed long before the application was released.

...and I wouldn't be getting yelled at.

No comments: