Rollen Skill - Abweichungsmanager/ Defect Manager

Abweichungsmanager Kompetenz Rollen Skills www.hettwer-beratung.de Hettwer UnternehmensBeratung GmbH Beratung Experte Berater Profil Freiberufler Freelancer Spezialist Organisation Defect Manager

Der Defect Manager ist verantwortlich für das Fehler- und Abweichungsmanagement, also für die Fehlererkennung, Fehleranalyse, Fehlerbearbeitung und den Abschluss der Fehlerbehebung.

Ein Defect Manager verantwortet die effektive und effiziente Durchführung des Abweichungsmanagementprozesses, stellt durch geeignetes Defect Reporting eine Transparenz über den Defect Status und deren Verantwortungsübergängen her.

Des Weiteren tritt der Defect Manager bei Bedarf in Richtung der Projektleitung auch als Eskalationsinstanz auf.

Ein Defect (Fehlerzustand) in einem Softwaresystem oder einer Komponente beeinträchtigt die geforderte Funktionalität eines Produkts und kann in der Folge eine Fehlerwirkung verursachen.

Im Bereich des Abweichungsmanagements wird oft der Begriff Defect verwendet. Ein im Rahmen einer Testdurchführung festgestellter Defect begründet jedoch nicht immer einen Fehlerzustands der Software.

Vielmehr kann sich die Software auch anders als erwartet (= abweichend) verhalten, weil der Fehlerzustand auf Mängel zurück zu führen ist, die auf die Abbildung der Testumgebung, den konstruierten Testdaten oder den ungenau beschriebenen Anforderungen zurückzuführen sind.

Unter Abweichungsmanagement ist der Prozess zur Erkennung, Untersuchung, Ergreifung von Maßnahmen und Behebung von Fehlerzuständen zu verstehen. Dazu gehört auch, dass der Defect Manager die Abweichungen protokolliert, klassifiziert und die Auswirkung analysiert.

Erst im Rahmen einer Fehleranalyse wird somit die Quelle der Fehlerwirkung erkenntlich. Von daher sollen alle relevanten Informationen zu Fehlern und Abweichungen in den vorgesehenen Textfeldern ausführlich und verständlich genug beschrieben werden, wobei oftmals der zusätzliche Upload von Anhängen bei einer Fehleranalyse nützlich ist.

Rollenverantwortung beim Abweichungsmanagement

Rolle	Vorgangsart	Aktivitäten
Tester	Fehlererkennung	Mit der Entdeckung einer Abweichung werden alle wichtigen Informationen (z.B. Testumgebung, Testzeitpunkt, Wiederholbarkeit, vermutete Ursache) dokumentiert, die den beobachteten Fehler eindeutig kennzeichnen. Des Weiteren ist der möglicher Fehler anhand bestimmter Merkmale zu klassifizieren, so dass sich aus dem Fehlerschweregrad die Auswirkungen und Folgen für den Projektzeitplan bewerten lassen.
Defect Manager	Fehleranalyse	Durch eine Untersuchung der möglichen Fehlerzustände können in diesem Zusammenhang eventuelle weitere Probleme aufgedeckt und Lösungsvorschläge (Maßnahmen) erarbeitet werden. Auf Grund von vorhandener zusätzlichen Informationen können Fehlerklassifizierung und Auswirkungen erneut bewertet werden.
Entwickler	Fehlerbearbeitung	Ergreifung von erforderlichen Maßnahmen, die auf Basis der Ergebnisse der Fehleranalyse zur Behebung des Fehlers notwendig sind. Des Weiteren können diese Maßnahmen sich auch auf Prozesse und Methoden erstrecken, die dazu führen, dass ähnliche Fehler in Zukunft nicht mehr vorkommen.
Tester	Fehlernachtest durchführen (Regressionstest*)	Alle Testfälle, auf die die Fehlerbehebung eine negative Auswirkung hat (bzw. auch auf bereits bestehende Funktionalität haben könnte) müssen nochmals getestet werden. Des Weiteren ist sicher zu stellen, dass durch die Fehlerbehebung nicht weitere bisher nicht bemerkbare Fehlerzustände freigelegt wurden.
Defect Manager	Fehlerbearbeitung abschließen	Im Falle einer erfolgreichen Durchführung eines Regressionstest* werden alle etwaig weitere zusätzlich erforderlichen Informationen dokumentiert und der Abschluss des Defects durch den Status „erfolgreiche geschlossen“, „zurückgewiesen“, „zurückgestellt“ o. ä. klassifiziert.

* Regressionstest ist die Wiederholung aller oder einer Teilmenge von Testfällen, um Nebenwirkungen von Modifikationen in bereits getesteten Teilen der Software aufzuspüren

Im Wesentlichen geht es hier um:

Unser grundsätzliches Rollenverständnis, exemplarisch aufgeführt

» Prozess Manager der Defect Prozesse (Prozessqualitätssicherung, Terminüberwachung)

» Sicherung Qualität bei Defect Erstellung (Verständlichkeit, Vollständigkeit, Doppelerfassung)

» Steuerung Defect Verwaltung und Fehler Tracking (Koordination, Analyse und Auswertungen)

» Gezieltes Ticketrouting (Fehlerzuweisung, Fehlerzuordnung)

» Verfolgung Bearbeitungszeit von Defects (Controlling insb. außergewöhnlich lange

Fehlerbehebungszeiten sowie ungewöhnlich lange Dauer zwischen den Statusübergängen)

» Überwachung Statuspflege der Defects im Tool (z.B. HP QC, HP ALM),
bei Bedarf Erinnerung der Bearbeiter an bereits längere Zeit unbearbeitet Fehler

» Zielgruppenausgerichtetes Informationen und (bei Bedarf) Eskalation über

Fehlermeldungen im Rahmen von Fehlerstatistiken (Defect Reporting)

Genauer beschrieben obliegt es einem Defect Manager das Fehler- und Abweichungsmanagement zu verantworten, welches die Fehlererkennung, die Fehleranalyse, die Fehlerbearbeitung und den Fehlerabschluss umfasst.

Hierbei verantwortet der Defect Manager insbesondere die effektive und effiziente Durchführung des Defect Prozesses, stellt Transparenz über den Defect Status her und tritt bei Bedarf auch als Eskalationsinstanz auf.

Des Weiteren muss jede Abweichung, die aufgedeckt wird, in einem Fehlerbericht separat dokumentiert werden.

Unter einem Fehler- bzw. Abweichungsbericht ist ein Dokument zu verstehen, indem alle zu untersuchenden Ereignisse auflistet werden, die während des Testens aufgetreten sind.

HP ALM (HP Application Lifecycle Management)

HP Application Lifecycle Management (HP ALM) ist eine Scope-erweiterte Nachfolgeversion des Testmanagementwerkzeuges HP Quality Center (HP QC).

Das HP ALM Modul Defects bietet die Möglichkeit zur Erfassung und Verwaltung von Fehlern. Es dient damit der Steuerung und Kontrolle von während der Testdurchführungsphasen aufgetretenen Abweichungen. Darunter sind insbesondere Aktivitäten zur Dokumentation und Nachverfolgung der während eines Testprozesses aufgetretenen Fehler zu verstehen.

Handling Defect Status via HP Application Lifecycle Management

n HP ALM Modul Defects gibt es Felder, die zur Klassifizierung von Fehlern genutzt aber auch optional angewendet werden können.

Bei den durchzuführenden Aktivitäten erfasst zunächst der Tester den „neu“ festgestellten Fehler mit einer möglichst genauen Beschreibung.

Anschließend weist von der Grundidee her der Test Manager diesen Defect an den zuständigen IT Bereich/ Entwickler.

Nach der Durchführung einer Fehlerkorrektur setzt der zuständige Entwickler den Fehler auf den Status „behoben“.

Sobald die Fehlerbehebung auch in der Abnahmeumgebung zur Verfügung steht, setzt der Entwickler den Status des Defect auf „Nachtest“ und weist den Defect an den Defect Manager (alternativ kann aber auch ein Defect Routing direkt an den Ersteller des Defects vereinbart werden).

Der Tester führt den Nachtest durch und setzt den Fehler im Falle einer erfolgreichen Korrektur auf den Status „geschlossen“. War der Nachtest hingegen nicht erfolgreich, dann setzt der Tester den Status des Defects auf „Wiedereröffnet“ und weist diesen dann nochmals an den zuständigen IT Bereich/ Entwickler.

Anmerkung: Im Falle einer berechtigten Abweisung dürfen Defects „geschlossen“ werden.

Die Verantwortlichkeiten für die gesteuerten Änderungen des Defect Status (Bearbeitungszyklus zur Fehlerbearbeitung) können auf der Grundlage eines abgestimmten Rollen- und Berechtigungskonzeptes jedoch individuell festgelegt werden.

Die einem Defect zugrundeliegende Testfälle, Test Runs, Anforderungen sowie das zugehörige Release sollten in HP ALM manuell miteinander verknüpft werden.

Die Grundstruktur eines Defect-Workflows sowie des Rollen- und Berechtigungskonzeptes sollten als bindend beachtet werden, da Standardreports in der Regelt genau auf diese Vorgaben ausgerichtet sind und nur bei einer Einhaltung dieser Vorgaben korrekte und verlässliche Werte liefern können.

Verfügbare Felder für die Dokumentation von Defects in HP ALM (Auswahl)

HP ALM Attribute	Beschreibung des Defects
Assigned to	Angabe des nächsten zugewiesenen Bearbeiter im Fehlerprozess
Closing Date	Datum der Fehlerschließung
Comments	Kommentare (Hinweise zum Fehler)
Defect Type	Angabe der Fehlerursache
Description	Fehlerbeschreibung
Detected By	Name (oder Kennung) des Erstellers des Defect
Detected in Cycle	Angabe, in welchem Testzyklus der Fehler gefunden wurde
Detected on Date	Datum der Erstellung des Defects
Detected in Environment	Angabe, in welcher Testumgebung der Fehler gefunden wurde
Detected in Release	Angabe, in welchem Release der Fehler gefunden wurde
Priority	Angabe Dringlichkeit, mit der der Fehler behoben werden muss
Reproducible	Vermerkt , ob der Fehler reproduzierbar ist
Severity	Angabe der zu klassifizierenden Schwere der Fehlerauswirkung
Status	Status des Defects im Workflow
Subject	Ordnerebene auf der der Fehler aufgetreten ist
Summary	Kurze und präzise Zusammenfassung des Fehlers
Target Release	Angabe des Releases, in dem der Fehler behoben wird

Hinweis: Ein Defect ist in Prinzip ein Problem, welches in jeder beliebigen Phase eines Anforderungsmanagementprozesses erkannt werden kann. Ein Defect kann in HP ALM direkt oder indirekt mit anderen Entitäten (Anforderungen, Tests oder anderen Fehlern) verknüpft werden.

HP ALM Attribut „Severity“ - Bewertung Schweregrad eines Defects

Die Schwere eines Defects lässt sich durch eine Kategorisierung in Fehlerklassen steuern, beispielhaft wie folgend:

Kategorie	Fehlerbeschreibung
Fehlerklasse 1	» Systemausfall » Datenverlust » Wichtige Funktionalität kann nicht ausgeführt werden » Wichtige Anforderung wurde nicht umgesetzt
Fehlerklasse 2	» Verwendung einer Funktionalität ist schwer eingeschränkt möglich, es gibt hierzu keinen Workaround » Die Anforderung wurde mit starken Abweichungen umgesetzt und die Einschränkung kann vorübergehend nicht hingenommen werden
Fehlerklasse 3	» Verwendung einer Funktionalität ist mittelschwer eingeschränkt möglich, es gibt hierzu einen Workaround » Die Anforderung wurde eingeschränkt umgesetzt und die Einschränkung kann vorübergehend hingenommen werden

HP QC (HP Quality Center)

HP Quality Center (HP QC) ist eine webbasierte Applikation für alle wesentlichen Aspekte des Testmanagements, der Testplanung (Testfälle, Releases), des Fehlermanagements (Defects) aber auch des Anforderungsmanagements (Requirements).

Mit HP Quality Center können Applikationen schnell und effektiv getestet werden. Hierfür werden vom HP Quality Center einheitliche und wiederholbare Prozesse für das Aufstellen von Anforderungen, die Planung und das Scheduling (Zeitplanerstellung) von Tests bereitgestellt.

Damit können während der Testausführung die Testergebnisse analysiert sowie die Fehler und Probleme nachverfolgt werden.

Aufbau HP QC (HP Quality Center)
Bereich Management [Repräsentation der Release Planung]	Hier werden die Release Termine hinterlegt. Dieses erfolgt, indem zunächst Ordner und anschließend Releases erfasst werden: » Definition der Releases und Teststufen » Verknüpfung Struktur mit Requirements, Test Sets, Defects
Bereich Requirements [Repräsentation der Anforderungen]	Hier werden Anforderungen zu Geschäftsprozessen hinterlegt.
Bereich Business Compenents	Hier werden die Elemente für den Geschäftsprozess-orientierten Test hinterlegt
Bereich Testplan [Testfallerstellung, Testfallbeschreibung]	Hier werden alle Testfälle hinterlegt. Die Hinterlegung erfolgt mit Unterstützung des HP QC TIS. Die Anlage der Struktur erfolgt durch Ordner und Tests, wobei ein Test einem Testfall entspricht.
Bereich Test Resources [Übergreifend genutzte Komponenten]	Dieser Bereich wird für die Testautomatisierung benötigt.
Bereich Test Lab [Testausführung]	Hier werden die Testfälle – zugeordnet zum jeweiligen Release - abgelegt, die im Rahmen der jeweiligen Releases tatsächlich getestet werden.
Bereich Test Lab [Testausführung]
Bereich Defects [Erkannte Fehler]	Hier werden Fehler, die während der Testdurchführung gefunden werden, dokumentiert. Über die Schaltfläche New Defect wird das Detailfenster zur Erfassung des Fehlers angezeigt. Die Pflichtfelder, die erfasst werden müssen, sind rot markiert dargestellt
Bereich Dashboard [Berichte und Analysen]	Hier können Reports (Auswertung und Testberichte) erzeugt werden.

Handling Defect Erfassung in HP QC

Erkannte Defects sind über den Button „Defects neu“ anzulegen und nach der Befüllung der erforderlichen Attribute mit „Submit“ zu bestätigen:

Idealerweise werden Defects während der Testdurchführung aus dem „Manual Runner“ angelegt
Die Bezeichnung des Defects sollte eindeutig, prägnant und vor allem „sprechend“ sein
Das Feld „Description“ ist die Problembeschreibung des Defects vorgesehen
Das Feld „Comments“ ist zur Dokumentation der Bearbeitungsschritte vorgesehen
Das Feld „Link Comment“ dient der Beschreibung von Abhängigkeiten
Die Defects sind mit den zu Grunde liegenden Testfällen zu verknüpfen
Nutzung der Mailbenachrichtigungsfunktion, um die zuständigen Bearbeiter nach der Defect Zuordnung schnell hiervon informieren zu können

Hinweis: Im HP Quality Center ist die Aktivierung eine automatischen Mailversandfunktion bei Änderungen der Attribute "Assigned To" oder "Status" an die in den Feldern "Detected By" und "Assigned To" eingetragenen User möglich.

Anbei eine Auswahl der verfügbaren Attribute für die Dokumentation in HP QC:

HP QC Attribute	Erläuterung
Actual Fix time	Tatsächliche Bearbeitungszeit in Stunden
Assigned To	Angabe des aktuellen Bearbeiters, der den Defect weiter bearbeiten soll
Category	Kategorie des Defects, z.B. » Change Request » Double Defect » External Defect » Handling Defect » Real Defect
Closing Date	Datum, an dem die Lösung des Defects akzeptiert wird
Component	Komponente, in der der Defect aufgetreten ist
Detected By	Gefunden durch (Ersteller des Defects)
Detected On Date	Gefunden am (Erstellungsdatum)
Detected In Cycle	Gefunden in Zyklus (Teststufe, in der der Fehler festgestellt wurde)
Detected In Release	Gefunden in Release (Release, in dem der Fehler festgestellt wurde)
Estimated Fix Time	Geschätzte Aufwände für Behebung des Defects (in Stunden)
Modified	Datum der letzten Änderung (Automatisch bei jeder Änderung)
Test Data	Möglichkeit zur Hinterlegung von Testdaten
Priority	Priorität für Behebung des Defects Möglicher Wertebereich: » 1-Hoch (Hohe inhaltliche und zeitliche Wichtigkeit, d.h. Behebung fürs nächste Release unverzichtbar) » 2-Mittel (Hohe inhaltliche aber keine zeitliche Wichtigkeit, d.h. Behebung darf auf anderes Release verschoben werden) » 3-Niedrig (Keine inhaltliche und zeitliche Wichtigkeit, d.h. Behebung nicht im nächsten Release)
Severity	Einschätzung Schweregrad des Defects (Fehlerklassifikation) Möglicher Wertebereich: » 1-Hoch » 2-Mittel » 3-Niedrig
Status	Aktueller Bearbeitungszustand im Lebenszyklus (Workflow) Möglicher Wertebereich: » Clarify » Closed » Fixed » New » Open » Reopen » Retest » Work
Subject	Pfad des zugehörigen Testfalls im Test Plan (Ordnerstruktur)
Target Cycle	Zyklus eines Teststufe aus dem Bereich Releases, zu der der Defect behoben werden soll
Target Release	Release zum Zyklus eines Teststufe, in der der Defect behoben werden soll (erfolgt auch automatisch durch Setzen von Target Cycle)