User acceptance testing and test cases

Q- What's the purpose of acceptance testing? Can we use the same test cases of system testing for acceptance testing?

A- As with most questions folks ask about items related to software testing, the answer starts with "It depends…" In this case, it depends on what the client or team means when they refer to acceptance testing (and possibly how the team defines and implements test cases). Rather than dig too far into all of the variability in the use of these terms I've seen over the course of my career, I'm going to state some assumptions.

Let's assume that we're talking about "user acceptance testing." Acceptance testing could relate to anyone whose approval is required prior to launching an application, but user acceptance testing is by far the most common. Further, let's assume Cem Kaner's definition of a test case -- "a test case is a question that you ask of the program. The point of running the test is to gain information, for example whether the program will pass or fail the test." This allows us to focus on the point of having test cases rather than focusing on how they are documented.

With that out of the way, let's take a look at the first part of the question – "What is the purpose of acceptance testing?" Simply speaking, the purpose is to give the end-user a chance to give the development team feed back as to whether or not the software meets their needs. Ultimately, it's the user that needs to be satisfied with the application, not the testers, managers or contract writers. Personally, I think user acceptance testing is one of the most important types of testing we can conduct on a product. The way I see it, I care a whole lot more about whether users are happy about the way a program works than whether or not the program passes a bunch of tests that were created by testers in an attempt to validate the requirements that an analyst did their best to capture and a programmer interpreted based on their understanding of those requirements.
Which leads us to the second part of the question – "Can we use the same test cases for system testing and acceptance testing." I've seen a lot of projects where there is a tester put in charge of developing user acceptance tests. They start with test cases. They then write detailed scripts, including test data, for users to follow through the application and ask those users to check boxes on those scripts as pass or fail for the test cases the tester decided to include. Sometimes at the end of the script the tester leaves a section for free responses from the end-users, but in my experience, not very often.

Now, that process has never made any sense to me. If the point of user acceptance testing is to find out if the user is happy with the software, what sense does it make for some tester to tell them what to look for? Why not just ask the users to try the software and tell the team what they think? The only answer to that question I've ever gotten is "It's too hard to figure out if they are actually happy, so we're just trying to figure out if we gave them what they asked for according to the requirements document that they signed off on." Which boils down to "we're just getting the users to agree that we should get paid." So, if that is your goal, go ahead and use system test cases. But if your goal is to determine user satisfaction, just let them use the system and tell you what they like and what they don't like about the system. I'm willing to bet you'll end up with a better application that way.

BY-Scott Barber