Testphasen im Softwareentwicklungsprozess

MPDL

In diesem Dokument werden die gängigen Testphasen, die im Laufe eines Softwareentwicklungsprozesses durchlaufen werden, kurz beschrieben.

Der Text stammt aus dem Lehrplan "ISTQB Foundation Level" S. 24 ff. (gekürzt und formale Änderungen)

=Komponententest (MPDL: "Entwicklertest")=

Der Komponententest (auch bekannt als Unit-, Modul- oder Programmtest) hat zum Ziel, Software, die separat getestet werden kann (z.B. Module, Programme, Objekte, Klassen, etc.), zu prüfen und darin vorhandene Fehler zu finden.

Der Komponententest kann das Testen funktionaler wie auch nicht-funktionaler Aspekte umfassen, so etwa das Testen der Ressourcenverwendung (z.B. Suche nach Speicherengpässen), Robustheitstest oder auch struktureller Test (z.B. Entscheidungsüberdeckung). Testfälle werden von Entwicklungsdokumenten wie einer Komponentenspezifikation, dem Softwareentwurf oder dem Datenmodell abgeleitet.

In der Praxis sind oft die für den Code verantwortlichen Entwickler an den Komponententests beteiligt. Dabei werden die gefundenen Fehlerzustände häufig sofort korrigiert und gar nicht erst formell behandelt.

=Integrationstest=

Der Integrationstest prüft die Schnittstellen zwischen Komponenten und die Interaktionen zwischen verschiedenen Teilen eines Systems, beispielsweise zum Betriebssystem, Dateisystem, zur Hardware, und er prüft die Schnittstellen zwischen Systemen.

Ein Komponentenintegrationstest prüft das Zusammenspiel der Softwarekomponenten und wird nach dem Komponententest durchgeführt.

Systematische Integrationsstrategien können auf der Systemarchitektur (z.B. Top-Down und Bottom-Up), funktionalen Aufgaben, Transaktionsverarbeitungssequenzen oder anderen Aspekten des Systems oder seiner Komponenten basieren. Das Testen spezieller nicht-funktionaler Eigenschaften (z.B. Performanz) kann im Integrationstest ebenso enthalten sein, wie funktionale Tests.

=Systemtest (MPDL: "QA-Test")=

Der Systemtest beschäftigt sich mit dem Verhalten eines Gesamtsystems/-produkts. Beim Systemtest sollte die Testumgebung mit der finalen Ziel- oder Produktivumgebung so weit wie möglich übereinstimmen, um das Risiko umgebungsspezifischer Fehler, die nicht während des Testens gefunden werden, zu minimieren.

Systemtests können Tests einschließen, die auf einer Risikoanalyse basieren und/oder auf Anforderungsspezifikationen, Geschäftsprozessen, Anwendungsfällen oder anderen abstrakten textuellen Beschreibungen oder Modellen des Systemverhaltens.

Funktionale Anforderungen werden im Systemtest zunächst mit spezifikationsorientierten Testentwurfsverfahren (Black-Box-Testentwurfsverfahren) getestet. Systemtests werden oft durch unabhängige Testteams durchgeführt.

=Abnahmetest (MPDL: "Peer Review Test" / "Endnutzertest")=

Das Ziel des Abnahmetests besteht darin, Vertrauen in das System oder in spezifische nicht-funktionale Eigenschaften eines Systems zu gewinnen. Das Finden von Fehlerzuständen ist nicht das Hauptziel beim Abnahmetest. Abnahmetests können die Bereitschaft eines Systems für den Einsatz und die Nutzung bewerten, obwohl sie nicht notwendigerweise die letzte Teststufe darstellen.

Unter anderem gibt es folgende typische Ausprägungen des Abnahmetests:

Er prüft die Tauglichkeit eines Systems zum Gebrauch durch Anwender bzw. Kunden.
 * Anwender-Abnahmetest (MPDL: „Endnutzertest“)

Hersteller kommerzieller oder Standardsoftware wollen oft Feedback von potenziellen oder existierenden Kunden erhalten, bevor sie ein Produkt kommerziell zum Kauf anbieten. Der Alpha-Test wird am Herstellerstandort durchgeführt, nicht jedoch vom Entwicklungsteam. Der Beta- (oder Feldtest) wird von Kunden oder potenziellen Kunden an den Kundenstandorten durchgeführt.
 * Alpha- und Beta-Test (MPDL: „Peer Review Test“)