Testprotokoll – Arbeitstier statt Papiertiger

Testprotokolle haben gemeinhin einen eher schlechten Ruf und gelten im besten Fall als Papiertiger. Ich finde, dass Testprotokolle diesen Ruf völlig zu Unrecht tragen und vielmehr ein echtes Arbeitstier für die Softwareentwicklung sind.

Status Quo

Bevor ich das Testprotokoll näher beleuchte, möchte ich Sie als Leser bitten, sich den aktuellen Status Quo Ihres Softwaretests (wahrscheinlich ohne den Einsatz von Testprotokollen) präsent zu machen.

  • Was ist das Ziel Ihrer Testaktivitäten?
  • Gibt es klar abgegrenzte Testläufe mit Start und Ende?
  • Welches Werkzeug benutzen Sie?
  • Wie gehen Sie mit Testergebnissen um?
  • Kommunizieren Sie positive und negative Testergebnisse?

Nehmen Sie sich ruhig etwas Zeit, um über die obigen Fragen nachzudenken, ich kann aber zumindest ein paar Anregungen geben.

Wenn Sie ein Testmanagement Tool wie TestLink einsetzen, sieht das Testergebnis wahrscheinlich so aus:

Wenn Sie die gefundenen Probleme in einen Issue Tracker eingefüllt haben, sieht das Ergebnis dann vielleicht so aus:

Oder Sie benutzen gar keinen Issue Tracker und versenden Bugs per E-Mail oder schreiben Sie in Excel-Tabellen?

Besonders der Punkt Bug Tracker zur Dokumentation der Ergebnisse sollte aus meiner Sicht einmal kritisch durchdacht werden. Sie sind sind äußerst strukturiert und in ihnen geht definitiv nichts verloren, aber sie bedeuten durchaus einen gewissen Overhead in der Erfassung, besonders bei sehr vielen Kleinigkeiten.

Außerdem finde ich, dass Bug Tracker tendenziell die Kommunikation schwächen. Man sollte sich bewusst sein, dass die eigene Organisation allein durch das Vorhandensein von bestimmten Features im Bug Tracker beeinflusst wird. Beispielsweise sei ein Tester gerade mit der Prüfung eines Features beschäftigt, wobei er ein Issue in den Bug Tracker einträgt. Ein Entwickler wird wahrscheinlich per E-Mail benachrichtigt und die Chancen sind durchaus gegeben, dass er sich dadurch veranlasst fühlt, sich diesen Bug sofort anzuschauen. Die Kommunikation zwischen Entwickler und Tester erfolgt dann primär schriftlich über den Bug Tracker. Das kann, muss aber nicht ein gewünschtes und sinnvolles Verfahren sein.

So, im besten Fall haben Sie jetzt etwas über Ihre Tools und Methodiken sinniert. Merken Sie sich Ihre Überlegungen!

Technik des Testprotokolls

Nun möchte ich das Testprotokoll beleuchten und wie es vielleicht den Status Quo des Tests ändern kann. Ich beziehe mich dabei natürlich hauptsächlich auf die Abbildung von Testprotokollen in Quality Spy, wobei vieles auch allgemein gültig ist.

Zunächst bin ich der Meinung, dass es eine klare Abgrenzung des Testlaufs geben muss. Dieser bezieht sich immer auf eine Softwareversion und hat zum Start ein klar umrissenes Ziel und natürlich auch ein eindeutiges Ende.

In der Phase der Durchführung werden alle gefundenen erwähnenswerten Vorkommnisse chronologisch in ein Protokoll eingefügt. Übrigens unabhängig davon, ob ein Testplan verwendet wird oder nicht.

Ein Testlauf sollte normalerweise nicht länger als einen Tag dauern, mind. aber 30 Minuten. Erst nachdem der Testlauf abgeschlossen ist, findet ein Rückfluss der Informationen (z.B. gefundene Fehler) in die Organisation zurück.

Folgendes Schaubild verdeutlicht noch einmal diesen nicht allzu komplexen Prozess:

Randnotiz für Experten: Falls Sie vom Konzept der Test Sessions angetan sind, können Sie die Durchführung gerne in beliebig viele Test Sessions unterteilen!

Die Vorbereitung in Quality Spy besteht lediglich darin, vor dem Start den Test Scope festzulegen. Dieser kann wie in diesem Beispiel durchaus kurz und knackig sein:

Das Protokoll in Quality Spy ist einem klassischen Word-Dokument nachempfunden und erlaubt ein flottes Eintippen von Einträgen während des Testens:

Ein Eintrag in einem Testprotokoll ist prinzipiell einem Eintrag in einem Bug Tracker durchaus ähnlich, jedoch gibt es ein paar Unterschiede. Als “Informationsfelder” gibt es lediglich eine Klassifizierung als “Fehler”, “Warnung”, “Sonstiges” oder “Positives”,  den Text und Bilder.

Trotz des Dokumenten-Look sind die Einträge dennoch strukturiert abgespeichert, was für die spätere Weiternutzung enorm wichtig ist.

Nach Abschluss des Tests wird man dieses Protokoll vielleicht noch etwas überarbeiten und vielleicht Dopplungen löschen, aber meistens kann man auch mit der Rohfassung arbeiten. Nicht vergessen sollte man den Testlauf in knappen Stichpunkten zusammenzufassen (“total instabil”, “Feature XYZ blockiert, aber sonst ganz gut”).

Nun ist natürlich die Frage, was man mit dem Ergebnis anfängt, bzw. wie sich der Rückfluss aus dem Test vollzieht.

Eine wunderbare Idee ist es zunächst, über die Testergebnisse zu kommunizieren (Tester-zu-Entwickler, Tester-zu-Projektmanager, Tester-zu-Kunde). Dafür zahlt sich das Dokumentenformat aus, denn dies ist viel angenehmer zu lesen als eine Excel-Tabelle oder Bug-Tracker-Einträge.

Wie aber nun letztendlich die Behebung der Bugs vonstatten geht, hängt von der Organisation ab. Quality Spy bietet dafür mehrere Möglichkeiten an:

  • Integrierter Workflow (“Lightweight Bug Tracking”)
  • Export in einen Bug Tracker
  • Export als Dokument (RTF) z.B. zum Versand per E-Mail
  • Veröffentlichen in WordPress-Blog

Integriert ist ein sehr einfacher aber leistungsfähiger Workflow der mit den Status Accepted (AC) -> Fixed (FX) -> Checked (CK) arbeitet:

Über Filter nach den Fehlertypen und nach dem Status kann man schon recht bequem damit arbeiten. Wichtig ist dabei die Fehler im Batch auf einmal abzuarbeiten und zu korrigieren, somit kann man sich gegenüber Bug Trackern viel “Verwaltung” sparen, daher auch das Attribut  ”Lightweight”. Aus persönlicher Erfahrung kann ich übrigens auch sagen, dass Fehler in einem Testprotokoll viel weniger bösartig aussehen und die Behebung als Entwickler viel zufriedener macht.

Dieser Ansatz erfordert aber auch durchaus Disziplin und stellt Bedingungen an die Organisation, dies werde ich in einem separaten Beitrag zu “Lightweight Bug Tracking” noch erläutern.

Der Export in einen Bug Tracker ist zur Zeit für Mantis möglich, aber über das Plugin-Modell kann man leicht weitere hinzufügen. Da der Bug Tracker mehr Informationen wie z.B. Priorität und Fehlerschwere erfordert, muss man dies Nachpflegen, allerdings kann man dies auch per Massenzuweisung machen, sodass der Aufwand nicht allzu groß ist. Im Bug Tracker kann sich ggf. ein entsprechend umfangreicher Workflow zur Behebung vollziehen.

Der RTF Export ist gut geeignet, wenn man adhoc mit jemand zusammen arbeitet und weder einen gemeinsamen Bug Tracker noch Quality Spy als gemeinsames Werkzeug verwendet.

Weiterhin ist es mittels eines Plugins möglich, das Testprotokoll in einem WordPress Blog zu veröffentlichen. Das ist hilfreich, um die Sichtbarkeit der Testergebnisse zu Erhöhen, v.a. für Personen die sonst keinen Zugang zu diesen Testergebnissen haben oder wollen. Auch dieses Thema werde ich in einem separaten Artikel noch beschreiben.

Fazit

Das ist doch wirklich mehr als nur ein Papiertiger, oder? Denken Sie nun noch einmal an Ihren Status Quo, sie haben Anfangs ja hoffentlich darüber sinniert. Was könnten Testprotokolle daran ändern?

Ein Testprotokoll ist sicher keine Wunderwaffe, aber in vielen Projekten hat es sich für mich als solides Arbeitstier erwiesen. Übrigens sogar im Word-Format – in den düsteren Zeiten wo es noch kein Quality Spy gab :)