Issue Manager verwaltet Fehler über ihren gesamten Lebenszyklus (vom Zeitpunkt der Meldung bis zu dem Zeitpunkt, da der Fehler geschlossen wird) durch einen Mechanismus, der als aktionsgetriebener Workflow bezeichnet wird. Aktionsgetriebener Workflow bedeutet, dass ein Fehler durch Benutzeraktionen von einem Status (d. h. einer Bedingung) zum nächsten befördert wird, bis ein Endstatus erreicht ist.
Wie Statuswerte und Aktionen zusammenarbeiten
Das folgende Beispiel zeigt, wie eine Aktion, die mit einem Fehler in einem bestimmten Status durchgeführt wird, den Fehler durch seinen Lebenszyklus befördert. Im Standard-Workflow erhält ein neu eingegebener Softwarefehler, der von einem Mitarbeiter des technischen Support gemeldet wird, den Status Ungeprüft. Das bedeutet, dass noch niemand überprüft hat, ob es sich tatsächlich um einen Fehler handelt. Nach Prüfung der Situation bestätigt ein QS-Mitarbeiter, dass ein Fehler vorliegt. Der Fehler wird an einen Entwickler gesendet, der ihn beheben soll. In diesem Beispiel ist der anfängliche Fehlerstatus Ungeprüft, die durchgeführte Aktion ist Bestätigen, und der nächste Status ist Offen (d. h. bereit für die Entwicklungsabteilung). Das folgende Workflow-Diagramm zeigt die Statuswerte und die Aktion.
Wurde jedoch in Issue Manager bereits ein identischer Fehler eingegeben, lautet die mit dem ungeprüften Fehler durchzuführende Aktion Doppelt eingetragen. Der nächste Status ist vermutlich Geschlossen. Eine andere Aktion mit dem ungeprüften Fehler befördert diesen also auch in einen anderen Status (in diesem Fall Geschlossen). Das folgende Diagramm zeigt diese Beispiele.
Ein Workflow benötigt mindestens einen Endstatus. Der Endstatus ist der letzte Status im Workflow. Im obigen Diagramm ist der Endstatus Geschlossen.
Nicht bei allen Aktionen ändert sich der Fehlerstatus
Manchmal behalten Fehler ihren gegenwärtigen Status auch nach einer Aktion. Dies gilt beispielsweise für die Aktion Kommentar hinzufügen, mit der ein Benutzer zur Beschreibung eines vorhandenen Fehlers einen Kommentar hinzufügt. Im folgenden Diagramm fügt ein Entwickler einem Fehler im Status Offen einen Kommentar hinzu, ohne jedoch eine Aktion durchzuführen, die den Fehler dem Status Geschlossen näher bringt. Der Fehler bleibt also im Status Offen.
Zwei vom System bereitgestellte Aktionen
Issue Manager bietet für jeden Status in jedem Workflow zwei vordefinierte Aktionen an:
• Neu zuordnen ordnet einen Fehler einem anderen Postfach zu.
• Bearbeiten erlaubt das Ändern von Feldern auf der Seite Fehlerdetails.
Diese Aktionen verändern den aktuellen Status des Fehlers nicht, da sich der Fehler im Workflow nicht vorwärts bewegt. Nehmen wir an, Fred geht in Urlaub und ordnet seine ungeprüften Fehler dem Postfach von Diana zu. Die Fehler bleiben ungeprüft, bis David eine Aktion durchführt, die ihren Status ändert.
Ein Workflow definiert einen gültigen Satz von Aktionen, die in einem bestimmten Status durchgeführt werden können. Diese Aktionen werden im Fenster Workflows angezeigt. Die verfügbaren Aktionen hängen davon ab, welcher Fehlertyp und welcher Aktuelle Status in den Dropdown-Listenfeldern ausgewählt sind.
Aktionen stehen auf der Seite Fehlerdetails in Form von Schaltflächen zur Verfügung. Die verfügbaren Schaltflächen (d. h. Aktionen) variieren je nach Fehlertyp und aktuellem Status.
In diesem Kapitel erfahren Sie, wie Sie die Schaltflächenbezeichnungen für jeden Status definieren, die auf der Seite Fehlerdetails angezeigt werden.
Statusinformationen werden in Issue Manager an vielen verschiedenen Stellen angezeigt. So sind beispielsweise jeder Gruppe und jedem Benutzerkonto drei anfängliche Statuswerte zugeordnet (für die drei Fehlertypen Fehler, Erweiterung und Dokumentation).
Anfänglicher Status wirkt sich auf Lebenszyklus aus
Der anfängliche Status eines Fehlers hängt davon ab, welche Kenntnisse der den Fehler meldende Benutzer über diesen Fehlertyp hat. Meldet beispielsweise ein Mitarbeiter des technischen Support einen Dokumentationsfehler, kann davon ausgegangen werden, dass seine Einschätzung richtig ist. Der Fehler muss behoben werden und erhält den anfänglichen Status Zu dokumentieren. Meldet der gleiche Mitarbeiter jedoch einen Softwarefehler, sind möglicherweise Zweifel angebracht, und der anfängliche Status des Fehlers im Workflow ist Ungeprüft . Verschiedene Gruppen können für denselben Fehlertyp einen unterschiedlichen Anfangsstatus verwenden. Weitere Informationen über anfängliche Statuswerte finden Sie unter "Anfänglicher Fehlerstatus"..
Speichert ein Benutzer einen Fehler, weist Issue Manager dem Fehler automatisch den Anfangsstatus zu, der dem Benutzer zugeordnet ist. Wenn ein technischer Autor einen Dokumentationsfehler meldet, hat das Feld Status auf der Seite Fehlerdetails den Wert Zu dokumentieren. Das Feld Status ist ein automatisches Feld. Automatische Felder werden nicht vom Benutzer, sondern von Issue Manager ausgefüllt.
Jeder Status in einem Workflow, der kein Endstatus ist, hat genau einen Eigentümer. Der Statuseigentümer ist die Rolle in einem Unternehmen, die für die Durchführung von Aktionen mit einem Fehler in einem bestimmten Status verantwortlich ist. Betrachten wir zum Beispiel einen ungeprüften Fehler. Der Benutzer, der einen ungeprüften Softwarefehler bestätigt oder ablehnt, führt mit großer Wahrscheinlichkeit die Rolle "QS" aus. Der Statuseigentümer eines ungeprüften Fehlers ist also die Rolle "QS".
Ein Endstatus in einem Workflow hat keinen Eigentümer, da ein Fehler in diesem Status keinen verantwortlichen Benutzer benötigt, der eine Aktion mit ihm durchführt.
Issue Manager bietet vier mögliche Eigentümer für einen Status an, der kein Endstatus ist:
• QS
• Entwicklung
• Dokumentation
• Erweiterungen
Beachten Sie, dass ein Statuseigentümer kein spezieller QS-Mitarbeiter und kein spezielles Postfach ist. Er hängt auch nicht von einem Produkt, einer Komponente, einer Version oder einer Plattform ab. Der Statuseigentümer ist die allgemeine Bezeichnung für eine verantwortliche Person in einem bestimmten Status.
Wofür benötigt ein Status einen Eigentümer? Der Eigentümer ist eine wichtige Eigenschaft eines Status, da er zusammen mit den Zuordnungsregeln das spezielle Postfach bestimmt, an das der Fehler gesendet wird. Eine Beschreibung der Zuordnungsregeln finden Sie unter "Einrichten von Zuordnungsregeln". Im folgenden Beispiel verwendet Issue Manager Zuordnungsregeln, Statuswerte und Statuseigentümer, um einen Fehler an ein bestimmtes Postfach zu senden.
Angenommen, Sie haben entschieden, dass der Eigentümer des Status Ungeprüft für alle Softwarefehler, unabhängig von Produkt, Komponente usw., die Rolle "QS" sein soll. Die Mitarbeiter, die diese Rolle einnehmen, bestätigen, dass ein gemeldeter Fehler tatsächlich ein Fehler ist. Im Dialogfeld Statuseigenschaften des Status Ungeprüft wählen Sie also die Optionsschaltfläche QS-eigener Status. Um das Dialogfeld Statuseigenschaften zu öffnen, wählen Sie Konfiguration/Workflows. Klicken Sie dann auf die Schaltfläche Status bearbeiten.
Überlegen Sie sich nun die Zuordnungsregeln für bestimmte Produkte. Wenn Sie Zuordnungsregeln einrichten (Konfiguration/Zuordnungsregeln), geben Sie für jede Kombination aus Produkt, Komponente, Version und Plattform vier Postfächer an. Jede der vier Optionsschaltflächen für Statuseigentümer entspricht einem der vier Postfächer auf der Seite Zuordnungsregeln: QS, Entwicklung, Erweiterung und Dokumentation.
Beispiel: Eine Zuordnungsregel legt fest, dass ein Fehler, der zur E-Mail-Komponente einer beliebigen Version von Produkt C auf einer beliebigen Plattform gehört, einem der folgenden Postfächer zugeordnet wird: Mike - QS, Sonja - Entw, Dan - Entw (Produkt C) oder Judy - Dok.
Eines der vier Postfächer wird ausgewählt. Die Auswahl hängt von zwei Faktoren ab: vom aktuellen Fehlerstatus und vom Eigentümer dieses Status. Angenommen, der aktuelle Status des Fehlers ist Ungeprüft, und die Rolle "QS" ist der Eigentümer ungeprüfter Fehler. In diesem Fall wird der Fehler automatisch dem Postfach von Mike zugeordnet (Mike - QS).
Führt Mike eine Aktion mit dem Fehler durch, befördert er diesen in seinem Lebenszyklus in einen anderen Status, der einen anderen Eigentümer hat. Wieder ermittelt Issue Manager das geeignete Postfach. Als Grundlage dienen der aktuelle Fehlerstatus, der Statuseigentümer und die Zuordnungsregel für das Produkt, die Komponente, die Version und die Plattform.
In diesem Kapitel erfahren Sie, wie Sie für jeden Status im Workflow einen Statuseigentümer festlegen.
Die von Issue Manager unterstützten Begründungen sind optionale, anpassbare Schlüsselwörter, die beschreiben, warum ein Fehler bei einer bestimmten Aktion seinen Status gewechselt hat.
Begründungen erfüllen einen rein informativen Zweck. Wie die vorangegangenen Beispiele zeigen, kann es vorkommen, dass verschiedene Aktionen zum selben Fehlerstatus führen. So kann ein Fehler beispielsweise aus vielen verschiedenen Gründen geschlossen werden - er ist nicht reproduzierbar, er ist doppelt vorhanden, er ist kein Fehler usw. Ohne die Zusatzinformation der Begründung hat der Benutzer vom Lebenszyklus des Fehlers nur ein unvollständiges Bild.
Begründungen tragen auch dazu bei, die Anzahl der Statuswerte in Ihrem Workflow zu verringern. Anstatt beispielsweise mehrere Endstatuswerte zu definieren (Kein Fehler, Nicht reproduzierbar, Duplikat), reicht es aus, den Status Geschlossen um einige Begründungen zu erweitern, die darüber Auskunft geben, warum eine Aktion einen Fehler geschlossen hat (z. B. Geschlossen/Kein Fehler).
Wo werden Begründungen angezeigt?
Begründungen werden sowohl in den Aktionsdialogfeldern als auch auf der Seite Fehlerdetails angezeigt. Angenommen, die technische Autorin Judy findet in ihrem Postfach einen Dokumentationsfehler vor. Nach dem Lesen der Beschreibung erinnert sie sich daran, dass der Fehler bereits gemeldet wurde. Sie kennzeichnet den Fehler als Duplikat. Wenn Sie das Dialogfeld Doppelt eingetragen öffnet, sieht sie, dass Issue Manager den Fehler von Zu dokumentieren nach Geschlossen/Doppelt verschoben hat. Geschlossen ist der neue Status, und Doppelt ist die Begründung.
Beim nächsten Öffnen des Dialogfeldes für diesen Fehler trägt Issue Manager den Status und die Begründung ein.
Zuordnen, Löschen und Beibehalten einer Begründung
Bei bestimmten Aktionen ordnet Issue Manager der Aktion eine Begründung zu und gibt sie an den nächsten Status weiter. Nachfolgende Aktionen können die Begründung löschen oder einfach beibehalten. Eine einmal zugeordnete Begründung bleibt normalerweise so lange bei dem Fehler, bis dieser seinen Endstatus im Workflow erreicht.
Angenommen, ein Entwickler behebt einen Fehler und führt die Aktion Behoben durch, um anzuzeigen, dass der Fehler behoben wurde. Die Aktion setzt die Begründung auf Behoben und sendet den Fehler von Offen an Zu verifizieren. Der QS-Mitarbeiter, der die Anfrage des Entwicklers prüft, bestätigt die Behebung, indem er die Aktion Verifiziert durchführt. Die Aktion behält die Begründung Behoben bei und versetzt den Fehler in den Status Geschlossen. Das folgende Diagramm zeigt diesen Workflow.
Es gibt auch Fälle, in denen die Begründung gelöscht werden soll, z. B. dann, wenn ein Fehler zu einem früheren Status im Workflow zurückkehrt. Angenommen, der QS-Mitarbeiter beurteilt die Anfrage des Entwicklers negativ und führt die Aktion Ablehnen durch, die den Fehler wieder in den Status Offen versetzt. Nun ergibt die Begründung Behoben keinen Sinn mehr. Sie sollte daher für die Aktion Ablehnen gelöscht werden. Der folgende Auszug aus einem Workflow zeigt diesen Sachverhalt.
Ob Begründungen zugeordnet, gelöscht oder beibehalten werden, hängt von der Einstellung im Dialogfeld Neue Aktion für Status ab, das unter "Begründung" beschrieben ist. Um das Dialogfeld Neue Aktion für Status zu öffnen, wählen Sie Konfiguration/Workflows. Klicken Sie dann auf die Schaltfläche Aktion hinzufügen.
Welcher Status braucht eine Begründung?
Im Allgemeinen sollten Sie allen Statuswerten, die von einem Entwickler bearbeitet werden, eine Begründung zuordnen. Einem Endstatus brauchen Sie keine Begründung mehr zuzuweisen.
Im weiteren Verlauf dieses Kapitels erfahren Sie, wie Sie Begründungen einrichten, wenn Sie Statuswerte für Workflows und Aktionen definieren, die in einem bestimmten Status durchgeführt werden können.