CPSC 333: Validation Testing

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Validation Testing


This material was not covered in lectures in Winter, 1997, and can be considered to be optional.


Introduction

Validation Testing follows system integration and integration testing. The goals of validation testing are

Ideally, these are the same thing! However, it's possible that validation testing might reveal that the system agrees with the requirements specification, but that the requirements specification itself is invalid.

Validation testing is the first testing stage in which tests aren't performed entirely by developers. Instead, many validation tests are conducted by the potential users of the system being developed.

Some validation tests are carefully planned black box tests based on the requirements specification. Others aren't planned at all - instead, they consist of a group of people who will be using the system ``taking it for a test drive,'' trying to use it to solve the problems they'll encounter in practice.

Validation Testing for a Small Group of Users

Consider a system that will have a fairly small group of users.

For example, this might be a ``special purpose'' or ``customized'' system being developed for one organization by a contractor.

In this case, acceptance tests are used for validation testing. Ideally, these are tests performed by all of the potential users of the system. Tests are generally performed at the developers' site, with system developers present when tests are performed.

While developers won't try to solve problems (that are discovered by these tests) immediately, they will be aware of, and make note of, these problems as they're detected by the users conducting the tests.

Validation Testing for a Large Group of Users

Alternatively, the proposed system might have a much larger group of users - far too many for all of them to be involved in ``acceptance tests.''

This scenario is likely if general purpose commercial software is being developed.

In this case, two testing stages will be used - so that developers can be closely involved for at least part of the testing, but so that a large group of potential users can be involved as well.

Alpha Testing

Initially, a small group of users is involved in testing of the system. As for acceptance testing, tests are generally conducted at the developers' site, in the presence of developers, so that developers are available to suggest tests, and answer questions, and so that developers are aware of problems as soon as they are discovered.

Beta Testing

Following alpha testing, the software is released for trial use to a much larger group of users. During beta testing, the software is used at users' sites, without developers present. It is up to users to log and report problems as they are encountered; error reports are sent to developers on a regular basis.

Change in Terminology

Recently, ``alpha releases'' of software have appeared in FTP archives. Since these are being made widely available, they clearly aren't to be tested under the conditions described above for ``alpha testing.'' It seems that an ``alpha release'' of software now means software in which major subsystems might be missing completely (so that the software provides only some of the functions planned for it). ``Beta releases'' of software still typically follow alpha releases; these are generally functionally complete, but (as in software under ``beta testing'') they aren't considered ready for ``delivery.''

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Validation Testing


Department of Computer Science
University of Calgary

Office: (403) 220-5073
Fax: (403) 284-4707

eberly@cpsc.ucalgary.ca