Types of software testing: The Acceptance Test

The acceptance tests are carried out immediately before the release of the product, therefore after having tested the entire system and after the consequent “bug fixing”, or the correction of the defects found. They are typically of black box testing approach, therefore oriented to the verification from the strictly functional point of view of the entire system and are also called quality tests, final tests or release acceptance. Precisely from the name of these tests it is clear that they have more the purpose of giving confidence in the proper functioning of the system, rather than in finding faults.
In fact, the term acceptance is precisely to indicate 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 as a result the success or failure of this operation.
Generally there are 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 close as possible, to the real one, in which the end user will be operating, and must be accompanied by the relevant input data or a formal description of operational activities to be executed and a formal description of the expected results.
Acceptance tests can be performed both by the person who developed the system and by the end users before getting the software.
In the case in which the tests are carried out directly by the end users, one speaks of “User Acceptance Testing”, which has the aim of confirming that the system complies with the requirements mutually agreed between the parties.

Tests performed by the end user or by the customer, besides being a confirmation of the measure of correctness from the functional point of view of the application, often also have a legal value from a contractual point of view, as a 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 identical or very similar to the real one in which the software will normally operate. Alpha testing can be performed by potential end users or by developers inside or outside the development team, but it always occurs internally in the organization that was responsible for building the software.
Precisely for this reason the name of internal acceptance test is sometimes used.
Often after these tests there is a refinement of the software, therefore the component of the identification of the defects is not completely absent, even if usually marginal or in any case not so serious as to threaten the main functionalities.

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 version of the software, or at least not definitive, usually tested by a select group of end users or even by all of them.
These versions tend to be similar to the final software product, but are distributed without any guarantee and may be unstable.

With the development of the internet, beta testing has spread enormously, especially for commercial software products, which are usually distributed on the network for free in beta, so that it can be tested by a large number of users with different hardware and software configurations.
Once a defect or a compatibility problem is found, the user is asked to send a report to the software manufacturer.
When the frequency of the alerts is lowered to an acceptable level, it is time to release the final version of the software product, also called “build version”.