Management Skill - Abweichungsmanagement

Test Management Skills www.hettwer-beratung.de Hettwer UnternehmensBeratung GmbH Beratungskompetenz Experte Berater Profil Freiberufler Freelancer Spezialist Planung Organisation Kontrolle

Das Abweichungsmanagement verantwortet die methodische Erkennung und Aufzeichnung eines unerwarteten Ereignisses (Anomalie), die nähere Analyse, Identifikation und Klassifizierung der Fehlerwirkungen sowie die Bearbeitung und Verfolgung der Abweichungsbehebung bis hin zum dokumentierten Abschluss des aufgedeckten Fehlerzustandes.

Aus den Ergebnissen der Untersuchung von Prozessen und Methoden leitet das Abweichungsmanagement Maßnahmen ab.


Diese Maßnahmen erstrecken sich auch darauf erstrecken, dass ähnliche Abweichungen in Zukunft mehr vorkommen können.

Eine Abweichung erfordert zwar stets die Erstellung eines Abweichungsberichts, muss jedoch nicht immer zwangsläufig einen tatsächlichen Fehler an einer oder mehreren Hard- und Softwarekomponenten zur Ursache haben.

Das festgestellte Problem kann auch darauf beruhen, dass beispielsweise der Aufbau der Testumgebung von der Produktionsumgebung in unzulässigem Ausmaß abweicht oder nur unvollständigen Teststammdaten zur Verfügung gestellt wurden.

Näherungsbestimmung Begriff „Abweichung“ (Auszug)

» Nicht den Beschreibungen des Fachkonzeptes entsprechende Programmierung

» Technische Fehler (z.B. Störungen in Testumgebung, Parametrisierungsfehler etc.)

» Fehler zu deren Behebung gegebenenfalls ein Change Request erforderlich ist

 

KEINE Abweichungen sind beispielsweise:

» Fehler der Anwender

» Fachliche Fragestellungen

Ein Fehlerzustand ist erst dann ein tatsächliches Problem, wenn festgestellt wurde, dass die Fehlerwirkung nur durch eine technische Änderung am Softwaresystem oder an einer Komponente gelöst werden kann.

Ein Fehlerzustand lässt sich durch einen statisches Testen und eine Fehlerwirkung dagegen nur durch ein dynamisches Testen erkennen.

Mögliche erforderliche technische Abweichungen können bei einem Softwarelebenszyklus quasi in jeder Phase entdeckt werden.

Zum Zeitpunkt der Erkennung sind die relevanten Datenelemente und Informationen (z.B. Zeitpunkt der Testaktivität, Testphase, vermutete Ursache, Wiederholbarkeit, Symptome) zu dokumentieren, die den Fehler so eindeutig kennzeichnen, dass schon anhand bestimmter Merkmale der Schwergrad der Abweichung und mögliche Folgen für Projektzeitplan und Projektkosten relativ genau klassifiziert werden können.

Unter einer Fehlerwirkung ist die Abweichung eines Softwaresystems oder einer Komponente von der erwarteten Lieferung, Leistung oder dem Ergebnis zu verstehen. Je früher beim Testen eine Fehlerwirkung erkannt und korrigiert wird, desto geringer sind die Kosten der Qualität für das Gesamtsystem.

Im Rahmen einer Analyse wird anschließend versucht, die in dem Zusammenhang ggf. entstehenden weiteren Probleme aufzudecken und Lösungsvorschläge zu erarbeiten.

Die aus den Ergebnissen der Analyse abgeleiteten Maßnahmen können sich sowohl auf Maßnahmen erstrecken, die zur Behebung der Abweichung notwendig sind als auch auf die Überprüfung und Verbesserung von Prozessen, die in Zukunft das Vorkommen ähnlicher Fehler verhindern sollen.

Beim prozessualen Ablauf werden Abweichungen zunächst von den Testern als Ticket erfasst bzw. gemeldet.

Das Abweichungsmanagement stellt u.a. sicher

» Definition eines Workflows über die gesamte Lebensdauer eines Fehlers

» Überwachung und Bewertung der allgemeinen Fehlersituation

» Kontrolle der Einhaltung von definierten Richtlinien zur Erfassung von Fehlern

» Besprechung von Abweichungen im Rahmen von Status Jour Fix

» Rückmeldungen müssen zu jedem Ticket innerhalb eines angemessenen Zeitraumes erfolgen

» Bei Bedarf Einleitung von Eskalationsvereinbarungen

Das vorrangige Ziel des Abweichungsmanagements ist es, eine einheitliche Vorgehensweise für eine effiziente Bereinigung von Fehlern und deren Auswirkungen zu schaffen sowie kritische Situationen frühzeitig zu erkennen, um entsprechende Gegenmaßnahmen einleiten zu können.

Ziele des Abweichungsmanagement

» Transparenz über bestehende Abweichungen

» Statusinformation für (Teil)-Projektleitung

» Kommunikations- und Dokumentationsmedium über den Lebenszyklus von Abweichungen

» Zuordnung der erfassten Abweichungen zu dem betroffenen Testfall

» Revisions- und externe Prüfungssicherheit zur Nachvollziehbarkeit und Dokumentation

Wird ein definiertes Ziel nicht erreicht, greift ein Eskalationsverfahren unter Berücksichtigung der angegebenen Kategorie und Zeiträume:

Kategorie

Erläuterung

Kategorie 1

Nach x Tagen/Wochen Eskalation an Projektleitung

Kategorie 2

Nach y Tagen/Wochen Eskalation an Lenkungsausschuss

Kategorie 3

Wird nicht zur Eskalation gebracht, da nicht Go- Live verhindernd

Bei einem Teststillstand kann in der Regel - sofern notwendig - sofort eskaliert werden.

Bei der Definition von Workaround Lösungen sollte auch ein Zeitraum vereinbart werden, der für den Workaround praktikabel wie auch akzeptierbar ist.

Hettwer UnternehmensBeratung GmbH - Spezialisierte Beratung im Finanzdienstleistungssektor - Projektexpertise bei Banken & Versicherungen – Rollen Skill Abweichungsmanager - www.hettwer-beratung.de

Berichtswesen / Statusreporting

» Report einzelner/ aller/ neuer/ offener/ in Bearbeitung/ geschlossener Tickets

   nach entsprechenden Feldern/ Fehlerkategorien/ Priorität/ Erstellungsdatum etc.

» Reports zum Abweichungsmanagement nach Selektionskriterien

Fehlermanagement - Prozess

Zur Steuerung und Auswertung der Abweichungsprozesse müssen Vorgaben festgelegt werden.

Vorgaben zur Erfassung von Fehlern

» Jedes Ticket beschreibt immer nur einen Fehler

» Betreffzeile soll die Fehlerkategorie, die Testphase und eine Kurzbeschreibung des

   aufgetretenen Fehlers beinhalten

» Die Beschreibung eines Fehlers ist sachlich zu halten und umfasst sämtliche  Informationen,

   die die Entwicklung bei der Auffindung und Behebung des Fehlers unterstützt (verwendete

   Testdaten, Soll/Ist-Verhalten etc.)

» Erläuterung, welche Auswirkungen die Abweichung auf den Test bzw. auf die Produktion

   haben könnte

Workflow Defect-Bearbeitung anhand eines schematischen Beispiels :

Fehlerklassifikation

Die richtige Klassifikation (Gruppierung) von Fehlern ist für deren Analyse und Behebung, aber auch für die Bewertung des Behebungsfortschrittes sehr wichtig.

Die Klassifizierung von identifizierten Fehlerzuständen enthält häufig folgende Informationen:

• Testaktivität, die durchgeführt wurde, als der Fehlerzustand entdeckt wurde

• Testphase, in der der Fehlerzustand entdeckt wurde

• Grundursache des Fehlerzustands (z.B. Datenproblem)

• Wiederholbarkeit des Fehlerzustands (z.B. sporadisch)

• Symptome des Fehlerzustands (z.B. Systemabsturz)

• Quelle in dem der Fehler gemacht wurde (z.B. Datenbankdesign)

• Art des Fehlerzustands (z.B. Berechnungsproblem)

• Schweregrad (aus der Sicht des Anwenders) und Priorität des Fehlerzustandes

• Lösungsmöglichkeiten für Behebung Fehlerzustand (z.B. Programmänderung)

• Korrekturmaßnahmen nach Behebung Fehlerzustand (z.B. Konfigurationsdokumentation)

Fehlerklassifikation - Definition Severity

Fehlerzustände können beispielsweise nach deren Auswirkungen auf den Projektzeitplan, auf die Projektkosten, auf die Projektrisiken und auch auf die Projektqualität klassifiziert werden.

Derartige Klassifizierungen finden insbesondere ihre Beachtung bei der Entscheidungsfindung, wie schnell ein Fehler zu beheben ist.

Severity

Wirkung

Beispiel

1 - High

Software ist nicht einsatzfähig.

 

Fehler sind produktionsverhindernd

» Komplettabstürze

» Nicht abgefangene Fehler

» Applikation steht nicht zur Verfügung

» Grobe fachliche Umsetzungsfehler

» Daten werden nicht/ falsch gespeichert

» Grundlegende Funktionsprobleme

2 - Medium

Einschränkung der Funktionalität.

 

Fehler lassen eine Benutzung der Applikation nur mit Mühe zu

» Zugriff auf Daten ist möglich, obwohl

   nach Spezifikation verboten

» Funktionen werden angeboten, die

   gemäß Rolle nicht verfügbar sein sollten

3 - Low

Geringe Einschränkung der Funktionalität.

 

Fehler sind unschön, aber mit denen kann der Anwender „leben“

» Vorbelegung von Feldern entspricht

   nicht den Spezifikation

» Texte werden bei Ausgabe abgeschnitten

» Keine Plausibilitätsprüfung von

   Eingabewerten

Fehlerklassifikation - Definition Prioritäten

Eine Priorität gibt Auskunft über die Stufe der Wichtigkeit, die einem Fehlerzustand zugeordnet worden ist.

Priorität

Beschreibung zur Priorisierung von Fehlern

1 - High

Funktionalität ist für die Produktion zwingend erforderlich, jedoch nicht testbar bzw. die Testergebnisse sind fehlerhaft. Ein Work around ist nicht möglich.

2 - Medium

Funktionalität ist für die Produktion zwingend erforderlich, jedoch nicht testbar bzw. die Testergebnisse sind fehlerhaft. Ein Work around ist möglich.

3 - Low

Funktionalität ist für die Produktion nicht zwingend erforderlich. Sie ist nur eingeschränkt testbar bzw. die Testergebnisse sind fehlerhaft. Ein Work around ist nicht erforderlich.

Fehlerkategorisierung

Fehlerkategorisierung nach Priorität

Eine Fehlerklassifizierung nach Priorität gibt Auskunft über die Dringlichkeit von Fehlerbehebungsmaßnahmen, welche sich aus der Einschätzung des Fehlerschweregrades, des erforderlichen Korrekturaufwandes und der Auswirkungen auf den Testprozess ableitet.

Ein Fehlerzustand, der die Durchführung von weiteren Tests verhindert, ist beispielsweise eine hohe Priorität beizumessen.

Priorität

Beschreibung

1 - High

Fehlerbehebung ist so schnell wie möglich notwendig, da wesentliche Tests nicht oder nur stark eingeschränkt durchgeführt werden können.

2 - Medium

Fehlerbehebung ist spätestens zum nächsten Release notwendig, da wesentliche Tests für die betroffene Funktion zwar durchgeführt werden können, aber die Anzahl der durchzuführende Testfälle von der Behebung des Fehlers abhängig ist.

3 - Low

Fehlerbehebung ist nur bei Vorhandensein von freien Kapazitäten notwendig, da nur von ungeordneter Bedeutung und Auswirkung auf nur sehr wenige Testfälle.

Fehlerkategorisierung nach Schwergrad

Eine Fehlerklassifizierung nach Schwergrad gibt Auskunft über die Auswirkung, die ein Fehlerzustand auf Betrieb einer Softwareapplikation hat.

Priorität

Beschreibung

1 - High

Die gesamte Softwareapplikation oder wesentliche geschäftskritische Funktionalitäten stehen nicht zur Verfügung, sind instabil (Systemabstürze) oder (für das tägliche reguläre Arbeitsvolumen) nur zu langsam/ zu eingeschränkt nutzbar.

 

Es kommt zu Datenverlust, die Daten werden falsch gespeichert oder fehlerhafte Informationen oder Ergebnisse mit kritischen Auswirkungen auf wichtige Geschäftsprozesse werden geliefert.

 

Die Kommunikation mit Umsystemen führt zu schwerwiegenden Fehlern.

 

Es gibt keinen Work around, der zu einer anderen Einschätzung der Priorität führt oder er ist nur mit ungerechtfertigt hohem Zusatzaufwand darstellbar.

2 - Medium

Eine für die Softwareapplikation wesentliche einzelne Funktionalität steht nicht zur Verfügung, ist nur teilweise nicht erreichbar, ist nennenswert eingeschränkt oder reagiert so langsam, dass ein effizientes Arbeiten bzw. eine sinnvolle Nutzung stark erschwert wird.

 

Die Kommunikation mit Umsystemen führt zu Fehlern.

 

Es gibt einen vertretbaren Work around, der zu einer anderen Einschätzung der Priorität führt und ist zudem mit einem gerechtfertigten Zusatzaufwand darstellbar.

3 - Low

Eine für die Softwareapplikation nicht wesentliche einzelne Funktionalität steht nicht zur Verfügung, ist unkritisch fehlerhaft umgesetzt oder es treten geringfüge Beeinflussungen auf die Leistungsfähigkeit (Performance) auf.

 

Ein effizientes Arbeiten ist nicht nennenswert eingeschränkt und hat auch keine grundlegende Auswirkung auf irgendeinen wichtigen Geschäftsprozess.

 

Für die Problemlösung steht ein vertretbarer und effizienter Work around zur Verfügung.

Fehlerkategorisierung nach Status

Zur Fehlerklassifizierung gehört auch eine Bestimmung von möglichen bzw. zulässigen Fehlerzuständen, die gruppiert über einen dokumentierten Fehlerstatus ausgedrückt, konsistent verwendet und während ihres Lebenszyklus weiterverfolgt werden.

Fehlerstatus

Beschreibung

offen

Defect befindet sich noch nicht in einer Fehlerbearbeitung/ -verifizierung

erledigt/ behoben

Fehlerbehebung wurde durchgeführt.

geschlossen

Fehlerbehebung wurde erfolgreich getestet und ist beendet.

wiedereröffnet

Fehlerkorrektur war fehlerhaft, der Tester gibt den Defect an den Lösungsverantwortlichen zur erneuten Korrektur.

nicht

reproduzierbar

Fehlersituation kann nicht nachgestellt werden, daher keine Fehlerkorrektur möglich.

unlösbar

Fehler kann nicht behoben werden. Der Fachbereich muss entscheiden wie mit Fehlersituation umgegangen wird.

doppelt

Für den Defect gibt bereits einen gleichen Eintrag, der Sachverhalt ist zu überprüfen und einer der beiden Defects ist ggf. zurückziehen.

kein Fehler

Defect hat sich als kein Fehler herausgestellt und ist zu schließen.

zurückgestellt/

aufgeschoben

Fehlerkorrektur erst nach Abschluss der geplanten Testaktivitäten durchgeführt. Fachbereich muss entscheiden, ob Vorgehensweise machbar.

nicht behebbar

Fehler kann durch Lösungsverantwortlichen nicht behoben werden. Der Fachbereich muss entscheiden wie mit Fehlersituation umgegangen wird.

zugewiesen

Defect befindet sich beim jeweiligen Lösungsverantwortlichen in einer laufenden Fehlerbearbeitung

Re-Test

Fehlerbehebung wurde durchgeführt und steht auf den relevanten Testumgebungen zum Nachtest bereit

Hinweis: Die Gruppierung von Fehlerzuständen sollte sich möglichst auf eine notwendige Fehlerklassifizierung beschränken, da bei zu vielen Klassifizierungsfeldern die Bearbeitung von Fehlermeldungen relativ zeitintensiv ausfallen kann.

Fehlerkategorisierung nach Mängeln

Die Fehlerklassen/ Mängelklassen richten sich immer nach den entsprechenden Festlegungen, grundsätzlich gilt jedoch: Keine Änderungen am abgenommenen Ergebnisdokument ohne abgestimmtes und vereinbartes Vorgehen (CR- Verfahren).

Kategorie

Bedeutung

Erläuterung

Schwere Abweichung

» Go-Live verhindernd

 

wesentlicher Mangel

 

Ein ordnungsgemäßer Geschäftsbetrieb ist ausgeschlossen oder nur erheblich eingeschränkt möglich. Eine geschäftsschädigende Außenwirkung wäre die Folge und/oder die Erfüllung gesetzlicher Anforderungen wäre nicht gegeben oder eine Lieferung fachlich/technisch inkorrekter Ergebnisse und/oder Verfahrensabläufe liegt vor.

 

Behebung:

Behebung der Abweichungen in dem Testsystem vor Produktionseinführung, so dass ein Re- Test erfolgen kann und bei weiterhin auftretenden Abweichungen entsprechende Maßnahmen ergriffen werden können

Mittlere Abweichung

» nicht
   Go-Live verhindernd


nicht wesentlicher Mangel

 

Ein ordnungsgemäßer Geschäftsbetrieb ist nur unter Behinderungen möglich, die zu einer (Kunden-) Auswirkung führen, jedoch nicht zu einer geschäftsschädigenden Außenwirkung und/oder zu wesentlichem Mehraufwand für den Mandanten.

Behebung:

Ziel ist es einen Re- Test während des Testzeitraums zu ermöglichen. Eine Behebung bis Produktionsstart wird angestrebt. Sollte diese nicht möglich sein, wird für die jeweiligen Abweichungen ein Workaround erarbeitet und abgestimmt.

Leichte Abweichung

» nicht
   Go-Live verhindernd

 

geringfügiger Mangel

 

Mängel, die lediglich die Bereitstellung einer Zusatzinformation bedürfen und den grundsätzlichen Geschäftsbetrieb nicht behindern. Ein „Work around“ ist ohne einen wesentlichen Mehraufwand möglich.

Behebung:

Ziel ist es einen Re-Test während des Testzeitraums zu ermöglichen. Eine Behebung bis Produktionsstart ist wünschenswert. Ansonsten wird für die jeweiligen Abweichungen ein Workaround erarbeitet und abgestimmt

Eine Kumulation von Mängeln kann dazu führen, dass die Gesamtheit die Mängel eine höhere Kategorie Bewertung bedarf.

Fehlerbehebung

Der Fehlerschweregrad ergibt zusammen mit der Fehlerpriorität die zeitliche Reihenfolge der Fehlerbehebung vor.

Abweichungsbericht

In einem Abweichungsbericht werden alle Testereignisse dokumentiert, die nach dem Testen näher untersucht werden müssen. Bei der Untersuchung stellt sich jedoch oftmals nicht jede beim Testen gefundene Abweichung als Fehler heraus, da die Beschreibung von Anforderungen und Testfälle auch fehlerhaft sein kann.

Für jeden Fehler bzw. Abweichung muss jeweils ein eigener Abweichungsbericht erstellt werden, beispielsweise mit folgenden Inhalten:

  • Datum Entdeckung
  • Name Tester
  • Benennung Testumgebung
  • Benennung Testobjekts
  • SOLL Ergebnis Testfall
  • IST Ergebnis Testfall
  • Beschreibung Abweichung
  • Beschreibung Art der Abweichung bzw. Fehlerwirkung
  • Fehlerklasse/ Grad der Auswirkung
  • Priorität
  • Kennung der zugehörigen Anforderung
  • Kennung des zugehörigen Testfalls

Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH

Hettwer UnternehmensBeratung

Hettwer UnternehmensBeratung GmbH - Spezialisierte Beratung - Umsetzungsdienstleistungen im Finanzdienstleistungssektor – Experte im Projekt- und Interimsauftragsgeschäft - www.hettwer-beratung.de

H-UB ERFOLGSGESCHICHTE

Auszeichnung:

Gold-Partner-Zertifikat

Hettwer UnternehmensBeratung GmbH wurde aufgrund der erbrachten Beraterleistungen in den exklusiven Kreis der etengo Gold-Partner aufgenommen.

H-UB EXPERTENWISSEN

Hettwer UnternehmensBeratung GmbH – Expertenprofil Klaus Georg Hettwer (Geschäftsführer): Beratungskompetenz, Fachliche Kompetenz, Methodische Kompetenz, Soziale Kompetenz, Kommunikationskompetenz; Sonderthemen: SEPA, EMIR, TARGET2, MiFID, T2S

- Eine Beratung mit PROFIL -

H-UB Leistungskatalog

H-UB Leistungskatalog.pdf
Adobe Acrobat Dokument 89.4 KB

Projekt:

Hanseatische Container Logistik GmbH

Spedition, Logistik

Projekt:

WERDER BAU Bremen GmbH

Bauunternehmen

Projekt: Vino Bello

„La Dolce Vita“

 

H-UB SOCIAL MEDIA PRÄSENZ

© 2010-2024 Hettwer UnternehmensBeratung GmbH