Академический Документы
Профессиональный Документы
Культура Документы
Early detection of software problems (and time for
the customer or user to plan for possible late
delivery)
Preparation of appropriate test facilities
Early consideration of the user’s needs during
software development
The Customer or User's Responsibilities
in Acceptance Testing
Ensure user involvement in developing system requirements and
acceptance criteria.
Identify interim and final products for acceptance, their
acceptance criteria, and schedule.
Plan how and by whom each acceptance activity will be
performed.
Plan resources for providing information on which to base
acceptance decisions.
Schedule adequate time for buyer staff to receive and examine
products and evaluations prior to acceptance review.
The Customer or User's Responsibilities
in Acceptance Testing (Continued)
Prepare the Acceptance Plan.
Respond to the analyses of project entities before accepting or
rejecting.
Approve the various interim software products against quantified
criteria at interim points.
Perform the final acceptance activities, including formal
acceptance testing, at delivery.
Make an acceptance decision for each product
Acceptance Testing Measures the
Software's “Fit”
System Testing
Performed by developers and/or software testers.
Focuses on determining whether or not the software specifications have
been implemented as specified.
Should be performed before acceptance testing.
Acceptance Testing
Performed by user personnel with possible the assistance of software
testers.
Focuses on input processing, use of the software in the user organization,
and whether or not the specifications meet the true processing needs of
the user.
Three Reasons Why the Software Specified Might not Meet the
User’s True Needs.
The users do not specify the skill level of the people who will be
using the system.
Processing may be specified but turnaround time might not be
specified,
The users may not know that they have to specify the
maintainability attributes of the software.
Roles in Acceptance Testing
Providing the necessary resources, primarily user staff personnel, for acceptance
testing.
Comparing the actual acceptance testing results with the desired acceptance testing
results (NOTE: This may be performed using testing software).
Making decisions as to whether additional work is needed prior to placing the software
in operation, whether the software can be placed in operation with additional work to be
done, or whether the software is fully acceptable and can be placed into production as is.
Acceptance Criteria
In preparation for developing the acceptance criteria,
the user should:
Acquire full knowledge of the application for which the system is intended.
Fully understand the consequences of adding new functions to enhance the
system.
Acceptance Criteria that “Should” be in
the Requirements Specifications
Functionality Requirements
These requirements relate to the business rules that the system must execute.
Performance Requirements
These requirements relate to connections from one component to another component of processing
(e.g., human-machine, machine-module).
Certain security requirements – as required by law - are critical
Should contain pass or fail criteria – the
Acceptance Requirement.
Should cover the parts of the software product in
detail.
Specifying acceptable numeric values or ranges
of values is useful.
Example of Required Information to
Document Acceptance Criteria
Acceptance Criteria Example
Acceptance Test Plan
Example Table of Contents for an Acceptance Test Plan
Project Description
User Responsibilities
Administrative Procedures
Acceptance Description
A use case is a test case which represents how the software will be used
in operation. A use case is built on a business transaction and can be test
data or a test script.
When use cases are developed by clerical people intimately familiar with
the system, they tend to know the type of problems that are typical in the
business system. Thus, they can simulate those unusual events through
use cases that may not be developed during normal system testing.
An individual use case consists of:
Preconditions that set the stage for the series of events that
should occur for the use case
Post-conditions that state the expected outcomes of the
above process
Sequential narrative of the execution of the use case
See “Skill Category 5, Executing the Test Plan,” for
information on the process for preparing use cases.
http://www.agilemodeling.com/artifacts/
useCaseDiagram.htm
Scott W. Ambler
UML 2 Use Case Diagrams
Using System boundary boxes to indicate releases:
Executing the Acceptance Test Plan
Testing the executable software system.
Acceptance Decisions
Typical acceptance decisions include:
Occurs when the user has made the decision to accept
the software.
Usually, means that the the software project is
completed and the developer has no further
obligations.
Usually, some criteria will not be completely
satisfied.