Metriken und Testreporting

  • Frank Witte
Chapter

Zusammenfassung

Beim Testreporting werden Metriken zur Verdeutlichung von Sachverhalten einbezogen. Für ein erfolgreiches Testreporting sind dabei einige Punkte zu beachten.

Metriken werden in den Teststatusbericht eingebunden, um die aktuelle Entwicklung und den aktuellen Projektstatus aufzuzeigen.

Aus dem Teststatusbericht sollen folgende Informationen über den aktuellen Stand der Testaktivitäten hervorgehen:
  • Testobjekt(e): Teststufe, Testzyklus, betrachteter Zeitraum

  • Testfortschritt: geplante, durchgeführte, nicht durchgeführte bzw. blockierte Tests

  • Fehlerstatus: neue, offene, behobene Fehler nach Schwere und Priorität

  • Risiken: neue, offene, bekannte Testrisiken nach Priorität

  • Ausblick: Planung und Prognose des nächsten Testzyklus und weiterer Testphasen

  • Gesamtbewertung: (subjektive) Beurteilung des Testobjekts hinsichtlich Freigabereife bzw. Grad des erreichten Vertrauens in das Testobjekt [Spil2007]

28.1 Sichtweisen beim Testreporting

Eine wesentliche Aufgabe beim Testreporting ist die Feststellung des aktuellen Status des Testprozesses, um mögliche Schwachstellen im Projekt zu identifizieren und möglicherweise Gegenmaßnahmen einleiten zu können. Aktuelle und vor allem detaillierte Momentaufnahmen können dabei unterstützen. Beim Testreporting ist eine empfängerbezogene Darstellung der aufbereiteten Informationen zu beachten. Dazu muss die richtige Gruppierung (zum Beispiel in Teilprojekte, Systeme oder Prioritäten) für die richtigen Adressaten gefunden werden.

Ein weiterer wichtiger Punkt ist die Prognose über den weiteren Projektverlauf und den Projektausgang. Diese Prognose wird einerseits aus den historischen Projektdaten, andererseits aus bekannten Risiken abgeleitet. Die Einschätzung des Risikos hängt dabei stark von den Erfahrungen des Testmanagers ab. Für diese Prognose wird in der Regel eine zeitliche Darstellung genutzt.

Die Grundlage beider Aufgaben stellt die Qualität der verfügbaren Daten dar. Hierfür ist ein internes Kontrollsystem (im folgenden IKS genannt) nötig, um das Vertrauen ins Testreporting zu erhöhen und zu festigen. Status als auch Prognose dienen hierbei dem Testreporting nach außen, das IKS als regulatorisches Mittel innerhalb des Testteams.

Wenn man die grob unterteilten Testphasen Testvorbereitung, Testdurchführung und Fehlerbehebung mit den beschriebenen Sichtweisen verknüpft, erhält man die in Tab. 28.1 gezeigte Matrix.
Tab. 28.1

Matrix des Testreportings

 

Testvorbereitung

Testdurchführung

Fehlerbehebung

Status

   

Prognose

   

IKS

   

Der Testmanager soll sich für die vollständige Darstellung an dieser 3 × 3-Matrix orientieren, um alle Aspekte des Testprozesses und die Erwartungen an die Metriken zu erfüllen. Ziel ist es, jede dieser neun Kategorien durch einen Report abzudecken.

Sind im Testreporting nicht alle neun Kategorien dargestellt, werden spezielle Aussagen nur unzureichend dargestellt und die Entscheidungsgrundlage ist unvollständig. Existieren mehrere Grafiken zu einer Kategorie, kann das zu Redundanzen oder auch zu Widersprüchen führen. Dadurch wird die Aussagefähigkeit des Testreports geschwächt und die Akzeptanz als zielführendes Instrument sinkt. Ein gutes Berichtswesen deckt daher alle Phasen und Sichten der 3 × 3-Matrix durch entsprechende Statistiken oder Charts ab. [Tesg2012]

Beim Testreporting sind einige Punkte besonders zu beachten:

28.2 Zeitraum der Betrachtung

Sinnvoll sind im Allgemeinen Metriken auf Wochenbasis. Auf Tagesbasis sind die Schwankungen oft zu groß, um sinnvolle Aussagen liefern zu können, so dass Metriken pro Tag nur bei sehr hoher Dynamik oder besonders kritischen Projektphasen erforderlich sind. Auf Monatsbasis sind die Daten zu weit auseinander, um rechtzeitig auf eventuelle Probleme reagieren zu können.

Der Zeitraum der Betrachtungen sollte nicht mehr als ein halbes Jahr betragen, denn bei einer zu hohen Anzahl an wöchentlichen Daten wird das Reporting unübersichtlich. Es empfiehlt sich dann, die historischen Daten, die bereits einige Monate zurückliegen, im Report abzuschneiden. Da die alten Metriken ohnehin archiviert werden, könnte man im Bedarfsfall Informationen über vergangene Zeiträume immer noch hervorholen. Man kann im Nachhinein die Zeiträume der Analyse verdichten (zum Beispiel Januar, Februar, März als monatliche Zusammenfassung, ab April wochenweises Reporting).

Ein relativ triviales Problem entsteht dadurch, dass nicht in allen Wochen komplett gearbeitet wird, z. B. sind KW52 oder KW1 (zwischen Weihnachten und 6. Januar) Kalenderwochen, in denen es in vielen Branchen keinen großen Testfortschritt geben wird, genauso in Wochen mit „Brückentagen“ (z. B. Woche mit Christi Himmelfahrt: es sind produktiv oft nur 3 Arbeitstage statt 5). Das bedeutet aber, dass der Aufwand für das Reporting dadurch proportional steigt bzw. Daten über die Produktivität angepasst werden müssen, sonst ergibt sich ein schiefes Bild. Eventuell ist es daher angebracht, die Daten z. B. von KW51, KW52 und KW1 zu einem Wert zusammenzufassen.

Man sollte nicht unterschätzen, wie sehr gerade triviale Probleme Nervosität erzeugen. Oft werden Daten ungenügend hinterfragt, man nimmt sich zu wenig Zeit, um hinreichend ins Detail zu gehen, was entweder zu übertriebenem Aktionismus führt (somit evtl. zu noch mehr Reporting und noch weniger Arbeitsfortschritt!) oder dazu, sich zu früh in Sicherheit zu wiegen.

28.3 Historie von Metriken anpassen

Oft kommen Parameter, über die berichtet werden soll, erst im Laufe des Projekts hinzu. Das bedeutet, dass man sie normalerweise ab einem bestimmten Tag erhebt.

Beispiel: Die Anzahl der getesteten Testfälle pro Woche wird seit KW10 betrachtet. Da im Laufe der Testaktivitäten mehr und mehr Fehler erfasst werden, beschließt man ab KW20 zusätzlich, die Anzahl der neu entdeckten Fehler pro Woche zu erheben.

Im Allgemeinen reicht eine Anpassung der Metrik für die Zukunft. Historische Werte (in diesem Fall die neu entdeckten Fehler in KW10 bis KW19) sind dann reine Vergangenheitsbewältigung und nützen für die nächsten Wochen in der Regel nur wenig. Manchmal ist es ohnehin schwierig, diese Historie für vergangene Wochen noch exakt zu ermitteln.

28.4 Metrik fehlerhaft

Es kommt gar nicht so selten vor, dass die Interpretation der in der Metrik zu berichtenden Werte von Anfang an fehlerhaft war. So kann es z. B. vorkommen, dass die Anzahl der zu testenden Anforderungen in unterschiedlichen Teststufen nachzuweisen ist (etwa in einem Softwaretest und einem Gesamtsystemtest), und dass die Reviews der Anforderungen zusätzliche Zeit beanspruchen. Oftmals wird in der Praxis aber gar nicht strikt nach dem V-Modell gearbeitet, sondern die einzelnen Aktivitäten überlagern sich. Es kommt zum Beispiel relativ häufig vor, dass die Systemarchitektur erst nach der Entwicklung fertig wird, oder auch Unit-Tests erst nach dem Integrationstest vollumfänglich beschrieben und durchgeführt werden. Das bedeutet eine nachträgliche Anpassung der Metriken.

Bei dieser Vorgehensweise kann man zum Entschluss kommen, dass man die erhobenen Werte pro Woche neu bewerten muss. In der historischen Betrachtung kann es zu Effekten kommen, dass dabei ein bestimmter Wert geringer ist als vorher und dadurch ein unplausibler Verlauf in der zeitlichen Betrachtung entsteht. Ein Beispiel zur Anzahl getesteter Anforderung ist in folgender Grafik (Abb. 28.1) dargestellt.
Abb. 28.1

Anzahl getestete Anforderungen

Die Anpassung der Werte der im Systemtest nachgewiesenen Kundenanforderungen sinkt in diesem Beispiel in KW18 wegen der geänderten Bewertung auf 317, vorher lag sie bei 354. Der Originalplan und der aktuelle Plan (falls erhoben) müssen sich deswegen ebenfalls ändern. Kurvenverläufe wie hier beschrieben müssen in jedem Fall plausibel erklärt werden. Ansonsten wäre die hier präsentierte Metrik unglaubwürdig.

Man kann bei Metriken, die in der Vergangenheit fehlerhaft einen falschen Wert, z. B. einen zu großen Fortschritt, dargestellt haben, entweder den Wert der vorhergehenden Metriken anpassen. Dann muss einem aber bewusst sein, dass die früheren Metriken obsolet sind. Oder aber man stellt einen „Knick“ dar wie in der Kurve in Abb. 28.1 und behält dadurch die früher bereits berichteten Werte bei. Eine nachträgliche Erklärung der Daten benötigt man aber generell. Metriken, die nicht mehr gültig sind, sollten deutlich sichtbar (etwa mit einem auffällig groß geschriebenen Kommentar oder Balken über die gesamte Seite der Metrik) als ungültig markiert werden, sonst werden die Daten versehentlich später doch einmal zum Reporting herangezogen. Problematisch ist jedoch, dass die eigene Glaubwürdigkeit sinkt, wenn man Metriken im Nachhinein anpassen muss. Das Management wird sich in diesem Fall nämlich fragen, inwiefern den Zahlen aus dem Systemtest überhaupt Vertrauen entgegengebracht werden kann, und ob die neuerliche Bewertung nun wirklich korrekt ist oder noch weitere Fehler in der Betrachtung stecken. Das ist besonders dann von Bedeutung, wenn ein angestrebter Endtermin verschoben werden muss, denn zu diesem Zeitpunkt kommt sofort die Frage auf, ob mit der Verschiebung nun eine verlässliche Planung vorhanden oder ob schon bald eine neue Anpassung vorzunehmen ist. Es ist in diesem Zusammenhang dem Testmanager zu empfehlen, lieber einmal eine großzügigere Terminverschiebung (mit dann sicheren Daten) vorzunehmen, anstatt in einer „Salamitaktik“ immer wieder kleine Verschiebungen vorzubringen.

28.5 Probleme bei der Testfortschrittsbetrachtung

Bevor die Testdurchführung starten kann, sind in der Regel Konfigurationsarbeiten oder Vorbereitungen der Testumgebung erforderlich. Diese Tätigkeiten fallen nicht nur am Anfang des Projekts an, wo sie mit Hilfe von Metriken zur Testvorbereitung (siehe das entsprechende Kapitel) erhoben werden sollen.

Hin und wieder sind diese Änderungen auch mitten in einer zu testenden Version bezüglich der Konfiguration des Testsystems erforderlich. Diese Arbeiten nehmen manchmal mehrere Tage in Anspruch, so dass man dadurch z. B. keinen Fortschritt an durchgeführten Testfällen in der Metrik ausweisen kann. Dennoch sind diese Arbeiten ja dringend notwendig, um überhaupt den Test beginnen oder fortführen zu können und sie sind dann – entweder als erklärender Text, oder (besser) als eigene Aktivität in einer besonderen Metrik – klar hervorzuheben.

Ein weiteres Problem kann sich ergeben, wenn Testfälle zunächst mit OK getestet wurden, aber nachträglich als nicht erfolgreich gewertet werden müssen. Das kann zum Beispiel sein, wenn Anforderungen nur unzureichend oder fehlerhaft umgesetzt wurden und die System- und die Testfallbeschreibung dadurch genauso falsch waren wie die Implementierung. In diesem Fall fällt der Fehler zunächst nicht auf, denn es wurde falsch umgesetzt und das in Wahrheit falsche Ergebnis folgerichtig als richtig bewertet.

Das zeigt wieder einmal eindrücklich, wie wichtig es ist, eine stabile Basis an Kunden- und Systemanforderungen zur Verfügung zu haben. Leider ist aber tendenziell genau das der Bereich, in den nach wie vor viel zu wenig Energie investiert wird.

28.6 Andere Betrachtungszeiträume

Angenommen, die Metriken enthalten jeweils die Werte pro Kalenderwoche bis einschließlich Freitag. Nun steht aber am Donnerstag ein wichtiges Meeting an und man will eine Momentaufnahme für den Teststatus zum Arbeitsende vom Mittwoch reporten.

Das kann man einmalig machen, sollte aber diesen Betrachtungszeitraum bei folgenden Regelterminen wieder entfallen lassen. Schließlich muss beim außerplanmäßigen Reporting explizit darauf hingewiesen werden, dass der Betrachtungszeitraum geändert wurde.

28.7 Empfohlener Reporting-Rhythmus

Es empfiehlt sich, das Reporting wochenweise durchzuführen und die Daten zum Ende der Arbeitswoche (freitagnachmittags) zu erheben. Für den Montag empfiehlt sich daher die Sammlung der Daten, die Vorbereitung der Slides und die Formulierung der Testberichte. Der Vortrag in einem Project Review sollte idealerweise spätestens am Dienstag stattfinden.

Am Dienstag ist noch genügend Zeit, für die laufende Woche Gegenmaßnahmen einzuleiten. Wenn das Reporting später in der Woche stattfindet (z. B. am Freitag, aber Betrachtungszeitraum bis Freitag zur Vorwoche), sind die Daten schon zu stark veraltet und normalerweise bereits Aktionen eingeleitet und umgesetzt. Entweder würde man beim Reporting am Freitag mit dem Gegensteuern zu lange warten oder aber die Maßnahmen wären gar nicht mehr zeitgemäß, weil sich in der Vorwoche aufgezeigte Probleme inzwischen wieder erledigt haben oder sich die kritische Situation inzwischen weiter zugespitzt hat.

Besonders schwierig wird es bei der projekt- oder unternehmensweiten Präsentation von Metriken, wenn die Betrachtungszeiträume unterschiedlich sind: Wenn z. B. der Fortschritt bei der Programmierung am Mittwoch, aber der Fortschritt bei der Testdurchführung am Freitag pro Kalenderwoche gemessen wird. Wenn die Basis nicht eindeutig festgelegt ist, ist hier eine weitere Quelle für Missverständnisse gelegt.

Meist kann der Reporting-Rhythmus vom Tester gar nicht beeinflusst werden, sondern wird zentral vorgegeben oder (was wesentlich schlimmer ist) das Reporting wird nur unregelmäßig durchgeführt.

Manchmal werden in der Praxis beim Reporting Ergebnisse „geschönt“: Wenn die Fertigstellung einer Testreihe zu Ende KW10 vorgesehen war, das Reporting aber erst am Dienstag KW11 durchgeführt wird und die letzten notwendigen Tests erst montagvormittags in KW11 abgeschlossen wurden, werden sie vielleicht eher KW10 zugeschlagen, als ein zu spätes Erreichen des Ziels zu berichten. Das ist aber streng genommen falsches Reporting. Es ist verständlich, dass man dann, wenn das Problem ohnehin schon erledigt ist, nicht noch zusätzliche Nachfragen erzeugen will. Man muss aber bedenken, dass durch die Verzögerung eventuell andere Aktivitäten erst verspätet starten konnten und die fehlerhafte Planung nicht mehr kritisch hinterfragen kann. Wenn man Fortschritte besser darstellt als sie waren, muss man sich nämlich bewusst sein, dass man beim nächsten Reporting eventuell noch mehr Verzug darstellen muss, den man dann nicht mehr ohne weiteres aufholen und verstecken kann.

Leider besteht immer wieder die Angst, schlechte Nachrichten überhaupt zu verbreiten. Man hat immer noch die Befürchtung, der Überbringer der schlechten Nachricht werde geköpft wie der reitende Bote im Mittelalter. Dadurch kommt es dazu, dass häufig zu viele Probleme ausgefiltert werden und das Management gar nicht erreichen. Bei jeder weiteren Reportingstufe in der Hierarchie nach oben werden bei der Verdichtung der einzelnen Projektstatus eher die Erfolge berichtet, als die Probleme vorgetragen. Das liegt daran, dass viele Personen im mittleren Management nicht im Detail mögliche Gegenmaßnahmen beurteilen können und grundlegende Probleme, die längst erkannt sind, gar nicht adressiert werden, denn es könnte ja auf den Abteilungs- oder Bereichsleiter zurückfallen.

Schwierig wird es auch, wenn spontan bei einem Meeting irgendeine Metrik gezeigt werden soll, um einen bestimmten Sachverhalt zu erläutern. Das hatte ich leidgeprüft im Rahmen eines SPICE®-Assessments selber einmal erlebt, bei dem ich voll daneben lag – die eilig herausgezogene präsentierte Metrik war nicht geeignet, um das Problem exakt zu beleuchten, und führte zu einer Schwäche des gesamten Prozesses, trotz ansonsten guter Vorbereitung des Assessments. Man sollte immer genau definieren, welche Metrik wann wem präsentiert werden kann.

28.8 Zusammenfassung von Metriken in einer Metrik

Um nicht zu viele einzelne Metriken präsentieren zu müssen und den Status eines Testprojekts auf einem Blick darzustellen, empfiehlt es sich, vor allem in kleineren Projekten, mehrere Metriken in einer Grafik zusammenzufassen.

Im nachfolgenden Beispiel wird eine Metrik zu Testspezifikationen und Testdurchführung zusammengefasst (siehe Tab. 28.2 und Abb. 28.2). Sobald die Testspezifikation zu einem Teilsystem oder einer Gruppe von Funktionen annähernd fertig ist und die beabsichtigten Testfälle (abgesehen von den explorativen Testfällen, die man während der Testdurchführung ermittelt) beschrieben sind, kann man mit diesem Teilsystem mit der Testdurchführung beginnen, während man die Testfälle zu anderen Funktionen oder Teilsystemen noch parallel davon beschreibt.
Tab. 28.2

Metrik der Testdokumente

 

KW 36

KW 37

KW 38

KW 39

KW 40

KW 41

KW 42

KW 43

KW 44

KW 45

KW 46

Testspezifikation Original-Plan

0,15

0,25

0,4

0,6

0,75

0,9

1

1

1

1

1

Testspezifikation Aktueller Plan

0

0,1

0,2

0,4

0,45

0,65

0,85

1

1

1

1

Testspezifikation Ist

0

0,1

0,2

0,4

0,45

0,65

     

Testfallerstellung Original Plan

0,05

0,1

0,2

0,4

0,6

0,8

0,9

1

1

1

1

Testfallerstellung Aktueller Plan

0

0

0,1

0,2

0,3

0,5

0,6

0,8

0,9

1

1

Testfallerstellung Ist

0

0

0,1

0,2

0,3

0,5

     
Abb. 28.2

Metrik der Testdokumente

Der Wunsch, möglichst wenige Charts mit verdichteten Informationen zu erhalten, ist nachvollziehbar. Je komplexer und vielfältiger Projekte werden, umso weniger ist es einem Projektmanager oder einem Verantwortlichen im mittleren oder höheren Management möglich, sich haufenweise Folien zu betrachten. Gerade deswegen ist es umso wichtiger, die Darstellung zu reduzieren. Das Weglassen von Informationen gestaltet sich in der Regel weitaus schwieriger als das Hinzufügen. Außerdem muss man bei einer Verdichtung von Daten deren Basis genau definieren, um nicht unterschiedliche Sachverhalte zu vermengen und dadurch einen ungenauen und vernebelten Blick auf die Realität zu bekommen.

28.9 Sonstige Metriken

Neben den erwähnten Metriken zur Testplanung, Testdurchführung, Testautomatisierung oder Abbau von Fehlern kann es außerdem von Interesse sein, Offene-Punkte-Listen, die im Projekt geführt werden, wochenweise zu bearbeiten und den Abarbeitungsstand regelmäßig zu bewerten. In der Definition der Reportingthemen kann man individuell wählen, welcher Sachverhalt von Interesse ist. Man kann dabei z. B. auch die Entwicklung von Indexwerten oder Kennzahlen über mehrere Zeitperioden oder im Vergleich mit mehreren Projekten betrachten.

28.10 Projektampel

Das Reporting zu einem Softwareprojekt füllt normalerweise mehrere Folien: Anforderungsmanagement, Systemarchitektur, Softwareentwicklung und Test berichten mit Hilfe von Metriken über ihren aktuellen Bearbeitungsstand. Für einen Manager ist es wichtig, die wesentlichen Punkte auf einen Blick übersichtlich dargestellt zu bekommen und schnell erkennen zu können. Leider ist häufig zu wenig Zeit, um die Ursachen für Fehlentwicklungen wirklich zu erforschen und nachhaltig gegenzusteuern. Häufig macht aber auch das Reporting die wirklichen Probleme nicht hinreichend evident.

Erfahrungsgemäß ist darauf zu achten, dass die Probleme nicht nur technisch, sondern auch kaufmännisch bewertet werden: Was bedeutet es, wenn eine Verlinkung von den Requirements zu den Testfällen nicht einwandfrei gegeben ist? Was bedeutet es, wenn die Testabdeckung mangelhaft ist, wie hoch ist das Risiko (in EUR) zu bewerten? Das ist zwar in vielen Fällen nur annäherungsweise möglich, aber man kann immerhin eine Tendenz angeben. Probleme bleiben sonst zu sehr auf der technischen Ebene und werden dadurch vom Management, das nicht in den Details der Implementierung und des Testprozesses steckt (und das auch gar nicht leisten soll), fehlinterpretiert. Wenn reale Summen, die in Geld bewertet sind, im Report erscheinen, wird die Problematik evidenter und bewusster.

Es empfiehlt sich, den Gesamtstatus der Testaktivitäten im Überblick zu bewerten, um im Detail den Stand der Aktivitäten nachzuweisen. Eine „ Projektampel “ wie in Abb. 28.3 hat sich dazu bewährt.
Abb. 28.3

Projektampel

Manchmal werden auch die wesentlichen Kriterien
  • Funktionalität,

  • Termine und

  • Kosten

per Projektampel im Rahmen des regelmäßigen Testreportings einzeln bewertet.

In der Praxis werden die einzelnen Status meist eher von einem Bauchgefühl bewertet. Man sollte jedoch Kriterien festlegen, warum ein bestimmter Status rot oder gelb und eine gewisse Stufe erhält.

Beispiel: Es werden mehr neue Fehler festgestellt, als alte geschlossen werden. Dann legt man zuerst fest, in welchem Anteil dieses Kriterium das gesamte Reporting beeinflussen soll (zu 5 % oder 10 %?). Man kann dann vereinbaren, welche Stufe für das einzelne Kriterium wann erreicht wird: Wenn die Anzahl neuer Fehler die Anzahl der geschlossenen Fehler um 10 % überschreitet, dann ist das Kriterium „gelb 5“, bei über 20 % „gelb 6“, bei über 30 % „gelb 7“. Diese Einschätzung wird analog für andere Kriterien vorgenommen (z. B. Anzahl der beschriebenen Testfälle, Anzahl der automatisierten Testfälle usw.).

Zugegeben ist dieses Verfahren erheblich aufwändiger als ein Schätzwert aufgrund von Erfahrungswerten. Ein langjährig erprobter Testmanager liegt bei der Schätzung in vielen Fällen auch gar nicht so weit daneben. Aber es ist eben doch nur halb professionell.

Durch eine klare Klassifizierung und Gewichtung lässt sich die Ableitung des Gesamtstatus der Testaktivitäten fundiert begründen. Es ist wissenschaftlich nachvollziehbar und sichert die Qualität, was gerade für Testmanager entscheidend ist. Man kann dann am Ende darüber streiten, ob die Grenze von einer Stufe zu einer anderen besser bei einem anderen Schwellwert zu ziehen ist oder ob die Wichtigkeit eines Kriteriums über- oder unterschätzt wurde. Aber man bekommt durch dieses Verfahren eine wesentlich genauere Aussagefähigkeit und Glaubwürdigkeit. Die eigene Argumentationsgrundlage ist weitaus besser gegeben und man gewinnt selber wesentlich mehr Sicherheit. Man kann kritischen Nachfragen wesentlich besser begegnen und erhält dadurch eine höhere Reputation. Dann kann man auch wesentlich leichter negative Botschaften proaktiv überbringen und gewinnt deutlich an Kompetenz.

Literatur

  1. [Spil2007]
    Spillner A, Linz T (2007) Basiswissen Softwaretest. dpunkt-Verlag, HeidelbergGoogle Scholar
  2. [Tesg2012]
    Das 3x3 – Testreporting für Testmanager Theorie. TestGilde GmbH, Esslingen (2012). http://www.testgilde.de/downloads/Das_3x3_Testreporting_fuer_Testmanager_Theorie.pdf. Zugegriffen am 07.10.2017

Copyright information

© Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2018

Authors and Affiliations

  • Frank Witte
    • 1
  1. 1.LandshutDeutschland

Personalised recommendations