Bewertung: 0 / 5

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv
 

 

4 Ergebnistypen im Test

Ein wichtiger Hebel zur Steuerung der Testprozesse ist die Erstellung der typischen Ergebnistypen im Test. Wichtig zu beachten hierbei ist, dass es hierzu bereits eine hilfreiche Standardisierung gibt. Führend ist der IEEE 829 Standard for Software Testdokumentation [IEEE829] . Die folgenden Darstellungen beziehen sich auf diesen Standard, bzw. sind diesem entnommen.

 

Die Eingangsdokumente „Proj Doc“ (Projektdokumentationen) und „Item Doc“ (Projektproduktdokumentationen), sowie die „Test Item“ (Testgegenstand / Software) sind nicht Gegenstand des Standards, sondern werden von den im vorigen Kapitel benachbarten Prozessen definiert/erstellt.

Daneben gibt es weitere typische Dokumente, welche jedoch nicht im IEEE829 hinterlegt sind. Dazu gehört beispielsweise der Testfortschrittsbericht (test progress report), der Teststufensteckbrief, etc. Außerdem gibt es weitere Dokumente, welche in der Regel durch das Projektmanagement definiert werden (beispielsweise Steckbrief des Teilprojekts Test, Risikoliste, Offene Punkte Liste, etc.)

Viele der nachfolgenden Informationen werden typischerweise nicht (mehr) in einem physischen Dokument erfasst, sondern in einer entsprechenden Datenbankstruktur.

Unter dem Kapitel Testmanagementtools werden Vorschläge für die zu erfassenden Felder gemacht.

 

4.1 Überblick

Ergebnistyp

Beschreibung

Testkonzept

(test plan)

Ein Dokument, das u.a. den Gültigkeitsbereich, die

Vorgehensweise, die Ressourcen und die Zeitplanung der

beabsichtigten Tests mit allen Aktivitäten beschreibt.

Es identifiziert u.a. die Testobjekte, die zu testenden Features

und die Testaufgaben. Es ordnet den Testaufgaben die Tester zu

und legt den Unabhängigkeitsgrad der Tester fest. Es beschreibt

die Testumgebung, die Testentwurfsverfahren und die

anzuwendenden Verfahren zur Messung der Tests, und

begründet deren Auswahl. Außerdem werden Risiken

beschrieben, die eine Planung für den Fall des Eintretens

erfordern, werden beschrieben. Ein Testkonzept ist somit die

Niederschrift des Testplanungsprozesses.

Testentwurfsspezifikation (test design specification)

Ein Ergebnisdokument, das die Testbedingungen für ein

Testobjekt, die detaillierte Testvorgehensweise und die

zugeordneten logischen Testfälle identifiziert.

Testfallspezifikation

(test case specification)

Ein Dokument, das eine Menge von Testfällen für ein Testobjekt

spezifiziert (inkl. Testdaten und Vor-/Nachbedingung), bei dem

die Testfälle jeweils Ziele, Eingaben, Testaktionen,

vorausgesagte Ergebnisse und Vorbedingungen für die

Ausführung enthalten.

Testspezifikation

(test specification)

Ein Dokument, das aus der Testentwurfspezifikation, der

Testfallspezifikation und/oder der Testablaufspezifikation

besteht.

Testablaufspezifikation (test procedure specification)

Ein Dokument, das eine Folge von Schritten zur Testausführung

festlegt. Auch bekannt als Testskript oder Testdrehbuch.

Testprotokoll (test log)

Eine chronologische Aufzeichnung von Einzelheiten der

Testausführung.

Fehler- und Abweichungsbericht

(test incident report)

Ein Dokument, das alle Ereignisse auflistet, die während des

Testens aufgetreten sind und untersucht werden müssen.

Testbewertungsbericht (test summary report)

Ein Dokument, das zum Abschluss eines Testprojekts erstellt

wird und sämtliche Testaktivitäten und Ergebnisse

zusammenfasst. Es enthält auch eine Bewertung des

Testprozesses und einen Erfahrungsbericht.

Release Notes

Ein Dokument, das im Rahmen der Übergabe von der

Entwicklung zum Test zu Beginn der Testdurchführung die

Testobjekte identifiziert, ihre Konfiguration, aktuellen Status und

andere Informationen.

 

4.2 Dokumentenidentifikation

Jedes der folgenden Dokumente (bzw. alle Dokumente im Projekt) muss eindeutig identifiziert sein. Dazu gehört auch eine entsprechende Versionierung und die Kennzeichnung des Dokumentenstatus (beispielsweise „in Arbeit“, „fertig“, „abgenommen“) .

Des weiteren sollte das Dokument der jeweilig übergreifende Einheit eindeutig zugeordnet sein. Beim Testkonzept beispielsweise die Nennung der Projekt-Identifikation oder für eine Testentwurfsspezifikation das übergeordnete Testkonzept.

4.3 Testkonzept (test plan)

Der erste Ergebnistyp im Test ist das Testkonzept („Test Plan“). Er bildet das Gegenstück zum Projektmanagementplan im Projektmanagement, jedoch in einer anderen Struktur und mit einem höheren Detailierungsgrad.

Die Erstellung eines Testkonzepts in jedem Softwareentwicklungsprojekt ist essentiell. Dies gilt auch bei der vielfach gehörten Argumentation „aber wir wissen doch, wie es geht und was wir machen wollen“.

Das Testkonzept beschreibt den Inhalt, den Ansatz/Strategie, sowie den Zeitplan der Testaktivitäten. Die Testgegenstände und zu testenden Funktionen sollten identifiziert werden. Daraus ableitend sollte eine konkrete Aufgaben- und Verantwortlichkeitszuordnung stattfinden.

Zusätzlich ist eine Risikobetrachtung durchzuführen.

Sollten die Inhalte „schon bekannt“ sein und der Test „wie immer“ durchzuführen sein, kann die Erstellung einer Kopie aus dem letzten Projekt auch nicht sehr schwer sein. Es ist jedoch zu vermuten, dass es dann doch einige wichtige Unterschiede gibt, über die man sich vor dem Start der Testdurchführung im Klaren sein sollte.

Im Folgenden werden die Komponenten des Testkonzepts im einzelnen beschrieben. Während der IEEE829 Standard davon ausgeht, dass all diese Punkte in einem einzigen Ergebnistyp (und möglichst noch in der vorgegebenen Reihenfolge) abgebildet werden sollen, dürfte dies in der Praxis in den seltensten Fällen der Fall sein.

Nach der Erläuterung der Komponenten, bei denen jede für sich eine absolute Existenzberechtigung hat, werden wir jeweils diskutieren, wie diese in einem Testprojekt optimaler verwaltet werden können, als sie in einer einzigen Datei abzulegen.

Der Bedarf, diese Information geschickter zu verwaltet resultiert zum aus Überlegungen der Pflegbarkeit und Wiederverwendbarkeit zum anderen dem Bedarf die Testmethode auch neueren, iterativeren Entwicklungsansätzen verfügbar zu machen.

 

Auf der anderen Seite liefert eine Konsolidierung aller Informationen in einem Dokument einen einfacheren Zugriff durch alle Mitglieder des Test-Teilprojekt, welche oft nicht während der gesamten Projektlaufzeit mit dem Projekt beschäftigt sind und daher einen anderen und gezielteren Informationsbedarf als andere Projektmitarbeiter haben. (Hierzu ist weiter unten der Ergebnistyp Testanweisungen definiert, welche die optimale Verwaltung von Teilen des Testkonzept - gegenüber einer Darstellung in einem einzigen Dokument – wieder heilt.)

 

Festzuhalten ist an dieser Stelle, dass (in aller Regel) alle unten genannten Informationen zu ermitteln und zu verwalten sind.

Bei großen Projekten kann das Testkonzept selbst hierarchisch aufgebaut sein. Das heißt es gibt ein Mastertestkonzept (master test plan), welcher sich auf alle Teststufen bezieht. Informationen, welche nur pro Teststufe gültig sind werden dann in den Stufentestkonzepten (level test plan) hinterlegt.

 

4.3.1 Einführung

Die Einführung Testkonzepts enthält einen Überblick über die zu testenden Softwarekomponenten und Funktionen. Zusätzlich ist eine Referenz auf das Projektmandat, den Projektplan, den QS-Plan, das Konfigurationsmanagement, bestehende (interne) Richtlinien und relevante (externe) Standards.

Hinweis: Bei großen Projekten sind hierarchische Testkonzept möglich. Der übergeordnete Testkonzept enthält übergreifend gültige Informationen und betrachtet das Zusammenspiel der untergeordneten Testkonzepte. Die untergeordneten Testkonzepte betrachten dann meist Teilkomponenten der Gesamtlösung. Eine Unterteilung nach Teststufen erscheint möglich, wenn die Testbeteiligten in einer anderen Teststufe disjunkt sind. Evtl. könnte dies ein „abgespektes“ Testkonzept für eine spezielle Testergruppe für die jeweilige Teststufe sein. Dies könnte der meist gut abgrenzbaren nicht-funktionalen Tests (z.B. Performancetest), der Abnahmetest (acceptance test) oder der Benutzerakzeptanztest sein.

 

4.3.2 Testelemente

Die Testelemente inkl. Ihrer Versionierung sind Gegenstand des Tests. Des weiteren die notwendigen techn. Voraussetzungen, um diese einzusetzen.

In der Praxis wird man typischerweise diese Information nur generisch im Testkonzept festhalten. Die genaue Reihenfolge der Lieferung und die dazugehörige Versionierung wäre dem Entwicklungsplan zu entnehmen. Bei der tatsächlichen Testdurchführung wird dann der aktuelle Stand der Versionierung festgehalten. (siehe Release Notes)

Kritisch wird die Liste der Testelemente im Testkonzept, wenn es im Test technische Abhängigkeiten zwischen den Versionen der Testobjekte gibt. Dann ist tatsächlich eine detaillierte Planung notwendig, wobei die Testausführungsplanung sich von der Entwicklungsplanung unterscheiden kann (Reihenfolge und Abhängigkeiten).

(Aus diesem Grunde ist beispielsweise der Ergebnistyp „test item transmittal report“ von erheblicher Bedeutung für die erfolgreiche Testdurchführung.)

Des weiteren sollten Querverweise/Referenzen auf Anforderungsdokumente (fachliche Spezifikation, Fachkonzept), Designdokumente (DV-Konzept), Handbücher (Anwenderhandbuch, Betriebshandbuch, Schulungsunterlagen) und Installationsanweisungen enthalten sein.

Hinweise zu bekannten Fehlerzuständen, welche vom Test ausgeschlossen werden sollten beschrieben sein (bekannte und akzeptierte Fehler).

Testelemente werden in der Regel pro Testobjekt gruppiert.

 

4.3.3 Funktionen

Das Kapitel Funktionen enthält die Beschreibung der zu testenden Funktionen (Funktionsgruppen). Hier wird typischerweise auf Analysedokumente/Anforderungsdokumente verwiesen, bzw. auf eine bereits zerlegte Form (bzw. noch durchzuführende Analyse) der Anforderungsrepräsentation in einem Testmanagementtool.

Der Scope der zu testenden Funktionen kann sich von den zu entwickelnden Funktionen unterscheiden (siehe Kapitel „Nicht-Funktionen“).

Es können Aussagen zur Testpriorität von Funktionengemacht werden.

 

4.3.4 Nicht-Funktionen

Eine klare Abgrenzung der nicht zu testenden Funktionen ist erforderlich. Während im Projektantrag, bzw. den Analysedokumenten (fachliche Spezifikation und Fachkonzept) eine Abgrenzung der nicht zu entwickelnden Funktionalitäten enthält, kann sich der Umfang der nicht zu testenden Funktionalitäten davon unterscheiden.

Beispielsweise ist es möglich, dass bereits vorhandene Funktionen erneut im Zusammenhang mit den neuen Funktionen getestet werden müssen. Andererseits können neue Funktionen bewusst aus dem Testscope entfernt werden, weil sie Teil einer erwiesenermaßen funktionsfähigen Standardsoftware sind (Etwa die Sortierfunktionalität einer Liste in einer Standardsoftware; hier geht man ggf. von einer grundlegenden Funktionsfähigkeit aus. Es muss lediglich geprüft werden, ob für die angeforderte Liste die Sortierfunktionalität eingeschaltet ist.).

 

4.3.5 Teststrategie / Testansatz

Der Testansatz beschreibt die übergreifende Strategie des Testens. Hier wird die Gruppierung von Funktionen und ihre Priorisierung diskutiert. Des weiteren werden die unterschiedlichen Teststrategien (Testarten, Testtypen) sowie die Teststufen erläutert. Daraus leiten sich die Testziele pro Teststufe ab. (beispielsweise Strategien wie „erst die Teile, dann das Ganze“, indem man vom Modultest über den Systemtest zum Systemintegrationstest geht. Oder „erst intern, dann extern“, indem man die volle Funktionsfähigkeit von internen Komponenten sicherstellt, bevor teure externe Schnittstellensysteme für den Test verwendet werden.)

Welcher Testansatz für das jeweilige Projekt verwendet wird hängt von vielen Faktoren ab: Spielt die Vorgehenszielpriorität eine große Rolle, können Ressourcenoptimierung vs. Zeitoptimierung vs. Abdeckungsoptimierung eine Rolle spielen.

Weitere denkbare Ansätze wären Risikoerwägungen, welche aus Komplexitätsgesichtspunkten oder aus den erwarteten operationalen Risiken des Endsystems abgeleitet werden.

Auch Einschränkungen bei der Verfügbarkeit von speziellen Ressourcen oder Testanlagen können die Teststrategie beeinflussen.

 

Grundsätzlich sollte die Teststrategie in ausreichendem Detail beschrieben sein, so dass sich die Folgeaktivitäten der Testkoordinatoren in der Testvorbereitung danach ausrichten können.

 

Insgesamt ist dieses Kapitel das wichtigste Kapitel im Testkonzept, da hier die Weichenstellung für den gesamten Testprozess erfolgt.

Des weiteren zeigen die Erläuterungen, dass von einer zu starken Standardisierung im Projektmanagement oder im Testmanagement Abstand genommen werden muss, um optimal auf die Bedürfnisse des jeweiligen Projekts Rücksicht zu nehmen.

 

4.3.6 Testerfolgskriterien und Misserfolgskriterien

Die Definition der Testerfolgskriterien (und der Kriterien für Misserfolg) sind zu Testbeginn mit am schwierigsten sinnvoll zu definieren.

Die Folge davon ist, dass dieses Kapitel oft mit Aussagen, wie „Es dürfen maximal 10 schwere Fehler in der Software verbleiben.“

Es ist offensichtlich, dass solch abstrakte Festlegungen ohne Bezug zum Projektumfang, den kritischen Komponenten, etc. schwer sinnvoll zu definieren sind.

Eine Detaillierung im Rahmen der Testvorbereitung erscheint daher sinnvoll.

Eine wichtige Funktion haben diese Festlegungen dennoch: Sie zwingen den Auftraggeber während der Abstimmung des Testkonzepts über die möglichen Ergebnisse des Tests nachzudenken. Diese Festlegungen sollten entsprechend dokumentiert werden.

 

4.3.7 Testabbruchkriterien und Wiederaufnahmekriterien

Die verbindliche Definition von Testabbruchkriterien sind die Versicherung des Testmanagers gegen Fehlleistungen von Dritten.

Was könnte einen Testabbruch hervorrufen? Hierzu gehören Punkte wie, fehlender Annahmetest (d.h. die initiale Softwarequalität ist nicht ausreichend), fehlende Testumgebungsverfügbarkeit oder eine zu langsame Fixrate bei der Behebung von Abweichungen.

Ein häufiges Problem von Projekten ist, dass sich alle Verzögerungen des Projekts bis in die Testdurchführungsphase des Projekts akkumuliert haben, ohne dass dies vom Projektleiter eindeutig in den Teststatus und die Erwartungshaltung der Stakeholder eingepreist worden wäre.

Gerade bei Projekten mit einem fixen Endetermin (heutzutage also alle strategischen, wichtigen Projekte von Unternehmen) regiert Prinzip Hoffnung: Der Projektleiter kann (politisch) auf der einen Seite nicht in der ersten Projekthälfte schon eine Verzögerung von n Monaten kommunizieren, auf der anderen Seite hofft er, dass in der Testphase „schon nicht zu viele Fehler auftauchen“.

Dies bedeutet im Klartext, dass das Projekt bis zum Beginn der Testdurchführung ernsthafte Probleme hat, obwohl der Projektstatus „grün“ ist. Damit wird automatisch der Testmanager „schuld“, wenn der Status nun von grün nach rot springt, weil die Testziele nicht erreicht werden können.

Umso wichtiger ist eine klare Festlegung von Testabbruchkriterien.

 

Je nach Grund des Testabbruchs sollten die Tätigkeiten der Wiederaufnahme festgehalten werden. (Beispielsweise ein neuer Annahmetest, Rücksetzung der Testbasisdaten, etc.)

 

4.3.8 Ergebnistypen des Tests

An dieser Stelle im Testkonzept kann die Summe der Ergebnistypen gelistet und beschrieben werden. Je nach Projekt, können diese auch in einem übergreifenden QM-Plan, bzw. Ergebnistypenliste auftauchen und dort beschrieben werden.

 

4.3.9 Aufgaben im Test

Hier werden die Aufgaben im Rahmen der Vorbereitung und Durchführung für das spezifische Projekt identifiziert und beschrieben. Existiert ein Testmanagement-Rahmenwerk im Unternehmen, kann die Liste in vielen Fällen auf die reine Nennung der Aktivitäten im jeweiligen Projekt reduziert werden.

Da der Zweck eine Planungs- und Handlungsanweisung ist, sollten die projektspezifische Informationen natürlich beschrieben werden.

 

4.3.10 Testumgebung

Die Anzahl und die Eigenschaften der Testumgebungen sollte beschrieben sein. Dazu gehören auf der einen Seite die Hardwareeigenschaften der Testumgebung. In vielen Fällen ist die Hardware-Ausstattung der Testumgebung kleiner, als die der Produktionsumgebung, da kleiner Datenmengen getestet werden. Auf der anderen Seite können vergleichbare Last- & Performance-Tests nur bei vergleichbarer Hardwareausstattung durchgeführt werden.

Auf der anderen Seite ist die notwendige Softwareausstattung zu beschreiben, so dass die Softwarewareversorgung rechtzeitig erfolgen kann. Grundsätzlich gilt, dass die Softwareausstattung möglichst ähnlich der späteren Produktionsumgebung entsprechen soll, also insbesondere gleiche Versionen für Betriebssystem, Datenbank, …

Des weiteren müssen die verwendeten Testtools beschrieben werden. Dazu gehören technische Testtools, wie Lasttest-Software, Automatisierungssoftware, Analysewerkzeuge etc. und Testmanagement-Tools zur Verwaltung von Anforderungen, Releases, Testvorbereitung, Testdurchführung und Abweichungsverfolgung.

Nicht schon verfügbare Software muss in durch den Projektbeschaffungsprozess beschafft werden.

 

4.3.11 Verantwortlichkeiten

 

Hinter dem Testverfahren sollten klare Rollen und Verantwortlichkeiten definiert werden. Oft sind die Rollen in den Unternehmen im übergreifenden Testverfahren definiert (beispielsweise Testmanager, Testkoordinator, Testanalyst, Tester, Testumgebungskoordinator, Testberater). An dieser Stelle sind die Rollen jedoch konkret zu benennen pro Teilprojekt oder Teilbereich im Projekt mit konkreter Namensnennung.

Nicht zu vergessen sind die Verantwortlichen an den angrenzenden Prozessen, nämlich Entwickler, Entscheider beim Auftraggeber, Release Manager, Projektleiter, Projektbüro und QS-Manager.

 

4.3.12 Besetzungsbedarf und Trainingsbedarf

Im Rahmen der Testplanung ist der Personalbedarf mit der jeweiligen Qualifikation zu ermitteln. Der Besetzungsbedarf ergibt sich aus der Differenz von Bestand und Bedarf. Ggf. sind Qualifizierungsmaßnahmen einer Neubesetzung vorzuziehen. (Qualifizierungsgebot im Projektmanagement)

Für neue oder geänderte Applikationen ist ggf. spezieller Trainingsbedarf einzuplanen. Zusätzlich müssen Tester, welche von der Anwenderseiter rekrutiert werden in die Testverfahren und Abweichungsprozesse und die entsprechenden Tools eingewiesen werden.

 

4.3.1 Zeitplan

 

Die Meilensteine des Tests sind zu identifizieren und die Übergabe Punkte mit der Entwicklung abzustimmen. Hierbei greifen die regulären Planungsmechanismen des Projektmanagement.

Zusätzlich ist zu beachten, dass die Zeitplanung nicht nur durch den Umfang der erstellten Software, sondern auch von die Qualität der erstellten Software abhängig ist.

Daher kann eine Zeitplanung für Testdurchführung immer nur auf Annahmen basiert sein.

Die kontinuierliche Zeitplanung wird häufig außerhalb des Testkonzepts in den selben Dokumenten , wie die Zeitplanung des übrigen Projekts geführt.

 

4.3.14 Risiken und Puffer

Auf Grund der Abhängigkeit von äußeren Umständen sind die Risiken im Projektverlauf ständig neu zu bewerten. Zusätzlich sind entsprechende Puffer im Test vorzuhalten.

Dies kann insbesondere dann zu Schwierigkeiten führen, wenn es externe Abhängigkeiten, wie mit anderen Projekten gemeinsam verwendeten Testumgebungen gibt.

Für Risikomanagement existieren in den Projekten oft übergreifende Listen, welche sich gut für eine frühzeitige Risikokommunikation eignen.

 

4.3.15 Abnahmen

Soweit nicht im Dokumentenkopf vorgesehen, ist abschließend die Abnahme des Testkonzept festzuhalten. Die Planabnahme hat gleichzeitig die Wirkung eines Projektmandats für das Teilprojekt Test.

 

4.4 Testentwurfsspezifikation (test design specification)

Die Testentwurfsspezifikation ist ein Ergebnisdokument, das die Testbedingungen für ein Testobjekt, die detaillierte Testvorgehensweise und die zugeordneten logischen Testfälle identifiziert. Im Rahmen der Testentwurfsspezifikation wird das jeweilige Testobjekt in Testelemente (Hinweis: der Begriff Testeinheit ist nicht mehr gebräuchlich) zerlegt.

 

4.4.1 Funktionen

In diesem Kapitel werden die Testelemente des Testobjekts identifiziert und kurz beschrieben. Pro Testelement werden die zu testenden Funktionen oder Kombinationen von Funktionen beschrieben. Wichtig ist, dass die Referenz zur auslösenden Anforderung nicht verloren geht. (Forderung der Nachverfolgbarkeit (traceability)).

Typischerweise wird die Strukturierung der Testobjekte, Testelement und Einzelfunktionen in einem Testmanagementtool abgebildet.

 

4.4.2 Teststrategie

Es ist zu beschreiben, mit welcher Teststrategie (falls abweichend oder ergänzend zum Testkonzept) die Testfallermittlung und die Testdurchführung umzusetzen sind. Dazu gehört beispielsweise die Nutzung von Testdaten, die Testfallselektion (Werte und Prioritäten), Reihenfolgen und Abhängigkeiten, Fehlertoleranzen, Eingangsbedingungen, sowie Anforderungen an die Testumgebung.

 

4.4.3 Testszenarien

Hier werden die Testszenarien (auch Testprozeduren; entspricht Testfällen ohne Testdaten) ermittelt und priorisiert und kurz beschrieben. Diese Tätigkeit würde typischerweise auch in einem Testmanagementtool stattfinden.

Auf Basis der priorisierten Testszenarien werden später die Testfälle definiert.

 

4.5 Testfallspezifikation (test case specification)

Die Testfallspezifikation ist ein Dokument, welches eine Menge von Testfällen für ein Testobjekt spezifiziert (inkl. Testdaten und Vor-/Nachbedingung), bei dem die Testfälle jeweils Ziele, Eingaben, Testaktionen, vorausgesagte Ergebnisse und Vorbedingungen für die Ausführung enthalten.

Die Testfallspezifikation würde typischerweise in einem Testmanagementtool hinterlegt werden.

Zweck der Testfallspezifikation ist das detaillieren der Testszenarien für ein Testobjekt zu konkreten Testfällen.

Am Ende des Kapitels geben wir ein Beispiel für einen Testfall.

 

4.5.1 Funktionen

Hier wird beschrieben, welche Testelemente und welche Funktionen Gegenstand der Testfallspezifikation sind. Es sollte eine Referenz zu der Anforderungsdokumentation, zur Designdokumentation (DV-Konzept), sowie zu relevanten Handbüchern gegeben werden.

 

4.5.2 Eingabewerte

Beschreibung der Eingabewerte für einen Testfall.

 

4.5.3 Ausgabewerte

Beschreibung des erwarteten Ergebnisses für einen Testfall.

 

4.5.4 Anforderungen an die Testumgebung und Tester

Beschreibung der Hardwareanforderungen (beispielsweise bei Lasttests) und Softwareanforderungen für die Ausführung der Testfälle.

Beschreibung von Anforderungen an den Tester (Skills) und seine Berechtigungen auf der Testanlage.

 

1.5.5 Prozedurale Anforderungen oder Abhängigkeiten zwischen den Testfällen

Beschreibung von Einschränkungen oder anderen Hinweisen, welche zur Ausführung des Testfalls notwendig sind. Nennung von Vorgängertestfällen und Begründung für die Abhängigkeit.

 

4.5.6 Beispiel Testfallspezifikation

Testfall-ID

Depot.Kauf.27

Version

12

Status

Abgenommen

Funktionen

Test der Kauf-Maske im Depotsystem, gemäß Anforderung 762_Depot_Kauf_Fremdwährung

Testszenario: Depot.Kauf

Testumgebung

Testumgebung mit Online-Schnittstelle zum Test-Order-System erforderlich

Tester benötigt Berechtigung für WP-Kauf, sowie Verantwortlichkeit bis 100.000 Euro.

Abhängigkeit

Testfall Depot.Kunde.anlegen.26 muss vorher ausgeführt worden sein, da dort die Kundenstammdaten angepasst werden.

Testeingabedaten

Kunde „Hans Meier“, Depot 104.567.111

Wertpapier „IBM“

Börse „NY“

Menge „17“

Ausgabewerte

- Kauf von 17 IBM Aktien in NY im Kauflog sichtbar

- Betrag zu Tageskurs von Kundenkonto entnommen

- Spesen und Courtage von 10EUR vom Kundenkonto entnommen

- Ausdruck im Briefcenter mit Bestätigungsschreiben

 

4.6 Testablaufspezifikation (test procedure specification)

Ein Dokument, das eine Folge von Schritten zur Testausführung festlegt. Hier wird also das jeweilige Testszenario im Detail ausformuliert und dem Tester eine konkrete Handlungsanweisung gegeben.

Zunächst hat jede Testablaufspezifikation (Testszenario) einen Kopfbereich mit übergreifenden Informationen.

 

4.6.1 Zweck

Hier wird der Zweck des Testszenarios beschrieben.

 

4.6.2 Anforderungen

Hier werden notwendige Anforderungen an Testumgebung, Testdaten, Tester, Testberechtigungen, etc. beschrieben.

 

4.6.3 Testschritte

Die Testschritte enthalten die konkreten Schritte für die Testausführung. Im Wesentlichen sind das:

ID, Testanweisung, Erwartetes Ergebnis.

Der Standard IEEE829 schlägt noch zusätzlich folgende Informationen vor: Beschreibung der Methode der Testdokumentation, vorausgehende Aktivitäten (anderer Testfall oder Login ins System, …) , notwendige Aktivitäten zum Start des Testfalls (z.B. Aufruf einer Transaktion), Beenden des Testfalls und Wiederanlaufmaßnahmen, Beenden eines Testfals, Abbruch eines Testfalls.

Typischerweise würde man solche Informationen im Kopfbereich oder in Testschritten hinterlegen. Viele der Zusatzinformationen machen nur in speziellen Szenarien Sinn.

 

4.7 Release Note (test item transmittal report)

Die jeweilige Release Note ist ein Dokument, das im Rahmen der Übergabe von der Entwicklung zum Test zu Beginn der Testdurchführung die Testobjekte identifiziert, ihre Konfiguration, aktuellen Status und andere Informationen.

Die Release Note ist die notwendige Voraussetzung für den Tester, damit er weiß, was er testet.

 

Neben der reinen Nennung der übergebenen Testobjekte ist eine Liste der inzwischen behobenen Abweichungen und eine Auswirkungsanalyse auf bereits gelieferte oder schon vorhandene Testobjekte unerlässlich.

 

Den Release Notes kommt im Testprozess eine besondere Bedeutung zu, da sie ein Dokument sind, welches in der Regel nicht durch die Tester, sondern durch die Entwickler erzeugt werden muss. Hier muss das Verständnis für die Notwendigkeit von Release Notes meist erst mühsam erkämpft werden.

 

4.7.1 Übergebene Testobjekte oder Testelemente

Nennung der übergebenen Testobjekte (oder Testelement) mit ihrer jeweiligen Versionskennzeichnung und Hinweisen zur Art der letzten Bearbeitung.

Beispielsweise welche ausstehenden Funktionalitäten implementiert wurden oder welche Fehler behoben wurden.

Es hat sich in der Praxis als hilfreich erwiesen, wenn die Liste der übergebenen Testobjekte/Testelemente automatisch während dem Übergabeprozess (Deploymentprozess) erzeugt wird. Auf diese Weise können Abweichungen auf Basis einer fehlerhaften (falsche Version) Übergabe schneller identifiziert werden.

 

4.7.2 Ort der Übergabe

Da in den Projekten oft mehr als eine Testumgebung verwendet wird, ist es unerlässlich festzuhalten, auf welche Umgebung eine Übergabe stattgefunden hat.

 

4.7.3 Status

Der Status der übergebenen Elemente sollte bekannt sein.

 

4.7.4 Abnahmen

Eine Übergabe ist ein formaler Akt, der in aller Regel über einen Abnahmeprozess passiert. Beispielsweise könnte in den Release Notes das Ergebnis der Annahmetests dokumentiert werden, bevor die Release Notes an die „anderen Tester“ weitergegeben wird und die Testumgebung zum Test freigegeben wird.

 

4.7.5 Auswirkungsanalyse

Zu jedem übergebenen Objekt sollte eine Auswirkungsanalyse durch den jeweiligen Entwickler/Architekt abgegeben werden.

Auf diese Weise wird die Testfallselektion für den Retest von bereits bestehenden und getesteten Funktionalitäten optimiert werden.

Eine späte Identifikation von Fehlern auf Basis von nicht erkannten Quereffekten ist oft auf eine fehlende Auswirkungsanalyse in den Release Notes zurückzuführen.

 

4.7.6 Behobene Fehler

Insbesondere wenn die Zuordnung von Abweichungen zu Testobjekten nicht eindeutig durch den Tester vorgenommen werden kann, ist es notwendig, dass die behobenen Fehler pro Übergabe genannt werden.

Obwohl der Status Fehler in der Regel über das Testmanagementtool zu verfolgen ist, ist es eine oft vorkommende Fehlerquelle, dass unklar ist, in welcher Übergabe (Deployment) der korrigierte Code zum Retest bereit steht.

 

 

4.8 Testprotokoll (test log)

Das Testprotokoll ist eine chronologische Aufzeichnung von Einzelheiten der Testausführung.

 

4.8.1 Beschreibung

Übergreifende Informationen, welche für alle Einträge im Testprotokoll gültig sind. Dazu gehören die Testobjekte, Testläufe, verwendete Testumgebung, etc.

Typischerweise ist das Testprotokoll implizit in der Datenbank des Testmanagementtools enthalten.

 

4.8.2 Daten

Die abgelegten Detailinformationen entsprechen denen des Testfalls, wobei zusätzlich das tatsächliche Ergebnis eines Testschritts, die Bewertung des Vergleichs zwischen erwartetem und tatsächlichen Ergebnis (Testerfolg, Abweichung) und der Tester zu hinterlegen ist.

 

4.8.3 Abweichungsidentifikation

Im Falle einer Abweichung ist die Identifikation des Abweichungseintrags zu hinterlegen. Dies ermöglicht dem Bearbeiter der Abweichung den Testverlauf nachzustellen, was die Fehlersuche unterstützen kann.

Testmanagementtools verknüpfen Abweichung und Testfall/Testschritt im Testlauf in der Regel automatisch.

 

4.9 Fehler- und Abweichungsbericht (test incident report)

Der Fehler- und Abweichungsbericht ist ein Dokument, das alle Ereignisse auflistet, die während des Testens aufgetreten sind und untersucht werden müssen.

Auch die Verfolgung von Fehlern und Abweichungen findet meist über ein Testmanagementtool oder zumindest eine einfache Fehlerverfolgungsdatenbank (bug tracking tool) statt .

 

4.9.1 Identifikation

Der Abweichungseintrag muss eindeutig identifiziert sein. In der Regel wird dies über eine fortlaufende Fehlernummer (defect id) ermöglicht.

Zusätzlich verfügt der Fehlereintrag über einen Bearbeitungsstatus. Die Versionierung wird implizit über die Historisierung aller Aktivitäten ermöglicht.

Durch die Besonderheit, dass der Abweichungseintrag fortlaufend bearbeitet wird, reicht es nicht aus, die „alten Versionen“ zusätzlich zugänglich zu machen. Stattdessen sollte die komplette Historie laufend einsehbar sein (usability).

Des weiteren sollte die jeweilig übergreifende Einheit eindeutig zugeordnet sein: Für den Abweichungseintrag sind das der zugehörige Testfall, sowie der Testlauf indem die Abweichung identifiziert wurde.

 

4.9.2 Abweichungsinformationen

Für jede Abweichung sind folgende Informationen zu erfassen:

· Eingaben (bzw. Verknüpfung zum Testprotokoll)

· Erwartetes Ergebnis (bzw. Verknüpfung zum Testprotokoll)

· Tatsächliches Ergebnis (bzw. Verknüpfung zum Testprotokoll)

· Abweichungsbewertung (bzw. Verknüpfung zum Testprotokoll)

· Datum/Zeit (bzw. Verknüpfung zum Testprotokoll)

· Jeweilige Testschritte (bzw. Verknüpfung zum Testprotokoll)

· Testumgebung (bzw. Verknüpfung zum Testprotokoll)

· Tester (bzw. Verknüpfung zum Testprotokoll)

· Bewertung und weitere Analysen

· Einschätzung zur Kritikalität und Priorität

 

Es sind außerdem alle weiteren Informationen zu erfassen, welche eine schnelle Abweichungsanalyse und Fehlerbehebung ermöglichen (beispielsweise Screenshots).

 

4.9.3 Auswirkungen

Im Rahmen der Abweichungsanalyse sind die Auswirkungen zu bestimmen und zu dokumentieren. Dadurch kann beispielsweise Aufwand für Folgetests verhindert werden, welche unweigerlich in einen Folgefehler laufen würden.

 

4.10 Testbewertungsbericht (test summary report)

Der Testbewertungsbericht ist ein Dokument, das zum Abschluss eines Testprojekts erstellt

wird und sämtliche Testaktivitäten und Ergebnisse zusammenfasst. Es enthält auch eine Bewertung des Testprozesses und einen Erfahrungsbericht.

In der Praxis gibt es Zwischenstufen, so kann zum Ende jeder Teststufe ein Testbewertungsbericht erstellt werden, welcher die Entscheidung unterstützt, ob die Testendekriterien der jeweiligen Teststufe erreicht wurden.

Gibt es mehrere Bericht läuft der letzte Bericht auch unter dem Titel Testabschlussbericht.

 

4.10.1 Überblick der Testaktivitäten

Die Zusammenfassung enthält einen Überblick über die Prüfung der Testobjekte (mit Versionierung und Status), sowie Informationen auf welcher Testumgebung die Testaktivitäten durchgeführt wurden.

Dabei werden die Testergebnisse je Testelement oder je Testobjekt dargestellt.

Die relevante Testdokumentation (Testlaufdokumentation, Release Notes, …) wird referenziert.

 

4.10.2 Inhaltliche Abweichungen

Inhaltliche Abweichungen zwischen der ursprünglich spezifizierten Anforderung werden beschrieben, um eine Bewertung der erstellten Software zu ermöglichen.

Abweichungen werden erklärt.

 

4.10.3 Testabdeckung

Erläuterung der tatsächlichen Testabdeckung. Abweichungen zwischen der ursprünglich geplanten Testabdeckung im Testkonzept und der tatsächlichen Testabdeckung sind zu erläutern.

 

4.10.4 Zusammenfassung der Testergebnisse

Eine textuelle Zusammenfassung der Testergebnisse für die Testelemente. Nennung der offenen Abweichung..

 

4.10.5 Bewertung

Bewertung der Wahrscheinlichkeit eines Versagens der Komponenten in Produktion. Eine Bewertung der Testergebnisse und eine Empfehlung über eine Go/No Go Entscheidung aus Sicht des Testmanagement.

 

4.10.6 Zusammenfassung der Testaktivitäten

Beschreibung der wichtigsten Testaktivitäten und Vorkommnisse. Nennung des Ressourcenverbrauchs (Personentage und ggf. Maschinenkapazität).

 

4.10.7 Abnahme des Dokuments

Unterschrift des Testmanagers.

 

4.11 Weitere Dokumente: Testanweisungen

Nicht im IEEE Standard vorgesehen, bei wechselnden Besetzungen der Tester jedoch unumgänglich sind die Testanweisungen.

Sie dienen zur Einführung der Tester in das Projekt und enthalten alle relevanten Informationen. Da Tester meist nur für einen – im Verhältnis zur Gesamtlaufzeit – kurzen Zeitraum im Projekt mitarbeiten, können sie sich in der Regel nicht durch die gesamte Dokumentation hindurch lesen. Daher werden in den Testanweisungen redundant die relevanten Informationen zusammengefasst. Stellt sich das Unternehmen mit festen Testteams auf, können die Inhalte stark gekürzt werden oder sogar auf die Testanweisungen verzichtet werden.

 

Neben den testspezifischen Themen können auch organisatorische Fragen beantwortet werden.

Die wird beispielsweise dann relevant, wenn die Tester von anderen Standort zusammen gezogen werden. (Standort Kantine, …)

4.11.1 Projektinformation

Die Testanweisungen beginnen mit allgemeinen Informationen zum Projekthintergrund, zum Ablauf und zum Projektteam.

4.11.2 Testprozesse

Die relevanten Testprozesse (Testausführung und Abweichungsmanagement) werden dargestellt. Des weiteren werden Informationen zur Ablage der Testfälle und ggf. zum Zugriff auf externe Testdaten geliefert.

4.11.3 Organisatorische Themen

Hier wird die das Testteam in Einzelnen mit Aufgaben/Rollen/Verantwortlichkeiten benannt. Des weiteren wird die Testinfrastruktur (Testlabor, Testumgebungen, Testtool, Testdaten) vorgestellt.