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:
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.
Ä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.
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.
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:
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.
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.
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.
|
|