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