Softwaretest

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]

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

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 unabhä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.

Zusammenhang der Dokumente und Verfahrensschritte laut IEEE 829

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.

Wichtige Schnittstellen beim Testen

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