Unit testing

Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level.

In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors.

These type of tests are usually written by developers as they work on code (white-box style), to ensure that the specific function is working as expected.

One function might have multiple tests, to catch corner cases or other branches in the code.

Unit testing alone cannot verify the functionality of a piece of software, but rather is used to assure that the building blocks the software uses work independently of each other.

Unit testing is also called component testing.

Integration testing

Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design.

Software components may be integrated in an iterative way or all together (“big bang”).

Normally the former is considered a better practice since it allows interface issues to be localised more quickly and fixed.

Integration testing works to expose defects in the interfaces and interaction between integrated components (modules).

Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system.

System testing

System testing tests a completely integrated system to verify that it meets its requirements.

System integration testing

System integration testing verifies that a system is integrated to any external or third-party systems defined in the system requirements.

Regression testing

Regression testing focuses on finding defects after a major code change has occurred.

Specifically, it seeks to uncover software regressions, or old bugs that have come back.

Such regressions occur whenever software functionality that was previously working correctly stops working as intended.

Typically, regressions occur as an unintended consequence of program changes, when the newly developed part of the software collides with the previously existing code.

Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged.

The depth of testing depends on the phase in the release process and the risk of the added features.

They can either be complete, for changes added late in the release or deemed to be risky, to very shallow, consisting of positive tests on each feature, if the changes are early in the release or deemed to be of low risk.

Acceptance testing

Acceptance testing can mean one of two things:

A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression.

Acceptance testing performed by the customer, often in their lab environment on their own hardware, is known as user acceptance testing (UAT). Acceptance testing may be performed as part of the hand-off process between any two phases of development.

Alpha testing

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers’ site.

Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.

Beta testing

Beta testing comes after alpha testing and can be considered a form of external user acceptance testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team.

The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.