Validation activities test if a function required and anticipated by the clients exists in software. In this case, if the anticipated function or feature is not present it is obviously linked to the defluxion of anticipated behavior, or linked to a software failure. Nevertheless, this is a special sub-class of failures, where an anticipated function is non-existent.
When an unexpected function is present, it can be considered as a failure. The reason is that a client is hardly being enthusiastic to pay for a function that is not required.
And even in the case, it is free the client might be anxious about a possible interference with other critical needs.
Consequently, different quality assurance activities linked with such types of failures directly observable by software users may be considered as validation activities.
There are some examples of quality assurance activities that can be classified as validation activities:
- Acceptance testing and beta testing, where the main attention is paid to the estimation of software acceptance or performance by users
- System testing, where the main attention is paid to the overall set of system functions to be provided to users
- Usage-based statistical testing, where the operational environment by target users is simulated at the time of software testing before product release
- Software safety assurance activities, where the main attention is paid to providing the expected accident-free operations or reducing accident harm when an accident is inevitable
- Software fault tolerance, where the main attention is paid to providing continued service anticipated by clients even when local troubles subsist
Even if a specific software quality assurance activity is not directly operating with the above kind of failures, if the purpose is to identify or avert faults that are linked to such failures, the specific activity in question can also be classified as a validation activity.