At the culmination of integration testing, software is completely assembled as a package. Interfacing errors have been uncovered and corrected, and a final series of software tests - validation testing- may begin.
Validation can be defined in many ways, but a simple definition is that validation succeeds when software functions in a manner that can be reasonable expected by customer.
What are reasonable expectations?
Reasonable expectations are defined in the software requirement specification - a document that describes all user-visible attributes of the software. The specification contains a section titled "Validation Criteria".
Information contained in that section forms the basis for a validation testing approach.
A test plans outlines the classes of tests to be conducted and a test procedure defines specific test cases that will be used in an attempt to uncover errors in conformity with requirements. Both the plan and procedure are designed to ensure that:
- All functional requirements are satisfied
- All performance requirements are achieved
- Documentation is correct and human-engineered and
- Other requirements like portability, error recovery, and maintainability are met.
An important element of the validation process is a configuration review. The intent of the review is to ensure that all elements of the software configuration have been
properly developed, are catalogued, and have the necessary detail to support the maintenance phase of the software life cycle.
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 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 customer software is used in a natural setting with the developer "Looking over the shoulder" of the user and recording errors and usage problems. Alpha tests are conducted in a controlled environment.
The beta test is conducted at one or more customer sites by the end user(S) of the software . Unlike alpha testing the developer is generally 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/imagined) that are encountered during beta testing and reports these to the developer at regular intervals. Because of problems reported during beta test, the software developer makes modification and then prepares for release of the software product to the entire customer base.
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
QUALITY ASSURANCE PART TWO
QUALITY ASSURANCE SQA
QUALITY OF DESIGN OF TEST CASE
QUALITY MANAGEMENT IN SOFTWARE TESTING
TOOLS FOR QUALITY MANAGEMENT
STATICAL QUALITY ASSURANCE
ISO APPROACH TO QUALITY TESTING