Validation testing begins at the conclusion of integration testing,
When individual components have been exercised, the software is
completely assembled as a package, and interfacing errors have been
uncovered and corrected.
At the validation or system level, the distinction between conventional
software, object-oriented software, and WebApps disappears.
Testing focuses on user-visible actions and user-recognizable output
from the system.
In simple meaning, validation succeeds when software functions
in a manner that can be reasonably expected by the customer.
Validation-Test Criteria
Software validation is achieved through a series of tests that demonstrate
conformity with requirements.
A test plan outlines the classes of tests to be conducted and A test procedure
defines specific test cases that are designed to ensure that
All functional requirements are satisfied,
All behavioral characteristics are achieved,
All content is accurate and properly presented,
All performance requirements are attained,
Documentation is correct, and usability and other requirements are met
(e.g., transportability, compatibility, error recovery, maintainability).
After each validation test case has been conducted, one of two possible
conditions exist:
The function or performance characteristic conforms to specification
and is accepted.
A deviation (Error) from the specification is uncovered and a deficiency list
is created.
Configuration Review :
An important element of the validation processis a configuration review.
The objective of the review is to ensure that all elements of the software
configuration have been properly developed.
The configuration review, sometimes called an audit…
Acceptance Testing :
When custom software is built for one customer, a series of
acceptance tests are conducted to enable the customer to validate
all requirements.
Conducted by the end user rather than software engineers, an
acceptance test can range from an informal “test drive” to a
planned and systematically executed series of tests.
In fact, acceptance testing can be conducted over a period of weeks
or months.
Alpha and Beta Testing :
If software is developed as a product to be used by many customers, it
is impractical to perform formal acceptance tests with each one.
Most software product builders use a process called alpha and beta
testing to uncover errors that only the end user seems able to find.
The alpha test is conducted at the developer’s site by a representative
group of end users.
The software is used in a natural setting with the developer “looking
over the shoulder” of the users and recording errors and usage
problems.
Alpha tests are conducted in a controlled environment.
The beta test is conducted at one or more end-user sites.
Unlike alpha testing, the developer generally is not present.
Therefore, the beta test is a “live” application of the software in an
environment that cannot be controlled by the developer.
The customer records all problems (real or imagined) that are
encountered during beta testing and reports these to the developer
at regular intervals.
As a result of problems reported during beta tests, you make
modifications and then prepare for release of the software product
to the entire customer base.
Introduction: The objective of testing, stated simply, is to find the
greatest possible number of errors with a manageable amount of
effort applied over a realistic time span.
Although this fundamental objective remains unchanged for objectoriented software.
The nature of object-oriented software changes both testing
strategy and testing tactics (Plan).
Unit Testing in the OO Context
When object-oriented software is considered, the concept of the
unit changes. Encapsulation drives the definition of classes and
objects.
This means that each class and each instance of a class packages
attributes (data) and the operations that manipulate these data.
An encapsulated class is usually the focus of unit testing.
However, operations (methods) within the class are the smallest
testable units. Because a class can contain a number of different
operations, and a particular operation may exist as part of a number
of different classes.
Class testing for OO software is the equivalent of unit testing
for conventional software.
Unlike unit testing of conventional software, which tends to
focus on the algorithmic detail of a module and the data that
flow across the module interface,
Class testing for OO software is driven by the operations
encapsulated by the class and the state behavior of the class.
Integration Testing in the OO Context
Different strategies for integration testing of OO systems.
Thread-based testing
use-based testing
Cluster testing
The first, thread-based testing, integrates the set of classes
required to respond to one input or event for the system.
Each thread is integrated and tested individually.
Regression testing is applied to ensure that no side effects occur.
The second integration approach, use-based testing, begins the
construction of the system by testing those classes (called
independent classes) that use very few (if any) server classes.
After the independent classes are tested, the next layer of classes,
called dependent classes, that use the independent classes are
tested.
This sequence of testing layers of dependent classes continues until
the entire system is constructed.
Cluster testing
Cluster testing is one step in the integration testing of OO software.
Here, a cluster of collaborating classes is exercised by designing test
cases that attempt to uncover errors in the collaborations.
