Softwaretest – Wikipedia

Ein Softwaretest prüft und bewertet Software auf Erfüllung der für ihren Einsatz definierten Anforderungen und misst ihre Qualität. Die gewonnenen Erkenntnisse werden zur Erkennung und Behebung von Softwarefehlern genutzt. Tests während der Softwareentwicklung dienen dazu, die Software möglichst fehlerfrei in Betrieb zu nehmen.

Diese für eine einzelne Testmaßnahme verwendete Bezeichnung wird auch – im Sinn von „Testprozess“ – für mehrere oder die Gesamtheit von Maßnahmen zur Überprüfung der Softwarequalität (inkl. Planung, Vorbereitung, Steuerung, Durchführung, Dokumentation usw.) verwendet; siehe auch Definitionen.

Den Nachweis, dass keine Fehler (mehr) vorhanden sind, kann das Softwaretesten nicht erbringen. Es kann lediglich fallibilistisch feststellen, dass bestimmte Testfälle erfolgreich waren. Edsger W. Dijkstra schrieb hierzu: „Program testing can be used to show the presence of bugs, but never show their absence!“ (Das Testen von Programmen kann die Existenz von Fehlern zeigen, aber niemals deren Nichtvorhandensein). Der Grund ist, dass alle Programmfunktionen und auch alle möglichen Werte in den Eingabedaten in allen ihren Kombinationen getestet werden müssten – was (außer bei sehr einfachen Testobjekten) praktisch nicht möglich ist. Aus diesem Grund beschäftigen sich verschiedene Teststrategien und -konzepte mit der Frage, wie mit einer möglichst geringen Anzahl von Testfällen eine große Testabdeckung zu erreichen ist.

Pol, Koomen, Spillner^[1] erläutern 'Testen' wie folgt: „Tests sind nicht die einzige Maßnahme im Qualitätsmanagement der Softwareentwicklung, aber oft die letztmögliche. Je später Fehler entdeckt werden, desto aufwändiger ist ihre Behebung, woraus sich der Umkehrschluss ableitet: Qualität muss (im ganzen Projektverlauf) implementiert und kann nicht 'eingetestet' werden.“ Und: „Beim Testen in der Softwareentwicklung wird i. d. R. eine mehr oder minder große Fehleranzahl als 'normal' unterstellt oder akzeptiert. Hier herrscht ein erheblicher Unterschied zur Industrie: Dort werden im Prozessabschnitt 'Qualitätskontrolle' oft nur noch in Extremsituationen Fehler erwartet.“

Es gibt unterschiedliche Definitionen für den Softwaretest:

Nach ANSI/IEEE Std. 610.12-1990^[2] ist das Testen (engl. ‚Testing‘) „the process of operating a system or component under specified conditions, observing or recording the results and making an evaluation of some aspects of the system or component.“

Eine andere Definition liefert Ernst Denert^[3], wonach der „Test […] der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen“ ist.

Eine weitergehende Definition verwenden Pol, Koomen und Spillner^[1]: Unter Testen versteht man den Prozess des Planens, der Vorbereitung und der Messung, mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen und den Unterschied zwischen dem tatsächlichen und dem erforderlichen Zustand aufzuzeigen. Bemerkenswert hierbei: Als Messgröße gilt 'der erforderliche Zustand', nicht nur die (möglicherweise fehlerhafte) Spezifikation.

'Testen' ist ein wesentlicher Teil im Qualitätsmanagement von Projekten der Softwareentwicklung.

Im September 2013 wurde die Norm ISO/IEC/IEEE 29119 Software Testing veröffentlicht, die international erstmals viele (ältere) nationale Normen des Softwaretestens, wie z. B. die IEEE 829, zusammenfasst und ersetzt. Die Normreihe ISO/IEC 25000 ergänzt die Seite des Software-Engineering als Leitfaden für (die gemeinsamen) Qualitätskriterien und ersetzt die Norm ISO/IEC 9126.

„Kein umfangreiches System ist fehlerfrei.“^[4] Jedes Softwaresystem von genügender Komplexität weist Fehler auf. Diesen können neben vielen anderen Fehlergründen zum Beispiel nicht bedachte Ausnahmesituationen oder nicht berücksichtigte Randbedingungen zugrunde liegen.

In der Softwareentwicklung wird der Test verwendet um den Verlust von Geld, Zeit, Menschenleben oder anderen materiellen oder immateriellen Gütern, die durch mangelhafte Qualität eines Softwaresystems verursacht werden, zu minimieren.^[4] Durch das systematische Testen einer Software während der Entwicklung können Fehler früh festgestellt werden, was deren Fehlerkosten nach der Rule of ten minimiert.^[5]

Globales Ziel des Softwaretestens ist das Messen der Qualität des Softwaresystems. Dabei dienen definierte Anforderungen als Prüfreferenz, mittels derer ggf. vorhandene Fehler aufgedeckt werden. ISTQB: Der Wirkung von Fehlern (im produktiven Betrieb) wird damit vorgebeugt.

Ein Rahmen für diese Anforderungen können die Qualitätsparameter gem. ISO/IEC 9126 sein, denen jeweils konkrete Detailanforderungen z. B. zur Funktionalität, Bedienbarkeit, Sicherheit usw. zugeordnet werden können. Im Besonderen ist auch die Erfüllung gesetzlicher und/oder vertraglicher Vorgaben nachzuweisen.

Die Testergebnisse (die über verschiedene Testverfahren gewonnen werden) tragen zur Beurteilung der realen Qualität der Software bei – als Voraussetzung für deren Freigabe zum operativen Betrieb. Das Testen soll Vertrauen in die Qualität der Software schaffen^[1].

Individuelle Testziele: Da das Softwaretesten aus zahlreichen Einzelmaßnahmen besteht, die i. d. R. über mehrere Teststufen hinweg und an vielen Testobjekten ausgeführt werden, ergeben sich individuelle Testziele für jeden einzelnen Testfall und für jede Teststufe – wie z. B. Rechenfunktion X in Programm Y getestet, Schnittstellentest erfolgreich, Wiederinbetriebnahme getestet, Lasttest erfolgreich, Programm XYZ getestet usw.

Die Einordnung der Teststufen (zum Teil auch Testzyklen genannt) folgt gemäß V-Modell dem Entwicklungsstand des Systems. Ihr Inhalt orientiert sich dabei an den Entwicklungsstufen von Projekten. Dabei wird in jeder Teststufe (rechte Seite im 'V') gegen die Systementwürfe und Spezifikationen der zugehörigen Entwicklungsstufe (linke Seite) getestet, d. h., die Testziele und Testfälle basieren auf den jeweiligen Entwicklungsergebnissen. Dieses Vorgehensprinzip ist allerdings nur anwendbar, wenn evtl. in späteren Entwicklungsstufen vorgenommene Änderungen in den älteren Spezifikationen nachgeführt wurden.

In der Realität werden diese Ausprägungen, abhängig von der Größe und Komplexität des Software-Produkts, weiter untergliedert. So könnten beispielsweise die Tests für die Entwicklung von sicherheitsrelevanten Systemen in der Transportsicherungstechnik folgendermaßen untergliedert sein: Komponententest auf dem Entwicklungsrechner, Komponententest auf der Ziel-Hardware, Produkt-Integrationstests, Produkttest, Produkt-Validierungstests, System-Integrationstest, Systemtest, System-Validierungstests, Feldtests und Akzeptanztest.

Die nachfolgend beschriebenen Teststufen sind in der Praxis oft nicht scharf voneinander abgegrenzt, sondern können, abhängig von der Projektsituation, fließend oder über zusätzliche Zwischenstufen verlaufen. So könnte zum Beispiel die Abnahme des Systems auf der Grundlage von Testergebnissen (Reviews, Testprotokolle) von Systemtests erfolgen.

Der Modultest, auch Komponententest oder Unittest genannt, ist ein Test auf der Ebene innerer, abgrenzbarer Einzelteile der Software wie beispielsweise Module, Unterprogramme, Units oder Klassen. Testziel dieser häufig durch den Softwareentwickler selbst durchgeführten Tests ist der Nachweis der technischen Lauffähigkeit und korrekter (Teil-)Ergebnisse. Mittels Unittests können im Schnitt 30 Prozent der Fehler erkannt werden;^[6] bei der Verwendung von testgetriebener Entwicklung 45 %.^[7] Auf Grund der Tatsache, dass Unittests die Fehler bereits während der Entwicklungsphase erkennen, sind die durch Unittests vermiedenen Fehlerkosten gemäß der Rule of 10^[5] um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.

Der Integrationstest bzw. Interaktionstest testet die Zusammenarbeit voneinander abhängiger Komponenten. Der Testschwerpunkt liegt auf den Schnittstellen der beteiligten Komponenten und soll korrekte Ergebnisse über komplette Abläufe hinweg nachweisen. Mittels Integrationstests können im Schnitt 35 % der Fehler erkannt werden.^[6]

Der Systemtest ist die Teststufe, bei der das gesamte System gegen die gesamten Anforderungen (funktionale und nicht-funktionale Anforderungen) getestet wird. Gewöhnlich findet der Test auf einer Testumgebung statt und wird mit Testdaten durchgeführt. Die Testumgebung soll die Produktivumgebung des Kunden simulieren, d. h. ihr möglichst ähnlich sein. In der Regel wird der Systemtest durch die realisierende Organisation durchgeführt. Mittels Systemtests können im Schnitt 40 % der Fehler erkannt werden.^[6]

Ein Abnahmetest, Verfahrenstest, Akzeptanztest oder auch User Acceptance Test (UAT) ist das Testen der gelieferten Software durch den Kunden. Der erfolgreiche Abschluss dieser Teststufe ist meist Voraussetzung für die rechtswirksame Übernahme der Software und deren Bezahlung. Dieser Test kann unter Umständen (z. B. bei neuen Anwendungen) bereits auf der Produktionsumgebung mit Kopien aus Echtdaten durchgeführt werden.

Besonders für System- und Abnahmetests wird das Blackbox-Verfahren angewendet, d. h., der Test orientiert sich nicht am Code der Software, sondern nur am Verhalten der Software bei spezifizierten Vorgängen (Eingaben des Benutzers, Grenzwerte bei der Datenerfassung etc.).

Die Anzahl der Akzeptanztests sollte sich am Umfang der Software orientieren.^[8]

Pol, Koomen und Spillner^[1] beschreiben im Kap. 8.1 ‚TMap‘ ein Vorgehen nach einem Phasenmodell. Sie nennen dieses Vorgehen Testprozess, bestehend aus den Testphasen Testvorbereitung, Testspezifikation, Testdurchführung und -Auswertung, Testabschluss. Parallel sieht der Testprozess die Rahmenfunktionen Planung & Verwaltung vor. Das Vorgehen sei generisch, d. h., es wird – jeweils nach Erfordernis – für unterschiedliche Ebenen angewendet, für das Gesamtprojekt, für jede Teststufe und letztlich je Testobjekt und Testfall.

Bei anderen Autoren oder Instituten finden sich zum Teil andere Gruppierungen und andere Bezeichnungen, die aber inhaltlich nahezu identisch sind. Z. B. wird bei ISTQB der Testprozess mit folgenden Hauptaktivitäten definiert:^[9] Testplanung und Steuerung, Testanalyse und Testentwurf, Testrealisierung und Testdurchführung, Bewertung von Endekriterien und Bericht, Abschluss der Testaktivitäten. Die einzelnen Aktivitäten und deren Reihenfolge, die (im Testprozess festgelegt) für die einzelnen Testobjekte auszuführen sind – ggf. mehrfach, z. B. bei Testwiederholung/Regressionstest – nennt ISTQB ‚Testzyklus‘.

Testaktivitäten werden (nach Pol, Koomen und Spillner^[1]) rollenspezifisch zu sog. Testfunktionen zusammengefasst: Testen, Testmanagement, Methodische Unterstützung, Technische Unterstützung, Funktionale Unterstützung, Verwaltung, Koordination und Beratung, Anwendungsintegrator, TAKT-Architekt und TAKT-Ingenieur (bei Einsatz von Testautomatisierung; TAKT = Testen, Automatisierung, Kenntnisse, Tools). Diese Funktionen (Rollen) haben Schwerpunkte in bestimmten Testphasen; sie können im Projekt selbst eingerichtet sein oder über spezialisierte Organisationseinheiten einbezogen werden.

Personenbezogen können u. a. die folgenden Rollen beim Testen unterschieden werden:

• Testmanager (Führung): Der Testmanager entwickelt die Teststrategie, plant die Ressourcen und dient als Ansprechperson für Projektleitung und Management. Wichtige Charakterzüge sind dabei Verlässlichkeit und Integrität.
• Testarchitekt, Testengineer: Der Testengineer unterstützt den Testmanager bei der Entwicklung der Teststrategie. Zudem ist er für die optimale Auswahl der Testmethoden und Testwerkzeuge zuständig. Die Planung und Entwicklung einer projektspezifischen Testinfrastruktur liegt auch in seinem Aufgabenbereich.
• Testanalyst: Der Testanalyst bestimmt die nötigen Testsszenarien, indem er sie aus den Anforderungen ableitet. Zudem definiert er welche Testdaten notwendig sind.
• Testdatenverantwortlicher: Der Testdatenverantwortlicher kümmert sich um die Beschaffung und Aktualität der Testdaten. Er arbeitet eng mit dem Testanalyst zusammen. Diese Rolle wird meist unterschätzt, aber ohne die richtigen Testdaten, ist die Aussage der Testfälle nutzlos.
• Tester (Fachperson): Der Tester hat die Aufgabe die Tests zuverlässig und exakt auszuführen. Zudem soll er die Testergebnisse präzise und wertfrei dokumentieren. Bei der Fehlersuche kann er die Testanalysten und IT-Spezialisten unterstützen. Allgemein wird oft diese Rolle als Tester angesehen, wobei die anderen Rollen vergessen werden.

Ergebnis dieser i. d. R. parallel zur Softwareentwicklung stattfindenden Phase ist i. W. der Testplan. Er wird für jedes Projekt erarbeitet und soll den gesamten Testprozess definieren. In TMap wird dazu ausgeführt: Sowohl die zunehmende Bedeutung von IT-Systemen für Betriebsprozesse als auch die hohen Kosten des Testens rechtfertigen einen optimal verwaltbaren und strukturierten Testprozess. Der Plan kann und soll je Teststufe aktualisiert und konkretisiert werden, sodass die Einzeltests im Umfang zweckmäßig und effizient ausgeführt werden können.

Inhalte im Testplan sollten z. B. folgende Aspekte sein: Teststrategie (Testumfang, Testabdeckung, Risikoabschätzung); Testziele und Kriterien für Testbeginn, Testende und Testabbruch – für alle Teststufen; Vorgehensweise (Testarten); Hilfsmittel und Werkzeuge zum Testen; Dokumentation (Festlegen der Art, Struktur, Detaillierungsgrad); Testumgebung (Beschreibung); Testdaten (allgemeine Festlegungen); Testorganisation (Termine, Rollen), alle Ressourcen, Ausbildungsbedarf; Testmetriken; Problemmanagement.

Aufbauend auf der Testplanung werden die dort festgelegten Sachverhalte zur operativen Nutzung vorbereitet und zur Verfügung gestellt.

Beispiele für einzelne Aufgaben (global und je Teststufe): Bereitstellen der Dokumente der Testbasis; Verfügbar machen (z. B. Customizing) von Werkzeugen für das Testfall- und Fehlermanagement; Aufbauen der Testumgebung(en) (Systeme, Daten); Übernehmen der Testobjekte als Grundlage für Testfälle aus der Entwicklungsumgebung in die Testumgebung; Benutzer und Benutzerrechte anlegen; ...
Beispiele für Vorbereitungen (für Einzeltests): Transfer / Bereitstellung von Testdaten bzw. Eingabedaten in die Testumgebung(en).

Hier werden alle Festlegungen und Vorbereitungen getroffen, die erforderlich sind, um einen bestimmten Testfall (unterscheide logischer und konkreter Testfall) ausführen zu können.

Beispiele für einzelne Aktivitäten: Testfallfindung und Testfalloptimierung (orientiert an Testzielen und ggf. Testpfad-Kategorien); Beschreiben je Testfall (was genau ist zu testen); Vorbedingungen (inkl. Festlegen von Abhängigkeiten zu anderen Testfällen); Festlegen und Erstellen der Eingabedaten; Festlegungen zum Testablauf und zur Testreihenfolge; Festlegen Soll-Ergebnis; Bedingung(en) für 'Test erfüllt'; ...

Bei dynamischen Tests wird dazu das zu testende Programm ausgeführt, in statischen Tests ist es Gegenstand analytischer Prüfungen.

Beispiele für einzelne Aktivitäten: Auswählen der zu testenden Testfälle; Starten des Prüflings – manuell oder automatisch; Bereitstellen der Testdaten und des Ist-Ergebnisses zur Auswertung; Umgebungsinformationen für den Testlauf archivieren, ...

Weitere Anmerkung: Ein Testobjekt sollte nicht vom Entwickler selbst, sondern von anderen, wenn möglich unabhängigen, Personen getestet werden.

Die Ergebnisse aus durchgeführten Tests (je Testfall) werden überprüft. Dabei wird das Ist-Ergebnis mit dem Soll-Ergebnis verglichen und anschließend eine Entscheidung über das Testergebnis (ok oder Fehler) herbeigeführt.

• Bei Fehler: Klassifizierung (z. B. nach Fehlerursache, Fehlerschwere etc., siehe auch Fehlerklassifizierung), angemessene Fehlerbeschreibung und -Erläuterung, Überleitung ins Fehlermanagement; Testfall bleibt offen
• Bei OK: Testfall gilt als erledigt
• Für alle Tests: Dokumentation, Historisieren / Archivieren von Unterlagen

Abschluss-Aktivitäten finden auf allen Testebenen statt: Testfall, Testobjekt, Teststufe, Projekt. Der Status zum Abschluss von Teststufen wird (z. B. mit Hilfe von Teststatistiken) dokumentiert und kommuniziert, Entscheidungen sind herbeizuführen und Unterlagen zu archivieren. Grundsätzlich ist dabei zu unterscheiden nach:

• Regel-Abschluss = Ziele erreicht, nächste Schritte einleiten
• Alternativ möglich: Teststufe ggf. vorzeitig beenden oder unterbrechen (aus diversen, zu dokumentierenden Gründen); in Zusammenarbeit mit dem Projektmanagement

In kaum einer Disziplin der Softwareentwicklung hat sich, der Komplexität der Aufgabe ‚Testen‘ entsprechend, eine derart große Vielfalt an Begriffen gebildet wie beim Softwaretest. Dies trifft besonders auch für die Bezeichnungen zu, mit denen Testarten/Testvarianten benannt werden.

Sie leiten sich in der Regel aus den unterschiedlichen Situationen ab, in denen sie ausgeführt werden sowie aus den Testzielen, auf die sie ausgerichtet sind. Dadurch ergibt sich eine Vielzahl an Begriffen. Dieser Vieldimensionalität entsprechend können für einen konkreten Test die Bezeichnungen mehrerer Testarten zutreffen. Beispiel: Ein Entwicklertest kann gleichzeitig ein dynamischer Test, Blackbox-Test, Fehlertest, Integrationstest, Äquivalenzklassentest, Batchtest, Regressionstest etc. sein.

In Literatur und Praxis werden diese Bezeichnungen meist nur teilweise benutzt, zum Teil auch mit in Details abweichenden Bedeutungen. So könnten im praktischen Einsatz bestimmte Tests (zum Beispiel) einfach als Funktionstest bezeichnet werden – und nicht als Fehlertest, Batchtest, High-Level-Test etc. Die Testeffizienz wird hierdurch nicht beeinträchtigt – wenn die Tests ansonsten zweckmäßig geplant und ausgeführt werden. Durchaus im Sinn effizienter Testprozesse ist es dabei, mehrere Testziele mit nur einem Testfall abzudecken, z. B. dabei die Benutzeroberfläche, eine Rechenformel, korrekte Wertebereichsprüfungen und die Datenkonsistenz zu prüfen.

Ein Mittel zum Verständnis dieser Begriffsvielfalt ist die nachfolgend angewendete Klassifikation – bei der Testarten nach unterschiedlichen Kriterien gegliedert, dazu passende Testarten aufgeführt und ihre Testziele kurz erläutert werden.

Als analytische Maßnahmen werden Softwaretests definiert, die erst nach Erstellung des Prüfgegenstandes durchgeführt werden können. Liggesmeyer^[10] klassifiziert diese Testmethoden folgendermaßen (verkürzt und z. T. kommentiert):

Statischer Test (Test ohne Programmausführung)

• Review
• Statische Code-Analyse, auch Formale Verifikation

Dynamischer Test (Test mit Programmausführung)

• Strukturorientierter Test
  • Kontrollflussorientiert (Maß für die Überdeckung des Kontrollflusses)
    • Anweisungs-, Zweig-, Bedingungs- und Pfadüberdeckungstests
  • Datenflussorientiert (Maß für die Überdeckung des Datenflusses)
    • Defs-/Uses Kriterien, Required k-Tupels-Test, Datenkontext-Überdeckung
• Funktionsorientierter Test (Test gegen eine Spezifikation)
  • Funktionale Äquivalenzklassenbildung, Zustandsbasierter Test, Ursache-Wirkung-Analyse (z. B. mittels Ursache-Wirkungs-Diagramm), Syntaxtest, Transaktionsflussbasierter Test, Test auf Basis von Entscheidungstabellen
  • Positivtest (versucht die Anforderungen zu verifizieren) und Negativtest (prüft die Robustheit einer Anwendung)
• Diversifizierender Test (Vergleich der Testergebnisse mehrerer Versionen)
  • Regressionstest, Back-To-Back-Test, Mutationen-Test
• Sonstige (nicht eindeutig zuzuordnen, bzw. Mischformen)
  • Bereichstest bzw. Domain Testing (Verallgemeinerung der Äquivalenzklassenbildung), Error guessing, Grenzwertanalyse, Zusicherungstechniken

Den analytischen Maßnahmen, bei denen Testobjekte ‚geprüft‘ werden, gehen die sog. konstruktiven Maßnahmen voraus, die bereits im Verlauf der Software-Erstellung zur Qualitätssicherung betrieben werden. Beispiele: Anforderungsmanagement, Prototyping, Review von Pflichtenheften.

Weiterhin sind von den Prüftechniken die Spezifikationstechniken zu unterscheiden: Sie bezeichnen keine Testarten, mit denen Testobjekte aktiv geprüft werden, sondern nur die Verfahren, nach denen die Tests vorbereitet und spezifiziert werden.

Beispielbezeichnungen sind Äquivalenzklassentest und Überdeckungstest; Testfälle werden nach diesen Verfahren identifiziert und spezifiziert, konkret überprüft jedoch z. B. in einem Integrationstest, Batchtest, Sicherheitstest etc.

Debugging

für einzelne Codeteile: Überprüfen des Programmcodes unter schrittweiser oder abschnittsweiser Kontrolle und ggf. Modifikation des Entwicklers.

Modultest, Unittest oder Komponententest

Testen kleinst-möglicher testbarer Funktionalitäten isoliert von anderen; gilt auch als eine Teststufe.

Integrationstest

Test der Funktionalität bei der Zusammenarbeit voneinander abhängiger Komponenten; wird auch Interoperabilitätstest genannt; gilt auch als eine Teststufe.

Systemtest

Teststufe mit Tests über das gesamte System.

Schnittstellentest

Testen ob die Schnittstellen zwischen sich gegenseitig aufrufenden Komponenten korrekt (d. h. insbesondere bzgl. der möglichen Parameter-Kombinationen) implementiert sind; meist gem. der Spezifikation, beispielsweise mit Hilfe von Mock-Objekten.

Batchtest / Dialogtest

werden Tests von Stapelprogrammen bzw. Tests für Dialogprogramme genannt.

Web-Test

Test von Internet- oder Intranet-Funktionen; auch Browsertest genannt.

Hardwaretest

Testen konkreter, Hardwarekomponenten betreffender Last- und anderer Kriterien - wie Netzlast, Zugriffszeit, Parallelspeichertechniken etc.

Die jeweilige Testart testet ...

• Geschäftsprozesstest: ... das Zusammenwirken von Programmteilen eines Geschäftsprozesses.

ähnlich wie End-to-End Test: ... Funktionen des Systems über alle Schritte hinweg (z. B. von der Benutzerschnittstelle bis zur Datenbank).

• Verhaltenstest (behaviour test): ... die Anwendung aus der Sicht von Benutzern; bei^[11] werden unterschieden:

• Featuretest (oder Funktionstest): ... eine einzelne vom Benutzer ausführbare Funktion.
• Fähigkeitstest (englisch: capability test): ... ob eine bestimmte Benutzertätigkeit i. Z. mit den getesteten Funktionen ausgeführt werden kann.
• Akzeptanztest (auch User Akzeptanztest UAT): ... ob die Software vor allem hinsichtlich ihrer Benutzeroberfläche definierte Anforderungen/Erwartungen erfüllt.

• Oberflächentest: ... die Benutzerschnittstellen des Systems (z. B. Verständlichkeit, Anordnung von Informationen, Hilfefunktionen); für Dialogprogramme auch GUI-Test oder UI-Test genannt.

• Datenkonsistenztest: ... Auswirkung der getesteten Funktion auf die Korrektheit von Datenbeständen (Testbezeichnungen: Datenzyklustest, Wertebereichstest, Semantiktest, CRUD-Test)
• Wiederinbetriebnahmetest: ... ob ein System nach einem Abschalten oder Zusammenbruch (z. B. ausgelöst durch einen Stresstest) wieder in Betrieb genommen werden kann.
• Installationstest: ... Routinen zur Softwareinstallation, ggfs. in verschiedenen Systemumgebungen (z. B. mit verschiedener Hardware oder unterschiedlichen Betriebssystemversionen)
• Stresstest: ... das Verhalten eines Systems unter Ausnahmesituationen.
• Crashtest: ist ein Stresstest, der versucht, das System zum Absturz zu bringen.
• Lasttest: ... das Systemverhalten unter besonders hohen Speicher-, CPU-, o. ä. -Anforderungen. Besondere Arten von Last-Tests können Multi-User-Tests (viele Anwender greifen auf ein System zu, simuliert oder real) und Stresstests sein, dabei wird das System an die Grenzen der Leistungsfähigkeit geführt.
• Performance Test: ... ob bei bestimmten Speicher- und CPU-Anforderungen ein korrektes Systemverhalten sichergestellt ist.
• Rechnernetz-Test: ... das Systemverhalten in Rechnernetzen (z. B. Verzögerungen der Datenübertragung, Verhalten bei Problemen in der Datenübertragung).
• Sicherheitstest: ... potentielle Sicherheitslücken.

Aus den Qualitätsmerkmalen von Software (z. B. gem. ISO/IEC 9126 – die für die meisten Testanforderungen den Rahmen bilden können) lässt sich eine große Anzahl von Tests ableiten. Testartbezeichnungen gemäß dieser Klassifikation sind zum Beispiel:

• Funktionaler Test bzw. Funktionstest: ... ein System in Bezug auf funktionale Anforderungsmerkmale wie Korrektheit und Vollständigkeit.
• Nicht-funktionaler Test: ... die nicht-funktionalen Anforderungen, wie z. B. die Sicherheit, die Gebrauchstauglichkeit oder die Zuverlässigkeit eines Systems. Beispiele für konkrete Testarten hierzu sind Sicherheitstest, Wiederanlauftest, GUI-Test, Installationstest, Lasttest. Dabei steht nicht die Funktion der Software (Was tut die Software?) im Vordergrund, sondern ihre Funktionsweise (Wie arbeitet die Software?).
• Fehlertest: ... ob die Verarbeitung von Fehlersituationen korrekt, d. h. wie definiert, erfolgt.

Zeitpunkt der Testdurchführung

• Die nach diesem Aspekt bedeutendsten und meist auch im allgemeinen Sprachgebrauch benutzten Testartbezeichnungen sind die Teststufen, die mit Komponententest, Integrationstest, Systemtest, Abnahmetest bezeichnet werden.
• Eine Testart für frühe Tests ist der Alpha-Test (erste Entwicklertests). Ein Vorbereitungstest prüft zunächst nur wesentliche Funktionen. Im späteren Betatest prüfen ausgewählte Benutzer Vorabversionen der nahezu fertigen Software auf Tauglichkeit.
• Produktionstests werden in produktionsähnlich konfigurierten Testumgebungen oder gar in der Produktionsumgebung selbst, zum Teil sogar erst im produktiven Betrieb der Software (nur für unkritische Funktionen geeignet) durchgeführt. Möglicher Grund: Nur die Produktionsumgebung verfügt über bestimmte, zum Testen erforderliche Komponenten.
• Auch Test-Wiederholungen gehören zum Aspekt Testzeitpunkt: Solche Tests werden Regressionstest, Retest oder ähnlich genannt.
• Indirekt mit Zeitbezug sind zu nennen: Entwicklertest (vor Anwendertest ...), statisches Testen (vor dynamischem Testen).

Zum Testen ausgewählte methodische Ansätze

• Spezielle Teststrategien: SMART-Testing, Risk based testing, Data driven Testing, Exploratives Testen, top-down / bottom-up, hardest first, big-bang.
• Besondere Methoden sind für Entscheidungstabellentests, Use-Case- oder anwendungsfallbasierte Tests, Zustandsübergangs-/zustandsbezogene Tests, Äquivalenzklassentests, Mutationstests (gezieltes Verändern von Quelltextdetails zu Testzwecken) und Pair-wise-Tests die Grundlage für Testartbezeichnungen.

Testintensität

• Unterschiedliche Grade der Testabdeckung (Test-Coverage- bzw. Code-Coverage) werden mit Überdeckungstests erreicht, die (auf Grund der geringen Größe der Testobjekte) besonders für Komponententests geeignet sind. Testartenbezeichnungen hierzu: Anweisungs- (C0-Test, C1-Test), Zweig-, Bedingungs- und Pfadüberdeckungstest.
• Mit Vorbereitungstests werden vorerst nur wichtige Hauptfunktionen getestet.
• Ohne systematisch spezifizierte Testdaten/-fälle werden Smoketests ausgeführt, Tests, bei denen lediglich ausprobiert werden soll, ob das Testobjekt ‚überhaupt irgendetwas tut - ohne abzurauchen‘ – zum Beispiel im Rahmen eines Vorbereitungstests oder auch als finale Stichprobe beim Abschluss einer Teststufe.
• Beim Error Guessing provozieren (erfahrene) Tester bewusst Fehler.

Informationsstand über die zu testenden Komponenten

... der beim Spezifizieren/Durchführen von Tests genutzt wird:

• Black-Box-Tests werden ohne Kenntnisse über den inneren Aufbau des zu testenden Systems, sondern auf der Basis von Entwicklungsdokumenten entwickelt. In der Praxis werden Black-Box-Tests meist nicht von den Software-Entwicklern, sondern von fachlich orientierten Testern oder von speziellen Test-Abteilungen oder Test-Teams entwickelt. In diese Kategorie fallen auch Anforderungstests (Requirements Tests) (auf der Grundlage spezieller Anforderungen) und stochastisches Testen (statistische Informationen als Testgrundlage)
• White-Box-Tests, auch strukturorientierte Tests genannt, werden auf Grund von Wissen über den inneren Aufbau der zu testenden Komponente entwickelt. Entwicklertests sind i. d. R. White-Box-Tests - wenn Entwickler und Tester dieselbe Person sind. Hierbei besteht die Gefahr, dass Missverständnisse beim Entwickler zwangsläufig zu ‚falschen‘ Testfällen führen, der Fehler also nicht erkannt wird.
• Grey-Box-Test werden zum Teil Tests genannt, bei denen eine Kombination von White- und Blackbox-Tests parallel praktiziert wird bzw. die nur auf partiellen Codekenntnissen beruhen.^[12]
• Low-Level-Test/High-Level-Test: Fasst Testarten begrifflich danach zusammen, ob sie auf konkrete technische Komponenten ausgerichtet sind (wie Debugging, White-Box-Test für low-Level) oder aufgrund von Vorgaben zur Implementierung ausgeführt/spezifiziert werden, z. B. Requirementstest (Anforderungstest), Black-Box-Test für high-Level.

Wer führt die Tests aus oder spezifiziert sie?

• Entwicklertests (Programmierertests), Benutzertests, Anwendertests, Benutzerakzeptanztests (User Acceptance Tests - UAT) werden von der jeweiligen Testergruppe durchgeführt.
• Abnahmetests führen die fachlich für die Software verantwortlichen Stellen aus.
• Betriebstest, Installationstests, Wiederanlauftests, Notfalltests nehmen u. a. auch Vertreter des ‚Rechenzentrums‘ vor - zur Sicherstellung der Einsatzfähigkeit nach definierten Vorgaben.
• Crowd Testing; nach dem Prinzip des Crowdsourcing werden Testaufgaben an eine Menge von Usern im Internet (die Crowd) ausgelagert.

Art der Softwaremaßnahme

Diese Kategorie ist von eher untergeordneter Bedeutung; aus ihr resultieren Testbegriffe wie die folgenden:

• In Wartungsprojekten werden Wartungstests und Regressionstests ausgeführt; dabei werden i. d. R. bereits vorhandene Testfälle und Testdaten benutzt.
• In Migrationsprojekten werden Migrationstests durchgeführt; die Datenüberführung und spezielle Migrationsfunktionen sind hierbei z. B. Testinhalte.

Pol, Koomen und Spillner beschreiben in^[1] die Teststrategie als umfassenden Ansatz: Eine Teststrategie ist notwendig, da ein vollständiger Test, d. h. ein Test, der alle Teile des Systems mit allen möglichen Eingabewerten unter allen Vorbedingungen überprüft, in der Praxis nicht durchführbar ist. Deswegen muss in der Test-Planung anhand einer Risikoabschätzung festgelegt werden, wie kritisch das Auftreten eines Fehlers in einem Systemteil einzuschätzen ist (z. B. nur finanzieller Verlust oder Gefahr für Menschenleben) und wie intensiv (unter Berücksichtigung der verfügbaren Ressourcen und des Budgets) ein Systemteil getestet werden muss oder kann.

Demnach ist in der Teststrategie festzulegen, welche Teile des Systems mit welcher Intensität unter Anwendung welcher Testmethoden und -Techniken unter Nutzung welcher Test-Infrastruktur und in welcher Reihenfolge (siehe auch Teststufen) zu testen sind.

Sie wird vom Testmanagement im Rahmen der Testplanung erarbeitet, im Testplan dokumentiert und festgelegt und als Handlungsrahmen für das Testen (durch die Testteams) zu Grunde gelegt.

Nach einer anderen Interpretation wird „Teststrategie“ als methodischer Ansatz verstanden, nach dem das Testen angelegt wird.

So benennt z. B. ISTQB Ausprägungen für Teststrategien wie folgt:

• top-down: Haupt- vor Detailfunktionen testen; untergeordnete Routinen werden beim Test zunächst ignoriert oder (mittels „Stubs“) simuliert
• bottom-up: Detailfunktionen zuerst testen; übergeordnete Funktionen oder Aufrufe werden mittels „Testdriver“ simuliert
• hardest first: Situationsbedingt das Wichtigste zuerst
• big-bang: Alles auf einmal

Weitere Prinzipien und Techniken für Teststrategien sind:

• Risk based Testing: Testprinzip, nach dem die Testabdeckung an den Risiken ausgerichtet wird, die in den Testobjekten (für den Fall des Nichtfindens von Fehlern) eintreten können.
• Data driven Testing: Testtechnik, mit der über Einstellungen in den Testscripts die Datenkonstellationen gezielt geändert werden können, um damit mehrere Testfälle hintereinander effizient testen zu können
• Testgetriebene Entwicklung
• SMART: Testprinzip „Specific, Measurable, Achievable, Realistic, time-bound“
• Keyword driven testing
• framework based Testing: Test-Automatisierung mittels Testwerkzeugen für bestimmte Entwicklungsumgebungen / Programmiersprachen
• Testing nach ISO/IEC 25000: Die ISO/IEC-Norm 25000 ist ein Standard für Qualitätskriterien sowie Bewertungsmethoden für Software und Systeme. Dementsprechend kann ein Ansatz für eine Teststrategie auf den in dieser Norm vorhandenen Standards basieren.

Grundsätzlich ist es aus Gründen der Zeit und/oder den finanziellen Mitteln niemals möglich, eine Software (oder Teile einer Software) komplett zu testen. Aus diesem Grund ist es wichtig, Tests gemäß der Bedeutung des zu testenden Software-Bestandteils zu priorisieren. Eine bewährte Methode zur Priorisierung von Tests ist die risikobasierte Methode, auch RPI-Methode genannt, wobei RPI für Risiko-Prioritäts-Index steht.

In der RPI-Methode werden zuerst die Anforderungen zu Gruppen zugeordnet. Anschließend werden Kriterien definiert, welche für das Endprodukt von Bedeutung sind. Diese Kriterien werden später verwendet, um die Anforderungsgruppen zu bewerten. Nachfolgend wird auf die drei Kriterien eingegangen, welche sich aus der Praxis bewährt haben. Mit den aufgezeigten Fragen soll es möglichst gut gelingen, die Anforderungen zu unterscheiden, womit die Bewertung ermöglicht wird.

Businessrelevanz

• Wie groß ist der Nutzen für den/die Endanwender?
• Wie groß ist der Schaden bei Nichterfüllung dieser Anforderung?
• Wie viele Endanwender wären betroffen, wenn diese Anforderung nicht erfüllt wird?
• Wie wichtig ist diese Anforderung gegenüber anderen Anforderungen? Muss/soll/kann sie erfüllt werden?

Auffindbarkeit

• Ist der Fehler bzw. ein Nichterfüllen der Anforderung schnell auffindbar?
• Wird der Fehler überhaupt bemerkt?
• Wie wird der Fehler ersichtlich?
• Findet jeder den Fehler oder eher Anwender, welche erweitertes Wissen gegenüber dem Produkt vorweisen?

Komplexität

• Wie komplex ist die Anforderung?
• Wie sehr ist die Anforderungen von anderen Teilen abhängig? Wie viele andere Anforderungen hängen davon ab?
• Wie komplex ist die Umsetzung der Anforderung?
• Sind Technologien im Einsatz, welche eher einfach oder komplex sind?

Sobald die Anforderungen gruppiert und die Kriterien definiert wurden, durchlaufen sämtliche Anforderungsgruppen die drei Kriterien. Die Anforderungen werden von 1 bis 3 bewertet, wobei 3 dem höchsten Wert (bezgl. Wichtigkeit) darstellt (für eine breitere Verteilung der Anforderungen kann die Skala beliebig angepasst werden). Ist dies getan, wird das Produkt aus den drei bewerteten Kriterien gebildet - woraus sich die Wichtigkeit der Anforderungen ergibt.

ISO 25000 definiert 8 Dimensionen^[13] für Software-Qualitätsmerkmale. Diese Dimensionen sind die folgenden:

• Funktionale Eignung (Ist die geforderte Funktionalität in der Software gegeben?):
  • Angemessenheit
  • Richtigkeit
  • Interoperabilität
  • Ordnungsmäßigkeit
• Zuverlässigkeit (Wie zuverlässig arbeitet die Software?):
  • Reife
  • Fehlertoleranz
  • Wiederherstellbarkeit
• Benutzbarkeit (Ist die Software einfach bedienbar?):
  • Verständlichkeit
  • Erlernbarkeit
  • Bedienbarkeit
• Leistungseffizienz (Wie effizient arbeitet die Software?):
  • Zeitverhalten
  • Verbrauchsverhalten
• Wartbarkeit (Wie leicht lässt sich die Software modifizieren?):
  • Analysierbarkeit
  • Modifizierbarkeit
  • Stabilität
  • Prüfbarkeit
  • Anpassbarkeit
• Übertragbarkeit (Wie leicht lässt sich die Software auf ein anderes System portieren?):
  • Anpassbarkeit
  • Installierbarkeit
  • Konformität
  • Austauschbarkeit
• Sicherheit (Wie sicher sind unsere Daten und Programme vor nicht autorisiertem Zugriff?):
  • Zugriffssicherheit
  • Datenverschlüsselung
• Kompatibilität (Wie kompatibel ist die Software beim Austausch und der Verarbeitung von Daten mit und von anderen Systemen?):
  • Austauschbarkeit
  • Erweiterbarkeit
  • Abwärtskompatibilität

Die Teststrategie ist auf diese 8 auf Erfahrungen und Standards basierenden Qualitätsmerkmale ausgerichtet. Durch gezielt dafür erstellte Testfälle soll sichergestellt werden, dass diese Kriterien von der zu testenden Software – soweit relevant – eingehalten/unterstützt werden.

Die Sieben Grundsätze des Softwaretestens liefern nach ISTQB CTFL Syllabus^[14] generelle allgemeine Richtlinien für alle Tests.

1. Testen zeigt die Anwesenheit von Fehlerzuständen, nicht deren Abwesenheit

   Mit Testen lässt sich (nach Spillner und Linz^[4]) nicht beweisen, dass keine Fehlerzustände im Testobjekt vorhanden sind. Selbst wenn keine Fehlerwirkungen im Test aufgezeigt wurden, ist dies kein Nachweis für Fehlerfreiheit oder Korrektheit.

   Testen reduziert die Wahrscheinlichkeit, dass noch unentdeckte Fehlerzustände in der Software vorhanden sind, aber auch wenn keine Fehlerzustände gefunden werden, ist Testen kein Beweis dafür, dass es keine Fehlerzustände gibt.^[14]

2. Vollständiges Testen ist nicht möglich

   Mit Ausnahme von sehr trivialen Testobjekten ist ein vollständiger Test, bei dem alle möglichen Eingabewerte und deren Kombinationen unter Berücksichtigung aller unterschiedlichen Vorbedingungen ausgeführt werden, nicht durchführbar.^[14]

   Tests sind immer nur Stichproben, und der Testaufwand ist deshalb nach Risiko und Prioritäten zu steuern.^[4]

3. Frühes Testen (Shift left) spart Zeit und Geld

   Testaktivitäten sollten so früh wie möglich im Softwareentwicklungslebenszyklus gestartet werden, um Fehlerzustände frühzeitig zu erkennen.^[14]

   Das hilft dabei, im Softwareentwicklungslebenszyklus späte und damit kostenintensive Änderungen zu vermeiden.^[4]

4. Fehlerzustände treten gehäuft auf

   Die meisten Fehlerzustände finden sich in der Regel in nur wenigen Teilen (Modulen) eines Systems.^[4]

   Das Phänomen, dass eine kleine Anzahl von Komponenten eines Systems häufig die meisten der entdeckten Fehlerzustände enthält bzw. für die meisten Fehlerwirkungen im Betrieb verantwortlich ist, ist eine Veranschaulichung des Pareto-Prinzips. Vorausgesagte Anhäufungen von Fehlerzuständen und die tatsächlich beobachteten Fehlerzustände im Test oder im Betrieb sind ein wichtiger Beitrag für den risikobasierten Test bzw. zur Risikoanalyse, die genutzt wird, um den Testaufwand zu konzentrieren.^[14]

5. Tests nutzen sich ab (früher auch „Vorsicht vor dem Pestizid-Paradoxon“)

   Werden Tests nur unverändert wiederholt, decken sie keine neuen Fehlerwirkungen mehr auf. Damit die Effektivität der Tests nicht absinkt, sind die vorhandenen Testfälle regelmäßig zu prüfen und zu ergänzen.^[4]

   In einigen Fällen kann die Wiederholung der gleichen Tests jedoch zu einem positiven Ergebnis führen, z. B. bei automatisierten Regressionstests.^[14]

6. Testen ist kontextabhängig

   Es gibt keinen universell anwendbaren Ansatz für das Testen. Das Testen wird in verschiedenen Kontexten unterschiedlich praktiziert.^[15]

   Je nach Einsatzgebiet und Umfeld des zu prüfenden Systems ist das Testen (Intensität, Definition der Endekriterien usw.) entsprechend seines Einsatzumfelds anzupassen.^[4]

7. Trugschluss: „Keine Fehler bedeutet ein brauchbares System“

   Es ist ein Irrtum zu erwarten, dass das Verifizieren von Software den Erfolg eines Systems sicherstellt.^[14] Trotz gründlicher Tests der Anforderungen und Beheben aller gefundenen Fehlerzustände kann ein System entwickelt worden sein, das schwer zu nutzen ist, die Bedürfnisse der Nutzer nicht erfüllt oder eine geringe Qualität aufweist im Vergleich zu anderen Systemen (oder dem Vorgängersystem).^[4] Neben der Verifizierung sollte auch eine Validierung durchgeführt werden.^[16]

   Zur Vermeidung des Problems empfehlen Spillner und Linz^[4] die frühzeitige Einbeziehung der späteren Nutzer in den Entwicklungsprozess und die Nutzung von Prototyping als vorbeugende Maßnahmen.

Zur Testplanung gehört auch die Vorbereitung der Dokumentation. Eine normierte Vorgehensweise dazu empfiehlt der Standard IEEE 829.^[17][18] Laut diesem Standard gehören zu einer vollständigen Testdokumentation folgende Unterlagen:

Testplan

Beschreibt Umfang, Vorgehensweise, Terminplan, Testgegenstände.

Testdesignspezifikation

Beschreibt die im Testplan genannten Vorgehensweisen im Detail.

Testfallspezifikationen

Beschreibt die Umgebungsbedingungen, Eingaben und Ausgaben eines jeden Testfalls.

Testablaufspezifikationen

Beschreibt in Einzelschritten, wie jeder Testfall durchzuführen ist.

Testobjektübertragungsbericht

Protokolliert, wann welche Testgegenstände an welche Tester übergeben wurden.

Testprotokoll

Listet chronologisch alle relevanten Vorgänge bei der Testdurchführung.

Testvorfallbericht

Listet alle Ereignisse, die eine weitere Untersuchung erforderlich machen.

Testergebnisbericht

Beschreibt und bewertet die Ergebnisse aller Tests.

Insbesondere bei Tests, die häufig wiederholt werden, ist deren Automatisierung angeraten. Dies ist vor allem bei Regressionstests und bei testgetriebener Entwicklung der Fall. Darüber hinaus kommt Testautomatisierung bei manuell nicht oder nur schwer durchführbaren Tests zum Einsatz (z. B. Lasttests).

• Durch Regressionstests wird nach Softwareänderungen meist im Zuge des System- oder Abnahmetests der fehlerfreie Erhalt der bisherigen Funktionalität überprüft.
• Bei der testgetriebenen Entwicklung werden die Tests im Zuge der Softwareentwicklung im Idealfall vor jeder Änderung ergänzt und nach jeder Änderung ausgeführt.

Bei nicht automatisierten Tests ist in beiden Fällen der Aufwand so groß, dass häufig auf die Tests verzichtet wird.

Die nebenstehende Grafik zeigt Begriffe, die im Kontext 'Testen' auftreten – und wie sie mit anderen Begriffen in Verbindung stehen.

Die Grafik zeigt die wichtigsten Schnittstellen, die beim Testen auftreten. Zu den von Thaller^[19] genannten 'Partnern' beim Testen wird nachfolgend beispielhaft angeführt, was jeweils kommuniziert bzw. ausgetauscht wird.

• Projektmanagement: Termin- und Aufwandsrahmen, Status je Testobjekt ('testready'), Dokumentationssysteme
• Linienmanagement (und Linienabteilung): Fachlicher Support, Testabnahme, fachliche Tester stellen
• Rechenzentrum: Testumgebung(en) und Testwerkzeuge bereitstellen und betreiben
• Datenbankadministrator: Testdatenbestände installieren, laden und verwalten
• Konfigurations-Management: Testumgebung einrichten, Integrieren der neuen Software
• Entwicklung: Test-Basisdokumente, Prüflinge, Support zum Testen, Testergebnisse erörtern
• Problem- und CR-Management: Fehlermeldungen, Rückmeldung zum Retest, Fehlerstatistik
• Lenkungsausschuss: Entscheidungen zur Test(stufen)abnahme oder zum Testabbruch

• Andreas Spillner, Tilo Linz: Basiswissen Softwaretest. Aus- und Weiterbildung zum Certified Tester. Foundation Level nach ISTQB-Standard. 5., überarbeitete und aktualisierte Auflage. dpunkt.verlag, Heidelberg 2012, ISBN 978-3-86490-024-2. 
• Harry M. Sneed, Manfred Baumgartner, Richard Seidl: Der Systemtest - Von den Anforderungen zum Qualitätsnachweis. 3., aktualisierte und erweiterte Auflage. Carl Hanser, München 2011, ISBN 978-3-446-42692-4. 
• Georg Erwin Thaller: Software-Test. Verifikation und Validation. 2., aktualisierte und erweiterte Auflage. Heise, Hannover 2002, ISBN 3-88229-198-2. 
• Richard Seidl, Manfred Baumgartner, Thomas Bucsics, Stefan Gwihs: Basiswissen Testautomatisierung - Konzepte, Methoden und Techniken. 2., aktualisierte und überarbeitete Auflage. dpunkt.verlag, 2015, ISBN 978-3-86490-194-2. 
• Mario Winter, Mohsen Ekssir-Monfared, Harry M. Sneed, Richard Seidl, Lars Borner: Der Integrationstest. Von Entwurf und Architektur zur Komponenten- und Systemintegration. Carl Hanser, 2012, ISBN 978-3-446-42564-4. 
• Bill Laboon: A Friendly Introduction to Software Testing. CreateSpace Independent, 2016, ISBN 978-1-5234-7737-1. 

• Glossar „Testbegriffe“ von ISTQB
• Ausführliche Auflistung von Testmanagement Software und Erläuterung der Management Werkzeugarten im Softwaretest
• Testtool Review - Informations-Portal über das internationale Marktangebot im Bereich Softwaretest-Werkzeuge

1. ↑ ^{a b c d e f} Martin Pol, Tim Koomen, Andreas Spillner: Management und Optimierung des Testprozesses. Ein praktischer Leitfaden für erfolgreiches Testen von Software mit TPI und TMap. 2., aktualisierte Auflage. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2.
2. ↑ IEEE Standard Glossary of Software Engineering Terminology. IEEE, doi:10.1109/ieeestd.1990.101064 (ieee.org [abgerufen am 5. Oktober 2020]). 
3. ↑ Ernst Denert: Software-Engineering. Methodische Projektabwicklung. Springer, Berlin u. a. 1991, ISBN 3-540-53404-0.
4. ↑ ^{a b c d e f g h i j} Andreas Spillner, Tilo Linz: Basiswissen Softwaretest: Aus- und Weiterbildung zum Certified Tester, Foundation Level, nach ISTQB-Standard. 6. Auflage. dpunkt.verlag, Heidelberg 2019, ISBN 978-3-86490-583-4. 
5. ↑ ^{a b} Fehlerkosten 10er Regel Zehnerregel (Rule of ten). In: SixSigmaBlackBelt.de. 19. Juni 2021, abgerufen am 5. April 2022. 
6. ↑ ^{a b c} Steve McConnell: Code Complete. A Practical Handbook of Software Construction. 2. Auflage. Microsoft Press, 2004, ISBN 978-0-7356-1967-8, S. 470 (englisch, 960 S.): “Unit test: Lowest Rate 15%, Modal Rate 30%, Highest Rate 50%; Integration test: Lowest Rate 25%, Modal Rate 35%, Highest Rate 40%; System test: Lowest Rate 25%, Modal Rate 40%, Highest Rate 55%” 
7. ↑ Capers Jones: Software Engineering Best Practices. Lessons from Successful Projects in the Top Companies. Mc Graw Hill, 2010, ISBN 978-0-07-162162-5, S. 660 (englisch, 960 S.). 
8. ↑ David Longstreet: Test Cases & Defects. Softwaremetrics, archiviert vom Original am 8. Februar 2019; abgerufen am 8. September 2022 (englisch): „The number of acceptance test cases can be estimated by multiplying the number of function points by 1.2“ 
9. ↑ ISTQB Certified Tester Foundation Level Syllabus Version 2011 1.0.1 International Software Testing Qualifications Board. Abgerufen am 20. Mai 2019. , Deutschsprachige Ausgabe. Herausgegeben durch Austrian Testing Board, German Testing Board e. V. & Swiss Testing Board, Kap. 1.4
10. ↑ Peter Liggesmeyer: Software-Qualität. Testen, Analysieren und Verifizieren von Software. Spektrum Akademischer Verlag, Heidelberg u. a. 2002, ISBN 3-8274-1118-1, S. 34.
11. ↑ Toby Clemson: Testing Strategies in a Microservice Architecture. In: Martin Fowler. 18. November 2014, abgerufen am 13. März 2017 (englisch). 
12. ↑ Tobias Weber, Uni Köln, Planung von Softwareprojekten (Memento vom 9. August 2016 im Internet Archive) White Black and Grey Box Test
13. ↑ Dominique Portmann: The Noser Way of Testing. Hrsg.: Noser Engineering AG. 7. Auflage. Januar 2016. 
14. ↑ ^{a b c d e f g} ISTQB Certified Tester Foundation Level Syllabus Version 2023 4.0.1D International Software Testing Qualifications Board. Abgerufen am 25. Januar 2024.  Deutschsprachige Ausgabe. Herausgegeben durch Austrian Testing Board, German Testing Board e. V. & Swiss Testing Board, Kap. 1.3
15. ↑ Cem Kaner, James Bach, Bret Pettichord: Lessons Learned in Software Testing: A Context-Driven Approach. 1. Auflage. John Wiley & Sons, 2011, ISBN 978-1-118-08055-9. 
16. ↑ Barry W. Boehm: Software Engineering Economics. Hrsg.: Prentice-Hall. 1. Auflage. 1981. 
17. ↑ IEEE Standard for Software Test Documentation (IEEE Std. 829-1998)
18. ↑ IEEE Standard for Software and System Test Documentation (IEEE Std. 829-2008)
19. ↑ Georg Erwin Thaller: Software-Test. Verifikation und Validation. 2., aktualisierte und erweiterte Auflage. Heise, Hannover 2002, ISBN 3-88229-198-2.