VALIDATION TESTING

Validation testing begins at the culmination 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 web apps disappears. Testing focuses on user–visible actions and user–recognizable output from the system.

Validation can be defined in many ways, but a simple definition is that 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 behavioural 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 exists: (1) The function or performance characteristic conforms to specification and  is accepted or (2) a deviation from specification is uncovered and deficiency list is created

Configuration review

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 cataloged, and have the necessary detail support activities. The configuration review, sometimes called an audit.

Alpha and Beta testing

It is virtually impossible for a software developer to foresee how the customer will really use a program. Instructions for use  may be misinterpreted; strange combinations of data may be regularly used; output that seemed clear to the tester may be unintelligible to a user in the field.

When custom software is built for one customer, a series of acceptance tests are conducted to enable the customer to validate all required. Conducted by the end user rather than software engineers.

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 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 the beta tests, you make modifications and then prepare for release of the software product to the customer base.

A variation on beta testing, called customer acceptance testing is sometimes performed when custom software is delivered to a customer under contract.