User Acceptance Testing: Calming the Nerves

One of the many "thorns in the side" of a software development project is the User Acceptance Testing phase (UAT). While absolutely necessary, it's often one of the most difficult to organize and effectively manage to get usable results. There are many in the development field who believe we need to rethink this process, and I tend to agree.

The very name of the phase, UAT, often strikes terror into the hearts of the very people without whom there is no UAT: the users. I think the users are largely okay with looking at new software elements, but when they're told they have to "test" it, they tend to freak! Since their input is so indispensable, how do we avoid the feelings of terror the name generates and get them on a productive path? Well, we can start by changing the name of the process to eliminate the word "testing".

When you get down right to it, the bulk of the testing is done before the user community gets its hands on the software. While they often find issues that get by the testing staff, that's not really their job. What the users are really tasked with is using the software as they would in production, then providing an assessment: is this the software we need to do our jobs? Does it work the way we want it to and do what we need it to do?

I've seen that when you eliminate the word "testing" while explaining what you need them to do, they tend to relax a bit. They still require guidance, but at least they start off on a more comfortable footing. So what I've started doing is calling it the "User Assessment Phase", ditching the "red flag" word "testing" all together.

A change in the mindset is just a first step in running an effective UAT, but it's a good beginning. I'd be interested in hearing how other folks have gotten past the panic the word "testing" seems to cause.

One of my "go-to" places for QA information outside the realm of my current experience is StickyMinds.com. The amount of information available for free is staggering, and it's always good to see how others view the profession.

Earlier today I was reading an article on StickyMinds by George Wilson, Operations Director of Original Software, called The Reality of Software Testing in an Agile Environment: Ten QA Myths Blown Apart. Mr. Wilson contrasts Test Driven Development with standard QA testing practices, making the case that TDD does not make the QA group obsolete (a point I agree with wholeheartedly). He makes a good case for QA and test automation, and I think it's worth a read. Check it out.

QA Tools for the Taking

Most of us in the QA community, I think, are aware that there are a lot of decent tools available to us that we don't have to pay for. Some of us may know it in the back of our heads, but just may not think of it when the occasion arises.

Here's a case in point. I'm presently in job search (or career transition, or whatever polite title you wish to give it). Part of this process involves talking with a great many people, networking to find that next opportunity. In the course of an informational interview, I encountered a QA manager of a small shop with a problem: no budget and a need for tools.

In my last position, I went through the same situation, having to begin building a tool set for QA without a budget. After some research, I discovered a wealth of open source tools that I could use without a monetary outlay. Of course, there is a cost: time, equipment, learning the tool, training others -- but compared with the cost of a "professional" tool, these ancillary costs are fairly minimal. Many of the tools you find are quite well built, though they may lack the polish of the programs you pay mega-bucks for. For the price, it's hard to beat them.

The QA manager I spoke with needed something better than spreadsheets and documents to keep his test cases in. I was able to point him to a tool I used with a lot of success at my last position available on SourceForge.net. Called RTH (Requirements and Testing Hub), it's similar in layout to TestDirector, giving you the capability to store requirements, test cases, test suites for specific releases, and the added bonus of a defect tracker built in. There are similar tools with different features: if you need it, you can find it, or at least come close!

The Software QA Community

I've been involved in Software Quality Assurance now for over 14 years, and it's a profession that I love. By the very nature of the job, there's always something new to discover: new tools, new processes, new schools of thought and more. One of the best discoveries you can make is that you're not alone by any means: there's a huge, thriving community of QA folks out there, eager to communicate and share what they know.

That discovery for me came well into my second year in QA. I was trying to figure out what it was all about, and I knew there had to be more. Strictly by chance, I stumbled on a local QA group, AQAA (Atlanta Quality Assurance Association, www.aqaa.org). I started going to meetings, and started learning pretty much anything and everything I wanted to know about my chosen profession. And I've been there ever since, serving on the board for several years now to try and pay back what the community has done for me.

There's more. QA folks gather all over the web. It seems that if you have a question or problem, the answer you need is only a few clicks away. Doesn't seem to matter what it is: process, tools, technical issues with a specific application... there's always someone willing to help.

If you're just starting down the QA path, welcome. If you've been doing this for awhile, and you haven't participated, get out there! Answer questions, join a local group -- if there isn't one where you are, start one! The QA community needs you. Hey, we're all in this together...