RonJeffries in a paper located at http://www.XProgramming.com/xpmag/whatisXP.htm referred to the AcceptanceTest as a CustomerTest.

This is to clarify that AcceptanceTest''''''s are owned and defined (with assistance) by the Customer.  This is similar to UnitTest''''''s being called ProgrammerTest''''''s now.

----
An interesting twist. I think it works. It gets across the big point that customer really is responsible for devising the tests. Didn't like the article though. It's a little clunky.
----
I like the article.  It is short and sweet. -- MichaelFinney
----
I do not understand the desire to call AcceptanceTest''''''s CustomerTest''''''s, and UnitTest''''''s ProgrammerTest''''''s ... basically, the customer needs to do more types of testing than what is covered by just AcceptanceTest''''''s. For example, load testing and system testing also are part of the types of tests the customer needs to run. In addition, programmers need to do integration testing in addition to unit testing!? -- BrettKotch
----
Programmers (or somebody else in the software organisation, but not the customer) do need to run integration tests, as well as test load/performance/resiliency. That's, as I understand it, exactly the reason to rename UnitTest to ProgrammerTest.

Unit Testing is limited in what it can and cannot test unless you perform unit testing across a variety of tools such as a bot combined with JUNIT/CPPUNIT and high test plus scripting, Rafael Kobylinski describes a tool: http://www.bruegge.in.tum.de/people/kobylinski/Awareness.pdf that takes Acceptance Tests as the definitive testing mechanism and I feel considering agile processes are both customer and test driven this may be the way to go, now taking this from another angle such as in a distributed environment where co-located customers may not be available is another story.
-- PaulPriorSToRC

As for SystemTest vs AcceptanceTest, these two are essentially the same. There is absolutely no difference in their scope. Only that they are done by different groups of people - usually with vastly different competencies, and with somewhat different vested interest.

Therefore, if customer does AcceptanceTest the XP way, separate system test activity does not add value.

In the RealWorld, we do separate system testing because we expect the programmers to screw up in one way or another, and we are afraid to let the customer know it.

''Perhaps you are thinking of the wrong person as your customer, as far as this testing is concerned?  Does it help to think of your system test team as the customer (since they are taking on the role of AcceptanceTest''''''ing which XP assigns to the customer)?''

I always wanted somebody from the customer side to be embedded with my team, but rarely had the privilege (my current job is to run system test teams for projects sized 20-100 man-years).

By the way, has anybody toyed with the idea of PairTesting as a way to design or execute manual system tests? I had some good experiences with this approach - usually paired with the customer, by the way.

-- AlexeyVerkhovsky

LineByLineReview is a pattern for using PairTesting to design manual system tests.
----
CategoryTesting
CategoryRealWorld