Seite 3: Testdurchführung

Inhaltsverzeichnis

Ergebnisse im Schnelldurchgang – Testdurchführung

Nachdem die Tests geplant und Konfigurationen zugewiesen wurden, lassen sich diese individuell oder in Form einer Test-Suite ausführen. Dabei startet der Tester einen Testlauf, in dessen Kontext er Diagnosedaten auf dem Testsystem erfasst. Beispielsweise zeichnet er ein Video der Ausführung, die Systemkonfiguration, parallel gestartete Programme oder das Eventlog auf. Vor dem Start des Testlaufs verändert sich das Testing Center zum Test Runner – einer verkleinerten Applikation, die sich an den Rand des Bildschirms anordnet, um den Desktop im sichtbaren Bereich zu halten. Der Test Runner zeigt einen Testfall mit seinen Testschritten, wie er vom Tester durchzuführen ist, direkt neben der zu testenden Anwendung. Das ermöglicht nicht nur einen schnellen Wechsel für den Tester, sondern auch das Aufzeichnen der oben beschriebenen Diagnosedaten in der Testumgebung.

Während der Testdurchführung erfasst der Tester nicht nur Logdaten, sondern zeichnet auch Benutzerinteraktionen mit der Anwendung, das sogenannte Action Log, auf. Damit gemeint sind alle Klicks und Tastatureingaben auf und mit den Steuerelementen der Testanwendung sowie die Verwendung der Testparameterwerte zum Befüllen von Steuerelementen. Das zuletzt aufgezeichnete Action Log lässt sich mit dem Testfall verknüpfen und bei der nächsten Ausführung abspielen, was für beschleunigte Regressionstests sorgt. Statt immer wieder das Login und die Navigation bis zum problematischen Eingabedialog der Testapplikation durchgehen zu müssen, kann der Tester mit einem Klick auf "Play" die automatische Instrumentierung starten und so im "Fast Forward"-Modus zum spannenden Teil des Testfalls springen. Das beschleunigt nicht nur, sondern motiviert zugleich, da dem Tester eintönige Klickorgien erspart werden. Voraussetzung für die Interaktion ist, dass ein zeitgemäßer Browser bei Webapplikationen beziehungsweise eine kompatible Oberflächentechnik für Windows-Applikationen verwendet wurde.

Wenn der Tester die beschriebene Aufzeichnung beziehungsweise Automatisierung der Benutzerinteraktionen anhand der Applikation überprüft, wird er mit großer Wahrscheinlichkeit Einschränkungen registrieren. So müssen alle verwendeten Steuerelemente die Standards MSAA (Microsoft Active Accessibility) und UIA (Microsofts UI Automation) erfüllen – also Schnittstellen für die alternative Steuerung der Applikation zum Beispiel durch Sprache und Gesten.

Kommunikation mit dem Entwickler

Sollte ein Testschritt fehlschlagen, also das tatsächliche vom erwarteten Ergebnis abweichen, markiert der Tester den Schritt mit "Fail". Zusätzlich kann er nun einen Kommentar, einen Screenshot und einen kompletten Fehlerbericht direkt aus dem Test Runner heraus anlegen. Der Fehlerbericht ist dabei nicht nur ein Formular für die Eingabe der textuellen Fehlerbeschreibung, sondern auch bereits mit den Diagnosedaten der Testausführung angereichert. Es entsteht ein sogenannter "Rich Bug", wie ihn Abbildung 8 darstellt.

Die im Beispiel gezeigte Fehlermeldung enthält zusätzlich zu allgemeinen Informationen wie Titel, ID, zugewiesener Bearbeiter und Version die durch den Tester ausgeführten Schritte mit Ergebnis und direktem Link zur Position innerhalb des aufgezeichneten Videos. Ein Link zum angelegten Screenshot ist ebenfalls enthalten. Alle Daten sind wiederum im zentralen Repository des Team Foundation Server gespeichert.

Neben den Verbesserungen für die Kommunikation zwischen Tester und Entwickler resultiert aus den Rich Bugs ein weiterer Vorteil. Diese unterstützen den Tester bei der Verifizierung der Fehlerbehebung. Der Tester kann im Abschnitt "Verify Bugs", wie in Abbildung 9 dargestellt, die vom Entwickler gelösten Bugs auflisten und per Klick den Testfall, der zur Identifikation des Fehlers führte, erneut ausführen, was die Zahl der nach der Fehlerbehebung erneut ausgeführten Tests reduziert. Zudem hilft das zuvor beschriebene "Fast Forward"-Abspielen bei der erneuten Ausführung des Tests, da man bis zum kritischen Testschritt springen kann.

Auswertungsmöglichkeiten

Ein Testergebnis ist eine Fehlermeldung in Form eines "Bugs". Doch auch die positiven Resultate sind interessant. Einen Überblick über die Ergebnisse des Testlaufs bietet "Analyze Test Runs" im Track-Bereich. Ein Testlauf sammelt alle Informationen zur Ausführung von Tests durch einen Tester beziehungsweise in einer automatisiert getesteten Lab-Umgebung. Dazu gehören Metadaten wie Titel, Start- und Endzeit, ausführender Tester sowie eine Übersicht in Diagramm- und Listenform der ausgeführten Testfälle und deren Ergebnis.

Über den Testlauf kann man weiter in die Testergebnisse navigieren. Dort finden sich die einzelnen Testschritte, Kommentare und aufgezeichneten Informationen zur Testdurchführung. Da sich ein Testfall durchaus mehrfach ausführen lässt, gibt es für diesen eine Ergebnishistorie, die alle bisherigen Ausführungen zusammenfasst und sie in ihrer zeitlichen Reihenfolge darstellt.

Eine grundlegende Auswertung hält nicht bei den Testläufen. Die Verknüpfung zu den getesteten Anforderungen dient nun zur Generierung von Übersichten, die die Testergebnisse im Kontext der Anforderungshierarchie zeigen. Sie zeigen erfolgreiche, fehlgeschlagene und noch nicht ausgeführte Tests. Wie im Bericht "Requirements Overview" in Abbildung 11 zu sehen, wird zudem der Fortschritt der Anforderungen hinsichtlich der Implementierungsaufgaben dargestellt. Beispielsweise lässt sich während einer iterativen Entwicklung der Status der Anforderungsentwicklung und -abnahme überwachen, was den Kommunikationsaufwand der Projektverantwortlichen reduziert, da sie gezielt die fehlgeschlagenen Tests und offenen Fehler verfolgen können.

Der Team Foundation Server bietet viele weitere Daten zur Auswertung über das zentrale Berichtswesen an, zum Beispiel zum Testplanungsfortschritt oder zum Status über alle definierten Testfälle. Über die standardisierte Schnittstelle lassen sich Anwendungen wie Excel oder der Report Builder für das Erstellen von Berichten nutzen.