Aufgabe: Testergebnisse bestimmen
Diese Aufgabe beschreibt, wie die Testergebnisse genau zu erfassen sind und welche Folgeaktion erforderlich ist.
Zweck

Diese Aufgabe hat folgenden Zweck:

  • Fortlaufend zusammenfassende Bewertungen der wahrgenommenen Produktqualität vornehmen
  • Die detaillierten Testergebnisse identifizieren und erfassen
  • Entsprechende Fehlerberichtigungen zur Behebung der qualitativen Mängel vorschlagen.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Schritte
Alle Teststörungen und -fehler untersuchen
Zweck:  Jedes Ereignis untersuchen und die sich ergebenden Probleme im Detail prüfen.  

Bei dieser Aufgabe werden die Testprotokolle analysiert, um die wichtigen Testergebnisse zu bestimmen. Interessant ist hierbei die Diskrepanz zwischen erwarteten und tatsächlichen Ergebnissen der einzelnen Tests. Ermitteln und analysieren Sie alle Ereignisse und Fehler nacheinander. Finden Sie so viel wie möglich über jeden Einzelfall heraus.

Stellen Sie fest, ob bestimmte Ereignisse mehrfach vorkommen, einheitliche Symptome zeigen oder andere Beziehungen aufweisen. Diese Bedingungen erlauben oft einen wertvollen Einblick in die eigentliche Ursache einer Gruppe von Ereignissen.

Änderungsanfragen erstellen und verwalten
Zweck:  Die Informationen zu einer Änderungsanfrage zum Zweck der Bewertung, Verwaltung und Behebung in ein Überwachungstool eingeben. 

Die Unterschiede bezeichnen potenzielle Mängel in den Zieltestelementen und sollten als Ereignisse oder Änderungsanfragen in ein Überwachungssystem eingegeben werden. Dabei sollten auch die entsprechenden Aktionen zur Fehlerberichtigung, die ausgeführt werden könnten, angegeben werden.

Unterthemen:

Ereignisfakten prüfen Seitenanfang

Prüfen Sie, ob genaue, unterstützende Daten verfügbar sind. Sortieren Sie die Daten so, dass Sie sie direkt der Änderungsanfrage zuordnen können, oder geben Sie an, wo die Daten separat abgerufen werden können.

Stellen Sie, wann immer dies möglich ist, sicher, dass das Problem reproduziert werden kann. Reproduzierbare Probleme haben eine bessere Chance, von Entwicklern wahrgenommen und gelöst zu werden. Ein Problem, das nicht reproduziert werden kann, ist frustrierend für das Entwicklungsteam und verschwendet wertvolle Programmierressourcen für die Suche. Sie sollten diese Ereignisse zwar protokollieren, sie aber getrennt von den reproduzierbaren Ereignissen verwalten.

Details zu Änderungsanfragen klären Seitenanfang

Änderungsanfragen müssen verständlich formuliert sind, das gilt vor allem für die Überschrift. Stellen Sie sicher, dass die Überschrift kurz und prägnant ist und das entsprechende Problem deutlich zum Ausdruck bringt. Kurze Überschriften sind nützlich für die Erstellung von Mängellisten und die Diskussion bei Besprechungen zum CCB-Status.

Es ist wichtig, dass die detaillierte Beschreibung der Änderungsanfrage unzweideutig ist und einfach interpretiert werden kann. Es ist sinnvoll, die Änderungsanfragen so bald wie möglich zu protokollieren, aber nehmen Sie sich genug Zeit, die Beschreibungen zu verbessern und zu erweitern, bevor sie vom Entwicklungsteam geprüft werden.

Stellen Sie geeignete Lösungen bereit, so viele wie es praktikabel erscheint. Dies hilft, die verbleibende Mehrdeutigkeit in der Beschreibung zu reduzieren und Klarheit zu schaffen. Außerdem erhöhen Sie so die Wahrscheinlichkeit, dass die Lösung nahe an Ihren Erwartungen liegt. Darüber hinaus wird gezeigt, dass das Testteam die Probleme nicht nur suchen, sondern auch entsprechende Lösungen identifizieren kann.

Andere Details, die Sie angeben müssen, sind Momentaufnahmen von Anzeigen, Testdatendateien, automatische Test-Scripts, Ausgaben von Diagnosedienstprogrammen und alle anderen Informationen, die bei der Isolierung und Behebung des zugrunde liegenden Fehlers nützlich sein können.

Relativen Schweregrad der Auswirkungen und Priorität für Problemlösung angeben Seitenanfang

Geben Sie den Mitarbeitern im Management und in der Entwicklung einen Hinweis zum Schweregrad des Problems. In größeren Teams wird normalerweise dem Managementteam das Vorrecht der Problemlösung zugestanden, sie können jedoch einzelnen Teilnehmern die Möglichkeit geben, ihre bevorzugte Lösungspriorität anzugeben, und diese dann nach Bedarf anpassen. Allgemein wird empfohlen, Änderungsanfragen standardmäßig eine durchschnittliche Lösungspriorität zuzuordnen und diese Priorität je nach Fall und Bedarf zu erhöhen oder zu verringern.

Möglicherweise müssen Sie zwischen den Auswirkungen, die die Änderungsanfrage auf die Produktionsumgebung hat, und den Auswirkungen, die sie auf die Tests hat, differenzieren. Für das Managementteam ist es genauso wichtig, zu wissen, wann ein Mangel sich auf den Test auswirkt, wie es für den Benutzer wichtig ist, zu wissen, welche Wertigkeit er hat.

Manchmal ist es schwierig, vorab zu erkennen, warum beide Attribute erforderlich sind. Es ist möglich, dass ein Ereignis, wie z. B. ein Systemabsturz, schwer wiegend ist, die zur Wiederherstellung erforderlichen Aktionen wahrscheinlich jedoch nie ausgeführt werden. In diesem Falle kann das Team die Wertigkeit als Hoch einstufen, jedoch eine sehr niedrige Lösungspriorität angeben.

Weitere Änderungsanfragen separat protokollieren

Bei der Ermittlung und Protokollierung einer Änderungsanfrage ergeben sich oft weitere Fragen, die zu behandeln sind. Geben Sie nicht der Versuchung nach, alle diese zusätzlichen Untersuchungsergebnisse sofort zur vorhandenen Änderungsanfrage hinzuzufügen. Wenn die neuen Informationen einen direkten Bezug zur vorhandenen Frage haben und helfen, sie besser zu lösen, können Sie dies tun. Unterscheiden sich die neuen Fragen von der vorhandenen, kann ein Vergleich mit einer vorhandenen Änderungsanfrage zu dem Ergebnis führen, dass diese Fragen nicht gelöst werden sollen, ihnen nicht die notwendige Aufmerksamkeit geschenkt wird oder dass sie die Bearbeitungsgeschwindigkeit, mit der andere Fragen behandelt werden, beeinträchtigen.

Status analysieren und bewerten
Zweck:  Die wichtigen Mess- und Bezugswerte des Tests berechnen und bereitstellen.  

Unterthemen:

Ereignisverteilung

Analysieren Sie die Ereignisse basierend auf der Verteilungsrichtung, z. B. Funktionsbereich, Qualitätsrisiko, zugeordneter Tester und zugeordneter Entwickler.

Suchen Sie nach Mustern in der Verteilung, z. B. Funktionsbereiche, in denen überdurchschnittlich viele Mängel auftreten. Achten Sie auch auf überarbeitete Entwickler und Tester. Stellen Sie fest, wo deren Arbeitsqualität möglicherweise nachlässt.

Umfang der Testausführung

Zum Bewerten des Umfangs der Testausführung müssen Sie die Testprotokolle überprüfen und Folgendes feststellen:

  • Das Verhältnis zwischen der Anzahl der Tests (Test-Scripts oder Testfälle), die in diesem Testzyklus durchgeführt wurden, und einer Gesamtanzahl von Tests für alle geplanten Zieltestelemente.
  • Der Faktor der erfolgreich durchgeführten Testfälle.

Das Ziel ist, sicherzustellen, dass von den Tests, die sich auf diesen Testzyklus beziehen, genug erfolgreich durchgeführt wurden. Wenn das nicht möglich ist oder wenn Sie die Ausführungsdaten erweitern möchten, können Sie ein oder mehrere zusätzliche Kriterien für die Testabdeckung angeben, basierend auf folgenden Punkten:

  • Qualitätsrisiko oder Priorität
  • Umfang gemäß Spezifikation (Anforderungen etc.)
  • Geschäftsbedarf oder Priorität
  • Codebasierter Umfang.

Siehe Konzept: Schlüsselmesswerte des Tests, anforderungsbasierte Testabdeckung..

Erfassen und präsentieren Sie die Testergebnisse in einem Bericht zur Testbewertung, der sich auf diesen Testzyklus bezieht.

Statistik zu Änderungsanfragen

Zum Analysieren von Mängeln müssen Sie die Messwerte, die Sie für Ihre Mängelanalysestrategie ausgewählt haben, überprüfen und analysieren. Die gebräuchlichsten Messgrößen für Mängel, die oft als Grafik dargestellt werden, sind die folgenden:

  • Mängeldichte - Die Anzahl der Mängel wird als Funktion eines oder zweiter Attribute dargestellt (z. B. die Verteilung über einen Funktionsbereich oder ein Qualitätsrisiko im Vergleich mit Status oder Wertigkeit).
  • Mängeltrend - Die Anzahl der Mängel wird als zeitabhängig Funktion dargestellt.
  • Mängelalter - Eine Sonderform des Berichts zur Mängeldichte, in dem die Anzahl der Mängel als Funktion des Zeitraums darstellt, den ein Mangel in einem bestimmten Status bleibt (Offen, Neu, Auf Überprüfung wartend etc.).

Vergleichen Sie die Messwerte aus diesem Testzyklus mit den laufenden Summen für die aktuelle Iteration und den Summen aus der Analyse der vorherigen Iterationen, um die Trends, die sich im Laufe der Zeit abzeichnen, besser verstehen zu können.

Es wird empfohlen, die Ergebnisse mit unterstützenden Daten auf Anfrage zu präsentieren.

Bewerten Sie die aktuelle Qualitätserfahrung.
Zweck:  Feedback zur aktuellen wahrgenommenen oder erfahrenen Qualität im Softwareprodukt abgeben.  

Formulieren Sie eine Zusammenfassung der aktuellen Qualitätserfahrung und heben Sie die positiven und negativen Aspekte der Qualität des Softwareprodukts hervor.

Besondere Qualitätsrisiken bewerten
Zweck:  Feedback zu der Frage abgeben, welchen Risikobereichen das Projekt potenziell am stärksten ausgesetzt ist. 

Definieren und erläutern Sie die Bereiche, die hinsichtlich der Qualitätsrisiken noch nicht behandelt wurden, und geben Sie an, welche Auswirkungen sie auf das Team haben.

Geben Sie an, welche Priorität die einzelnen Qualitätsrisiken haben, und legen Sie anhand der Priorität fest, in welcher Reihenfolge diese Fragen behandelt werden sollen.

Testabdeckung bewerten
Zweck:  Eine zusammenfassende Bewertung der Analyse der Testabdeckung vornehmen.  

Machen Sie basierend auf der Testabdeckung eine kurze zusammenfassende Aussage über den Status der Daten und die Informationen, die sich aus ihnen ergeben.

Entwurf der zusammenfassenden Testbewertung
Zweck:  Die Testergebnisse den Stakeholdern mitteilen und eine objektive Bewertung der Qualität und des Teststatus vornehmen.  

Stellen Sie die Testergebnisse für diesen Testzyklus in einer zusammenfassenden Testbewertung dar. Bei diesem Schritt wird der erste Entwurf der Zusammenfassung entwickelt. Dazu werden die vorherigen Informationen, die in einem lesbaren Ergebnisbericht erfasst wurden, zusammengetragen. Je nach Stakeholder-Zielgruppe und Projektkontext variieren Format und Inhalt der Zusammenfassung.

Oft ist es ein sinnvoller Lösungsansatz, den ersten Entwurf an eine Untergruppe von Stakeholdern zu verteilen, um ein Feedback zu erhalten, das Sie verwenden können, bevor Sie die für eine breitere Zielgruppe veröffentlichen.

Stakeholder über wichtige Ergebnisse informieren
Zweck:  Die Zusammenfassung der Bewertung bei Bedarf vertreten und öffentlich machen.  

Machen Sie diese Informationen in jeder geeignet erscheinenden Form publik. Es empfiehlt sich, die Informationen an eine zentrale Projektwebsite zu übergeben oder sie in regelmäßig stattfindenden Statusbesprechungen darzustellen, um Feedback sammeln und die nächsten Aktionen bestimmen zu können.

Bedenken Sie, dass sie an sensible Fragen der Geschäftspolitik rühren können, wenn Sie Zusammenfassungen von Bewertungen öffentlich zugänglich machen. Präsentieren Sie die Ergebnisse unverfälscht und präzise, aber begegnen Sie dabei der Arbeit der Entwickler mit Respekt. Sprechen Sie vorab mit dem Entwicklungsmanager.

Ergebnisse bewerten und prüfen
Zweck:  Überprüfen, ob die Aufgabe ordnungsgemäß ausgeführt wurde und die resultierenden Arbeitsergebnisse annehmbar sind.  

Wenn Sie Ihre Arbeit beendet haben, kann es vorteilhaft sein zu prüfen, ob diese Arbeit hinreichend nutzbringend oder eine reine Papierverschwendung war. Sie sollten bewerten, ob die Qualität Ihrer Arbeit angemessen ist und ob der Umfang der Arbeit ausreicht, um eine Hilfestellung für die Teammitglieder zu bieten, die sie als Arbeitsvorgabe verwenden sollen. Verwenden Sie nach Möglichkeit die RUP-Prüflisten, um zu überprüfen, ob Qualität und Vollständigkeit "gut genug" sind.

Legen Sie den Personen, die nachgeordnete Aufgaben ausführen müssen und auf Ihre Arbeitsvorgaben angewiesen sind, einen Zwischenstand Ihrer Arbeiten zur Prüfung vor. Wählen Sie dafür einen Zeitpunkt, der eine Einbeziehung von Änderungswünschen oder die Berücksichtigung von Problemstellungen zulässt. Bewerten Sie Ihre Arbeit auch anhand der Arbeitsergebnisse, die für Sie die wichtigsten Vorgaben waren, um sicherzugehen, dass Sie diese präzise und ausreichend dargestellt haben. Vielleicht lassen Sie Ihre Arbeit ja dahingehend vom Autor dieser Arbeitsergebnisse prüfen.

Vergessen Sie nicht, dass RUP ein iterativer Bereitstellungsprozess ist und dass sich in vielen Fällen Arbeitsergebnisse über einen längeren Zeitraum entwickeln. Es ist daher in der Regel nicht nötig und manchmal sogar kontraproduktiv, ein Arbeitsergebnis, das für die unmittelbar folgenden Arbeiten nur teilweise oder gar nicht benötigt wird, bereits vollständig und abschließend zu definieren. Es ist sehr wahrscheinlich, dass die umgebende Situation für das Arbeitsergebnis sich noch ändern wird und die bei Erzeugung des Arbeitsergebnisses gültigen Annahmen sich als fehlerhaft erweisen, so dass eine abschließende Gestaltung des Arbeitsergebnisses einen unnötigen Arbeitsaufwand und teures Nacharbeiten bedeuten würde. Sie sollten auch nicht zu viel Zeit auf die Darstellung verwenden, sondern sich eher auf den Inhalt konzentrieren. In Projektumgebungen, bei denen die Präsentation wichtig ist und als Projektliefergegenstand einen wirtschaftlichen Wert hat, könnten Sie für die Darstellungsaufgaben eine administrative Ressource nutzen.



Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen