F

Softwaretests: Wann sind Reports nötig und wie sollte ein Testbericht aussehen?

Testberichte sind bei der Softwareentwicklung nicht unbedingt nötig. Sollten Sie dennoch einen Testbericht brauchen, empfiehlt sich ein Template.

Sollten Testberichte bei Softwaretests schriftlich in einem Dokument festgehalten werden? In welcher Form würden...

Sie Testberichte dokumentieren?

Bei traditionelle Testberichten wir ein Dokument von einem Team angelegt, das sowohl den Entwicklern als auch dem Management nahe steht. Dabei könnte es sich zum Beispiel um eine externe Firma oder eine Entwicklungsteam handeln, bei dem der Team-Manager nicht der Entwicklungsverantwortliche ist. Die Gruppe arbeitet hierbei beispielsweise als Testgruppe und berät sich in eigenen Meetings mit der Entwicklungsabteilung.

Ich weise aus einem Grund darauf hin: Sitzen die Gruppen zusammen und arbeiten miteinander, können sie über den Fortschritt sprechen und sich gegenseitig Bugs zeigen. Der Testbericht erfolgt verbal, wobei ich diese Arbeitsweise bevorzuge.

Meine Präferenz ist eine konstante Zusammenarbeit mit dem Kunden, häufiges Bereitstellen für die Produktion, ein gemeinsames Verständnis für das Projekt und qualitativ hochwertigen Code erzeugen. Das gilt von der ersten Codezeile bis zu unabhängigen Tests. In einigen Fällen ist das aber nicht möglich.

Ist keine direkte Kommunikation möglich oder das Projekt wird erst später integriert, ist ein schriftlicher Testbericht unumgänglich. Die festgehaltenen Informationen sollten sowohl wertvoll für das Projekt als auch handfest sein. Die andere Partei in einfachen Worten verstehen, was wir ausdrücken wollen. Außerdem sollten Sie von zu vielen Informationen Abstand nehmen, da dies den Leser langweilt. Persönlich verwende ich am liebsten eine Kombination aus schlichter Sprache, Diagrammen, Screenshots und relevanten Zahlen. Damit meine ich keine „Metriken“, sondern relevante Daten.

Erstelle ich einen Testbericht, stehen die relevanten Informationen am Anfang. Da ein leitender Angestellter nur wenig Zeit hat, sollte er genug erfahren, um eine angebrachte Entscheidung treffen zu können. Hier sind einige Tipps, was ein Template für Softwaretests umfassen sollte:

Zusammenfassung für Führungskräfte

Vermitteln Sie dem leitenden Angestellten in einem Absatz oder weniger, was Sie von der Software halten. Sie sollten sich so ausdrücken, dass die Führungskraft anschließend eine Entscheidung treffen kann. Dort könnten Informationen über die Funktionen, Nutzererfahrung, Security-Status und weitere wichtige Projektpunkte enthalten sein.

Hauptprobleme am Anfang nennen

Arbeiten Sie sogenannte „Showstopper Bugs“ und andere entscheidende Probleme sorgfältig heraus. Für jeden Bug sollten Sie zunächst eine kurze Zusammenfassung schreiben und anschließend etwas detaillierter werden. Eventuell ist eine nummerierte Liste angebracht. Dabei fangen Sie mit dem schlimmsten Fehler an. Versuchen Sie die Länge der Informationen übersichtlich zu halten. Ich liste in der Regel fünf bis acht Bugs auf. Die Führungskraft kann sich die Liste ansehen und entscheiden, ob man weiter entwickelt oder zunächst die Probleme löst.

Übrige Probleme kurz aufzählen

Sprechen Sie über die Bugs, die man als mittelschwer oder niedrig einstufen würde. Sollten die Bugs ähnlich sein, können Sie diese mit einer Zahl versehen. Zum Beispiel: „Wir kennen drei weitere mittelschwere Bugs und fünf kleinere Fehler.“

Umfang des Projekts

Versuchen Sie auszudrücken, wieviel Testzeit in welche Teile der Anwendung investiert wurde. James Bachs Low Tech Testing Dashboard ist hier einen Blick wert. Das Low Tech Testing Dashboard lässt sich einfach in die Google Docs Tabellenkalkulation implementieren. Zudem können Sie Screenshots einfügen.

Was könnten wir mit mehr Zeit erreichen?

Informieren Sie die Führungskräfte, was Sie noch tun würden, wenn Sie mehr Zeit zum Testen hätten. Teilen Sie Ihre Gedanken, welche Vorteile dies bringt. Somit kann der Verantwortliche leichter entscheiden, ob er Ihnen mehr Zeit und/oder Ressourcen zur Verfügung stellt.

Unsere Teststrategie

Lassen Sie das Führungspersonal wissen, was Sie mit Ihrer Zeit angestellt haben. Dabei können Sie sowohl den Umfang als auch die Methoden einfließen lassen. Beschreiben Sie, ob es sich um Skript- oder explorative Tests gehandelt hat. Auch das Verhältnis ist in diesem Zusammenhang wichtig. Sollte das Dokument schon sehr lang sein und Sie glauben, dass dieser Teil keine wichtigen Informationen enthält, lassen Sie ihn weg.

Warum haben wir diese Teststrategie verfolgt?

Erklären Sie der Führungskraft, warum die Zeit angemessen veranschlagt wurde. Auch diesen Teil lasse ich in der Regel weg, wenn das Dokument zu lange wird oder die Informationen unwichtig sind.

Wo findet man weitere Informationen?

Stellen Sie Links zum Bug Tracker, Notizen über die Meetings und anderes Material zur Verfügung. Möglicherweise interessiert sich der Leser dafür, sollte er Zeit haben.

Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im Juni 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Software-Entwicklung

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchNetworking.de

SearchDataCenter.de

Close