Acceptance
testing is the final exam of a software development project. The title
of this type of testing has a very positive meaning;
however, there is no guarantee of acceptance. An acceptance test
suite is intended to exercise the system in its target environment
under standard loads with standard user interaction patterns.
Acceptance testing
merits
having its activity oval present at the highest level software
development process flow due to its importance. A course syllabus will
likely prominently mention the final exam along with its large
influence on the final course grade calculation. In the same way, the
acceptance test (AKA FQT test suite in government contract contexts) is
the final criteria gating mechanism before a software product enters
the world.
Depending on the contract that exists between the developing
organization and customer organization, "acceptance" may mean different
things. Acceptance may mean complete approval of the customer according
to their own subjective criteria (This is evidence of a deficient
contract in my opinion). On the other hand, acceptance may mean passing
a test given an optimal situation where the developing organization is
able to develop their own acceptance test suite with minimal input from
the customer and conduct all test execution on the developer
organization's own site. More likely, acceptance will lie somewhere
between these two extremes. An expected outcome of acceptance testing
(given that the contract allows this outcome) is that the customer
organization will accept the product pending the fulfillment of some
conditions (like providing fixes for a set of critical errors within a
specified time period). If a product is not considered acceptable under
any condition by the customer organization, then there will likely be
some major rework needed. That is why the software development process
shows failure at this stage causing the flow to regress all of the way
back to architecture design and detailed design.
V-Model Diagram
The acceptance testing
test plan
creation activity should start as the system requirements and system
specificaton artifacts become
relatively stable and mature.
No part of this work should be produced or used without the permission of the authors: Michael Turner and Dr. Sharon A White.