In ihrem Selbstverständnis sind Tests klar abzugrenzen von

• der klassischen Verifikation, welche einen Korrektheitsbeweis benutzt,
• dem einfachen Experiment oder Ausprobieren, in der Fachsprache des Software-Testens als "Try" (engl. für Versuch) genannt. Während in den Naturwissenschaften an ein Experiment höhere Anforderungen gestellt werden als an die Tests, ist dies in der Informatik umgekehrt.

Als Naturwissenschaftler kann man sich einen Test dabei als Experiment vorstellen, das nicht ca. mit den gleichen Bedingungen, sondern auch unterschiedlichen Bedingungen, den Test-Parametern, exakt definiert wiederholbar sein muss.

Es gibt unter anderem folgende Nennungen für spezielle Arten von Tests:

• Funktionale Tests, Abnahmetests, Akzeptanztests und Systemtests dienen dazu, die vom Abnehmer des Programms erwartete Funktionalität des Systems in dem normalen Gebrauch und somit die Akzeptanz beim Abnehmer sicherzustellen.
  • Beim Abnahmetest testet der Auftraggeber, ob das Programm den vereinbarten Anforderungen entspricht.
• Destruktionstests sollen das korrekte (ein definiertes) Verhalten bei unnormalem Gebrauch sicherstellen.
• Modultests, Unit-Tests und Component Tests testen die Funktionalität einzelner kleiner Programmelemente.
• Schnittstellentests testen die Funktionalität bei der Zusammenarbeit voneinander unabhängiger Komponenten unter Einsatz einer einzelnen Komponente und einer Spezifikation, beispielsweise mit Hilfe eines Mocks.
• Interoperabilitätstests testen die Funktionalität bei der Zusammenarbeit voneinander unabhängiger Komponenten unter Einsatz mehrerer Komponenten.
• Integrationstests bzw. Interaktionstests testen die Zusammenarbeit voneinander abhängiger Komponenten.
• Regressionstests bezeichnet man Tests, wenn man sie dazu einsetzt, das Wiederauftreten bereits behobener Bugs zu entdecken.
• Installationstests testen die Funktionalität unter verschiedenen Systemumgebungen.
• Oberflächentests testen die Benutzerschnittstelle des Systems.
• Stresstests sind Tests, die das Verhalten eines Systems unter Ausnahmesituationen analysieren. In dem Engeren Sinne handelt es sich bei Stresstests in der Praxis meist nicht um Tests, sondern um mit Hilfe von Testwerkzeugen erstellte Tries.
• Crashtests sind Stresstests, die versuchen, das System zu dem Absturz zu bringen.
• Lasttests sind Stresstests, die das Systemverhalten unter besonders hohen Speicher- oder CPU-Anforderungen analysieren.
• Performance Tests sind Tests, die ein korrektes Systemverhalten bei bestimmten Speicher- und CPU-Anforderungen sicherstellen sollen.
• Sicherheitstests testen ein System gegen potentielle Sicherheitslücken.
• Zufallstests sind Tests basierend auf Zufallsdaten.

Neben dieser Einordnung anhand des Ablaufs und Umfangs des Tests lassen sich Tests auch nach Wissen über die zu testende Komponente einordnen:

• Black-Box-Tests werden von Programmierern und Testern entwickelt, die keine Kenntnisse über den inneren Aufbau des zu testenden Systems haben. In der Praxis werden Black-Box-Tests meist von speziellen Test-Abteilungen oder Test-Teams entwickelt.
• White-Box-Tests werden von den gleichen Programmierern entwickelt wie das zu testende System selbst. Der den Test entwickelnde Programmierer hat also Kenntnisse über das zu testende System.
• Grey-Box-Tests werden von den gleichen Programmierern entwickelt wie das zu testende System selbst, allerdings nach der Testgesteuerten Programmierung , das heißt vor dem und damit ohne Kenntnisse über das zu testende System.

White-Box-Tests sind kurzfristig kostengünstiger, zeigen in der Praxis allerdings eine äußerst hohe Durchlässigkeit für Fehler.

Black-Box-Tests decken besonders viele Fehler auf, erweisen sich in der Praxis aber zu dem einen als organisatorisch aufwändig und zu dem anderen ab und zu auch als sozial unverträglich wegen eventueller Spannungen zwischen den Test- und den Entwicklungsabteilungen.

Grey-Box-Tests (Testgesteuerte Programmierung ) erweisen sich derzeit in der Praxis als besonders erfolgreich, da sie die Kostengünstigkeit von White-Box-Tests mit der Effizenz von Black-Box-Tests verbinden, sind allerdings außerhalb ihres üblichen Kontext des Extreme Programming oder immerhin der testgesteuerten Programmierung nicht unkritisch zu betrachten, da Software-Entwickler sonst leicht zu White-Box-Tests abdriften und so die Black-Box-Test-artigen Vorteile der Grey-Box-Tests verlieren.

Für den Praxiseinsatz ist die Automatisierung von Tests besonders wichtig. Tests werden in dem Idealfall nach jeder Änderung ausgeführt. Bei nicht automatisierten Tests wäre dabei der für das Durchführen der Tests notwendige Aufwand zu groß, sodass man häufig auf die Tests verzichten würde, was wiederum den Nutzen der Tests stark verringert.

Werkzeuge für das automatisierte Software-Testing sind z.B. JUnit und Cactus für Java.

Siehe auch: Software-Life-Cycle