Types of software testing: The Acceptance Test

Acceptance tests are performed immediately before the release of the product, therefore after testing the entire system and after the resulting “bug fixing”, ie the correction of the defects found. They are typical of a black box testing approach, therefore oriented to verification from a strictly functional point of view of the entire system and are also called quality tests, final tests, or release acceptance.

It is precisely from the name of these tests that they are more intended to give confidence in the proper functioning of the system, rather than to find defects.

In fact, the term acceptance indicates that through these tests we want to establish whether the finished product can be accepted as a solution to the real needs of the end-user.

Acceptance testing generally involves the execution of a collection of test cases, each of which exercises a particular operational functionality of the system, returning the success or failure of this operation as a result.

There are generally no degrees of success or failure for this type of test case, but only one or the other result.

Each test case is usually performed in an environment identical, or as similar as possible, to the real one, in which the end-user will operate, and must be accompanied by the relevant input data or a formal description of the operational activities to be performed and a formal description of the expected results.

Acceptance tests can be performed by both system developers and end-users prior to owning the software.

In the event that the tests are carried out directly by the end-users, we speak of “User Acceptance Testing”, which aims to confirm that the system complies with the mutually agreed requirements between the parties.

The tests carried out by the end-user or by the customer, in addition to being a confirmation of the correctness measure from the functional point of view of the application, often also have a legal value from a contractual point of view, as the final moment of the sale or release. of the software.

Two other examples of acceptance tests are alpha and beta testing, also performed on the entire application, in a test environment that is identical or very similar to the real one in which the software normally operates.

Alpha testing can be performed by potential end-users or by developers internal or external to the development team, but it always takes place within the organization that built the software.

For this very reason, the internal acceptance test name is sometimes used.

Often after these tests, a software refinement follows, so the component of identifying defects is not completely absent, even if usually marginal or in any case not so serious as to threaten the main functions.

These tests precede the transition to beta testing, characterized by the release of one or more beta versions of the product outside the organization that developed the software.

A beta version is a trial or non-definitive version of the software, usually tested by a select group of end-users or even all of them.

These versions tend to be similar to the final software product, but are distributed without warranty and can be unstable.

With the development of the internet, beta testing has spread enormously, especially for commercial software products, which are usually distributed free of charge on the net in beta, so that they can be tested by a large number of users with different hardware and software configurations.

Once a defect or compatibility problem is found, the user is asked to send a report to the software manufacturer.

When the frequency of reports is lowered to an acceptable level, it is time for the release of the final version of the software product, also known as the “build version”.