Richtlinie: Wichtige Entscheidungen in Test
Diese Richtlinie beschreibt wichtige Punkte, die bei der Anpassung der Testaspekte des Prozesses zu berücksichtigen sind.
Beziehungen
Hauptbeschreibung

Verwendung der Arbeitsergebnisse festlegen

Sie müssen entscheiden, welche Arbeitsergebnisse verwendet werden sollen und wie. Außerdem müssen Sie jedes Arbeitsergebnis so anpassen, dass es den Anforderungen des Projekts entspricht.  

Die folgende Tabelle enthält eine Liste der empfohlenen und optionalen (die nur in bestimmten Fällen verwendet werden können) Arbeitsergebnisse aus der Disziplin Test. Weitere Hinweise zur Anpassung finden Sie im Abschnitt "Anpassen" auf der Seite mit der Beschreibung des jeweiligen Arbeitsergebnisses.

Arbeitsergebnis Zweck Anpassen (optional, empfohlen)
Zusammenfassung der Testbewertung Fasst die Testergebnisse für das Managementteam (hauptsächlich) und andere Stakeholder außerhalb des Testteams zusammen. Empfohlen für die meisten Projekte.

Wenn die Projektkultur sich durch regen Informationsaustausch auszeichnet, kann es angemessen sein, die Testergebnisse einfach zu notieren und keine formalen Auswertungszusammenfassungen zu erstellen. In anderen Fällen können Zusammenfassungen der Testauswertung als Abschnitt in andere Arbeitsergebnisse für Auswertung eingefügt werden, z. B. die Iterationsauswertung oder die Prüfunterlagen.
Testergebnisse Dieses Arbeitsergebnis ist das analysierte Ergebnis, das auf den Rohdaten in einem oder mehreren Testprotokollen basiert. Empfohlen. Die meisten Testteams führen in irgendeiner Form mehr oder weniger detaillierte Unterlagen zu den Ergebnissen ihrer Tests. Die Ergebnisse manueller Tests werden normalerweise direkt in diesem Arbeitsergebnis aufgezeichnet und mit den gefilterten Testprotokollen von automatisierten Tests.

In einigen Fällen gehen Testteams von den Testprotokollen direkt zum Erzeugen der Zusammenfassung der Testauswertung über.
Testprotokoll

Die während der Testausführung ausgegebenen Rohdaten, die normalerweise von automatisierten Testscripts erzeugt werden.

Optional.

Viele Projekte, die automatisierte Tests verwenden, haben irgendeine Form von Testprotokoll. Worin sich Projekte unterscheiden, ist der Umgang mit den Testprotokollen nach der Auswertung der Testergebnisse, d. h. ob die Protokolle aufbewahrt oder verworfen werden.

Sie können Testprotokolle aufbewahren, wenn Sie bestimmte Prüfanforderungen erfüllen müssen, wenn Sie analysieren möchten, wie sich die ausgegebenen Testrohdaten im Laufe der Zeit ändern oder wenn Sie sich über den Umfang der zu erbringenden Analysen nicht im Klaren sind.

Testsuite In einer Testsuite werden einzelne zusammengehörige Tests (Testscripts) in aussagefähigen Untergruppen zusammengefasst. Empfohlen für die meisten Projekte.

Testsuites sind auch erforderlich, um alle Testscriptsequenzen zu definieren, die erforderlich sind, damit die Tests korrekt funktionieren.
Liste mit Testideen Eine Liste mit einer Aufzählung von Ideen, die häufig nur unvollständig formuliert sind und als hilfreiche Tests betrachtet werden. Empfohlen für die meisten Projekte.

In einigen Fällen werden diese Listen formlos definiert und verworfen, sobald entsprechende Testscripts oder Testfälle definiert wurden.
Teststrategie Definiert den strategischen Plan für den Testaufwand anhand eines oder mehrerer Aspekte des Zielsystems. Empfohlen für die meisten Projekte.

In den meisten Fällen wird eine einzelne Teststrategie pro Projekt oder pro Phase empfohlen. Optional können Sie vorhandene und geeignete Strategien wiederverwenden oder die Teststrategien basierend auf dem Typ der auszuführenden Tests weiter unterteilen.
 Testplan Definiert differenziertere Ziele, Zielsetzungen, Motivationen, Ansätze, Ressourcen, Zeitpläne und Arbeitsergebnisse für das Testen in einer bestimmten Iteration. Empfohlen für die meisten Projekte.

Ein separater Testplan pro Iteration ist empfohlen, um die spezifische, differenzierte Teststrategie zu definieren. Optional können Sie den Testplan als Abschnitt in den Iterationsplan einfügen.
 Testplan Definiert differenziertere Ziele, Zielsetzungen, Ansätze, Ressourcen, Zeitpläne und Arbeitsergebnisse für das Testen in einer bestimmten Phase oder im gesamten Lebenszyklus. Optional. Hilfreich für die meisten Projekte.

Ein Master-Testplan definiert die übergeordnete Teststrategie über größere Strecken des Softwareentwicklungszyklus hinweg. Optional können Sie den Testplan als Abschnitt in den Softwareentwicklungsplan einfügen.

Stellen Sie fest, ob Sie neben den Iterationstestplänen auch noch einen Master-Testplan verwalten möchten. Der Master-Testplan enthält primär Informationen zur Logistik und zur Prozessumsetzung, die sich auf den gesamten Projektlebenszyklus beziehen. Deshalb ist es unwahrscheinlich, dass er sich zwischen Iterationen ändert.
 Testscript,  Testdaten Die Testscripts und Testdaten sind die Realisierung oder Implementierung des Tests, wobei die Testscripts die prozeduralen Aspekte abdecken und die Testdaten die definierenden Merkmale. Empfohlen für die meisten Projekte.

Worin sich die Projekte unterscheiden, ist die Formalität, mit der diese Arbeitsergebnisse behandelt werden. In einigen Fällen sind die Arbeitsergebnisse formlos und temporär, und das Testteam wird anhand von anderen Kriterien beurteilt. In anderen Fällen, insbesondere bei automatisierten Tests, werden die Testscripts und die zugehörigen Testdaten (oder ein Teil derselben) als Hauptliefergegenstände der Tests betrachtet.
 Testfall

Definiert bestimmte Testeingaben, Ausführungsbedingungen und erwartete Ergebnisse.

Wenn Sie Testfälle dokumentieren, können sie auf Vollständigkeit und Richtigkeit geprüft und der Planung und Erweiterung der Implementierung berücksichtigt werden.

Dies ist besonders hilfreich, wenn die Eingaben, Ausführungsbedingungen und erwarteten Ergebnisse sehr komplex sind.

Für die meisten Projekte, in denen die Bedingungen für die Ausführung eines bestimmten Tests sehr komplex sind, wird empfohlen, Testfälle zu definieren. Testfälle müssen dokumentiert werden, wenn sie ein vertraglich festgelegter Liefergegenstand sind.

Für die meisten anderen Fälle wird empfohlen, eine Liste mit Testideen und die implementierten Testscripts zu pflegen, anstatt detaillierte Testfälle zu dokumentieren.

Einige Projekte skizzieren Testfälle einfach auf einer hohen Ebene und verlagern die Details auf die Testscripts. Eine andere gebräuchliche Methode ist, die Testfälle in Form von Kommentaren in Testscripts zu dokumentieren.

 Auslastungsanalysemodell

Eine spezieller Typ von Testfall, mit dem eine repräsentative Arbeitslast definiert werden kann, um Qualitätsrisiken in Bezug auf den Systembetrieb unter Last bewerten zu können.

Empfohlen für die meisten Systeme, insbesondere solche, bei denen die Systemleistung unter Last auswertet werden muss oder bei denen es andere signifikanten Qualitätsrisiken gibt, die sich auf den Systembetrieb unter Last beziehen.

Normalerweise nicht erforderlich für Systeme, die auf einem eigenständigen Zielsystem eingesetzt werden.

 Testfähigkeitsklassen im Designmodell

 Testfähigkeitselemente im Implementierungsmodell

Wenn das Projekt wichtiges zusätzliches Sonderverhalten entwickeln für die Unterstützung von Tests entwickeln muss, werden diese Aspekte durch den Einschluss von Testfähigkeitsklassen in das Designmodell und Testfähigkeitselementen in das Implementierungsmodell dargestellt.

Wann immer erforderlich.

 Stubs sind eine allgemeine Kategorie für Testklassen und Testkomponenten.

 Architektur für Testautomatisierung

Bietet eine umfassende Übersicht über die Architektur des Testautomatisierungssystems und enthält verschiedene Architektursichten, um unterschiedliche Aspekte des Systems zu veranschaulichen.

Optional.

Empfohlen für Projekte, in denen die Testarchitektur relativ komplex ist, eine Vielzahl von Mitarbeitern an der Erstellung automatisierter Tests zusammenarbeiten oder in denen das Testautomatisierungssystem s über einen langen Zeitraum hinweg gepflegt werden soll.

In einigen Fällen kann es sich einfach um ein Diagramm an einer Tafel handeln, die an einer zentralen Stelle für die interessierten Parteien aufgestellt ist.

 Testschnittstellenspezifikation

Definiert die erforderlichen Verhaltensweisen anhand eines Klassifikationsmerkmals (d. h. Klasse, Subsystem oder Komponente) für Tests (Testfähigkeit). Gebräuchliche Typen sind Testzugriff, Stub-Verhalten, Protokollierung für Diagnose und Testorakel.

Optional.

In vielen Projekten bieten sich ausreichende Testmöglichkeiten in den sichtbaren Operationen in Klassen, Benutzerschnittstellen usw. an.

Zu den gängigen Gründen für das Erstellen von Testschnittstellenspezifikationen gehören UI-Erweiterungen, um GUI-Testtools die Interaktion mit den Protokollierungsroutinen für Tool- und Diagnosenachrichten, insbesondere für Stapelprozesse zu ermöglichen.



Überprüfung der Arbeitsergebnisse festlegen

Dieser Abschnitt enthält Richtlinien, die Ihnen dabei helfen zu entscheiden, wie die Arbeitsergebnisse für Tests geprüft werden sollen. Eine allgemeine Anleitung finden Sie in Anleitung: Prüfebenen.

Mängel

Die Behandlung von Mängelprüfungen richtet sich in hohem Maß nach dem Kontext, aber im Allgemeinen werden sie als formlos, formal-intern oder formal-extern eingestuft. Dieser Prüfprozess wird häufig durch das Workflow-Management in einem Fehlererfassungssystem umgesetzt oder zumindest von einem solchen unterstützt. Im Allgemeinen richtet sich der Grad der Überprüfungsformalitäten nach dem Schweregrad oder den Auswirkungen des Mangels, aber auch Faktoren wie die Projektkultur und individuelle Verfahren haben Einfluss auf die Vorgehensweise bei der Überprüfung.

Manchmal bietet sich die gesonderte Behandlung von Mängeln (auch Symptome oder Funktionsstörungen genannt) und Fehlern (die eigentliche Fehlerursache) an. In kleinen Projekten brauchen Sie normalerweise nur die Mängel zu verfolgen und behandeln damit gleichzeitig die Fehler. Mit zunehmender Komplexität des Systems kann es jedoch von Vorteil sein, die Verwaltung von Mängeln und Fehlern zu trennen. Beispielsweise können mehrere Mängel auf denselben Fehler zurückzuführen sein. Wenn der Fehler behoben wird, müssen die berichteten Mängel gefunden und die Benutzer, die diese eingereicht haben, informiert werden, was nur möglich ist, wenn Mängel und Fehler voneinander unabhängig identifiziert werden können.

Testplan und Teststrategie

In jedem Projekt, in dem die Tests nicht einfach sind, benötigen Sie irgendeine Form von Testplan oder Teststrategie. Im Allgemeinen benötigen Sie einen Testplan für jede Iteration und eine übergeordnete Teststrategie. Optional können Sie einen Master-Testplan erstellen und pflegen. In vielen Fällen werden diese Arbeitsergebnisse formlos geprüft, d. h. zwar geprüft, aber nicht formal genehmigt. Wenn die Testtransparenz für die externen Stakeholder wichtig ist, müssen diese Arbeitsergebnisse formal-intern oder sogar formal-extern geprüft werden.

Testscripts

Testscripts werden normalerweise als formlose Arbeitsergebnisse behandelt, d. h. sie werden von jemandem innerhalb des Testteams genehmigt. Wenn die Testscripts von mehreren Testern verwendet und gemeinsam genutzt oder für unterschiedliche Tests wiederverwendet werden sollen, müssen sie als formal-interne Arbeitsergebnisse behandelt werden.

Testfälle

Testfälle werden vom Testteam erstellt und normalerweise je nach Kontext in einem formlosen Prozess oder gar nicht geprüft. In gewissen Fällen können Testfälle von anderen Teammitgliedern, d. h. in einem formal-internen Prozess, oder durch externe Stakeholder in einem formal-externen Prozess genehmigt werden.

Es wird empfohlen, nur die erforderlichen Testfälle formal zu überprüfen, die sich im Allgemeinen auf einen kleinen Teil beschränken, der am wichtigsten ist. Wenn ein Kunde beispielsweise ein Produkt prüfen möchten, bevor es freigegeben wird, kann ein Teil der Testfälle als Basis für die Überprüfung ausgewählt werden. Diese Testfälle werden als formal-extern behandelt.

Testarbeitsergebnisse in Design und Implementierung

Testfähigkeitsklassen sind im Designmodell und Testfähigkeitselemente im Implementierungsmodell zu finden. Mit diesen in Beziehung stehen zwei weitere Arbeitsergebnisse (obwohl nicht spezifisch für Tests): Pakete im Designmodell und Subsysteme im Implementierungsmodell.

Diese Arbeitsergebnisse sind Design- bzw. Implementierungsarbeitsergebnisse, werden jedoch für die Unterstützung der Testfunktionalität in der Software erstellt. Es liegt nahe, sie zusammen mit den Design- und Implementierungsarbeitsergebnissen aufzubewahren. Benennen oder kennzeichnen Sie sie so, dass sie sich eindeutig vom Design und von der Implementierung des Kernsystems unterscheiden lassen. Überprüfen Sie diese Arbeitsergebnisse unter Einhaltung der Prüfprozeduren für Design- und Implementierungsarbeitsergebnisse.

Abnahmekriterien für eine Iteration festlegen

Versuchen Sie in jeder Iteration, vorab klar zu definieren, wie beurteilt wird, ob die Tests ausreichend waren, und auf welcher Basis diese Beurteilung beruhen soll. Sprechen Sie dies mit der Person bzw. Gruppe ab, die für die Abnahme verantwortlich ist.

Die folgenden Beispiele zeigen Methoden für die Genehmigung einer Iteration:

  • Das Projektmanagementteam genehmigt die Iteration und bewertet die Tests anhand der Zusammenfassungen der Testauswertung.
  • Der Kunde genehmigt die Iteration anhand der Zusammenfassungen der Testauswertung.
  • Der Kunde genehmigt die Iteration basierend auf den Ergebnissen einer Demonstration, die einen bestimmten Teil der Gesamttests zeigt. Dieser Teil der Tests muss zunächst definiert und abgestimmt werden, vorzugsweise in einem frühen Stadium der Iteration. Diese Tests werden als formal-extern behandelt und häufig auch als Abnahmetests bezeichnet.
  • Der Kunde überprüft die Systemqualität, indem er eigene unabhängige Tests durchführt. Auch hier muss die Art dieser Tests zunächst klar definiert und abgestimmt werden, vorzugsweise in einem frühen Stadium der Iteration. Diese Tests werden als formal-extern behandelt und häufig auch als Abnahmetests bezeichnet.

Dies ist eine wichtige Entscheidung. Wenn ein Ziel nicht bekannt ist, kann es auch nicht erreicht werden.