Acceptance Testing
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.
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.