Testkonzept - Defectprozess

• Erkennung
  Tester identifizieren Abweichungen vom erwarteten Ergebnis während der Testdurchführung. Dies kann technische Fehler, fehlerhafte Eingaben oder falsche Ergebnisse umfassen.
  
  
• Dokumentation
  Der Tester dokumentiert jeden Fehler detailliert, einschließlich der Bedingungen unter denen der Fehler auftrat, Schritte zur Reproduktion und möglicherweise Screenshots oder Log-Dateien.

• Einreichung
  Fehler werden vom Tester in einem Defect-Tracking-System eingestellt. Dies geschieht unabhängig davon, wer die Tests durchführt.
  
  
• Zuweisung
  Fehler werden in der Regel automatisch oder manuell vom Defect-Tracking-System dem Defectmanager zugewiesen.

• Weiterleitung
  Der Defectmanager prüft den Fehler und leitet ihn an den zuständigen Lösungsverantwortlichen weiter, der für die Behebung des Fehlers verantwortlich ist.
  
  
• Koordination
  Der Defectmanager arbeitet eng mit dem Releasemanager zusammen, um zu bestimmen, wann und nach welchen Kriterien Fehlerkorrekturen für einen Nachtest bereitgestellt werden.

• Überwachung
  Defectkoordinatoren stellen sicher, dass für ihren jeweiligen Bereich ein aktives Fehlertracking stattfindet. Sie überwachen den Status aller gemeldeten Fehler und koordinieren die Behebungsmaßnahmen.
  
  
• Statusaktualisierungen
  Regelmäßige Aktualisierungen im Defect-Tracking-System halten alle Beteiligten über den Fortschritt der Fehlerbehebung informiert.

• Nachtest
  Nachdem Fehler behoben wurden, wird ein Nachtest durchgeführt, um sicherzustellen, dass die Korrekturen wirksam sind und keine neuen Probleme eingeführt wurden.
  
  
• Schließen von Fehlern
  Sobald bestätigt wird, dass ein Fehler erfolgreich behoben wurde, wird er im Tracking-System geschlossen.

Die Priorisierung von Fehlern in einem Testprozess ist entscheidend, um effizient Ressourcen zuzuweisen und sicherzustellen, dass kritische Fehler schnell behoben werden. Die Priorität eines Fehlers wird typischerweise basierend auf seiner Auswirkung auf das Gesamtsystem und die Geschäftsprozesse bestimmt, unabhängig von der Priorität des Testfalls, in dem der Fehler gefunden wurde.

• Testfall "Kundenanlage" (Hohe Priorität)
  Dieser Testfall ist entscheidend, da die Kundenanlage ein zentrales Element der Geschäftsprozesse ist.
  
  
• Aufgedeckter Fehler
  Im Rahmen dieses Testfalls wird festgestellt, dass das Notizfeld, das statt der geforderten 500 nur 250 Zeichen zulässt.

1. Fehlerklassen
   • Kritische Fehler
     Beeinträchtigen zentrale Geschäftsfunktionen oder Sicherheitsaspekte des Systems (z.B. Systemabstürze, Datenverlust).
     
     
   • Hohe Priorität
     Beeinflussen wichtige Funktionalitäten, bieten jedoch mögliche Workarounds.
     
     
   • Mittlere Priorität
     Beeinträchtigen weniger kritische Funktionen oder sind nur unter bestimmten Bedingungen problematisch.
     
     
   • Geringe Priorität
     Haben minimale Auswirkungen auf die Benutzbarkeit oder Performance des Systems, wie im Beispiel das Notizfeld.
2. Reaktionszeiten
   • Kritische Fehler
     Sofortige Bearbeitung und schnellstmögliche Behebung.
     
     
   • Hohe Priorität
     Schnelle Reaktion erforderlich, Behebung im aktuellen oder nächsten Release.
     
     
   • Mittlere Priorität
     Planmäßige Behebung in einem der kommenden Releases.
     
     
   • Geringe Priorität
     Behebung, wenn Ressourcen verfügbar sind oder im Rahmen von größeren Updates.

Die Festlegung von Fehlerklassen und entsprechenden Reaktionszeiten ermöglicht eine strukturierte und effiziente Fehlerbehandlung. Durch die klare Trennung der Priorität eines Testfalls und der Priorität eines aufgedeckten Fehlers kann das Testteam sicherstellen, dass Ressourcen gezielt dort eingesetzt werden, wo sie den größten Einfluss auf die Qualität und Stabilität des Produkts haben.

• Dokumentation
  Jeder Fehler wird im Defect-Tracking-System erfasst mit Informationen über die Umstände seines Auftretens, die betroffene Funktionalität und seine Auswirkungen.
  
  
• Bewertung
  Die Priorisierung erfolgt durch eine gemeinsame Bewertung von Testmanagern, Entwicklern und ggf. Stakeholdern, basierend auf den potenziellen Auswirkungen des Fehlers.
  
  
• Kommunikation
  Die festgelegte Priorität und die geplanten Reaktionszeiten werden an alle beteiligten Teams kommuniziert, um eine angemessene Reaktion sicherzustellen.

Die Klassifizierung von Fehlern nach diesen vier Prioritätsstufen ermöglicht eine effektive Steuerung des Behebungsprozesses und stellt sicher, dass kritische Fehler mit den größten potenziellen Auswirkungen auf das Geschäft oder die Compliance prioritär behandelt werden.

• Beschreibung
  Diese Klasse umfasst Fehler, die eine kritische Auswirkung auf das System haben, indem sie die Weiterverarbeitung komplett blockieren oder schwerwiegende Abweichungen von den Spezifikationen darstellen, die zu Datenverlust oder rechtlichen Problemen führen könnten.
  
  
• Beispiele
  
• • Systemabstürze oder schwerwiegende Programmfehler, die eine notwendige Funktion unterbrechen.
  • Fehler, die falsche Ergebnisse liefern, was zu fehlerhafter Rechnungslegung führen kann.
  • Datenverlust oder Datenzerstörung.
  • Verstöße gegen wesentliche gesetzliche oder quasi-gesetzliche Bestimmungen.
• Maßnahmen
  Sofortige Behebung erforderlich; diese Fehler gelten als abnahmeverhindernd.

• Beschreibung
  Fehler in dieser Kategorie beeinträchtigen wichtige Funktionen oder Geschäftsabläufe erheblich, können jedoch oft durch organisatorische Maßnahmen oder durch Workarounds umgangen werden.
  
  
• Maßnahmen
  Entscheidung über die Abnahmeverhinderung wird im Lenkungsausschuss getroffen; schnelle Behebung wird empfohlen.

• Beschreibung
  Diese Fehler beeinträchtigen die Nutzung des Systems, ohne jedoch wesentliche Funktionen zu verhindern. Sie weichen von den Spezifikationen ab, aber die Weiterverarbeitung ist möglich.
  
  
• Beispiele
• • Fehler, die die Benutzung einschränken, jedoch keine kritischen Prozesse blockieren.
  • Verstöße gegen sonstige gesetzliche und quasi-gesetzliche Bestimmungen, die nicht in Klasse 1 fallen.
    
    
• Maßnahmen
  Behebung nach Priorität und Verfügbarkeit der Ressourcen.

• Beschreibung
  Geringfügige Fehler, die kleinere Abweichungen von den Spezifikationen darstellen, aber keinerlei Auswirkung auf die Funktionalität oder Geschäftsabläufe haben.
  
  
• Maßnahmen
  Behebung kann geplant und bei Gelegenheit durchgeführt werden, ohne sofortige Auswirkungen auf das Projekt zu haben.

Die klar definierten Fehlerklassen und die zugeordneten Reaktionszeiten bilden das Rückgrat des Fehlerbehebungsprozesses in Softwareentwicklungsprojekten. Durch die Festlegung spezifischer Fristen und Prozesse wird sichergestellt, dass alle Teams effizient zusammenarbeiten, um die Softwarequalität durchgängig hochzuhalten und die Einhaltung des Projektzeitplans zu gewährleisten.

• Priorität 1 – Blocking (Produktionsverhindernd und testverhindernd)
• • Reaktionszeit
    Für Fehler der Klasse 1 ist eine Fehlerbeseitigung innerhalb von z.B. 10 Arbeitstagen erforderlich.
    
    
  • Maßnahme
    Angesichts der Dringlichkeit dieser Fehler müssen schnelle und effektive Lösungen bereitgestellt werden, um den Test- und Produktionsbetrieb so schnell wie möglich wiederherzustellen.
    
    
• Priorität 2 – Serious
• • Reaktionszeit
    Fehler dieser Klasse werden innerhalb von z.B. 20 Arbeitstagen behoben.
    
    
  • Zusätzliche Bedingungen
    Die Bearbeitungszeit kann sich verlängern, wenn mehrere Fehler innerhalb einer Komponente parallel bearbeitet werden müssen. In solchen Fällen ist die Situation zu kommunizieren und die betroffenen Parteien müssen eine angemessene Behebungszeit aushandeln.
    
    
  • Kommunikation:
    Die Information über aufgetretene Fehler und deren Status erfolgt durch die zuständige Organisation
    
    
• Priorität 3 – Medium
• • Reaktionszeit:
    Für Fehler dieser Klasse gilt eine standardmäßige Behebungsfrist durch den Auftragnehmer innerhalb von z.B. 60 Arbeitstagen.
    
    
  • Maßnahme:
    Diese Fehler werden mit einer weniger dringenden Priorität behandelt, was den Teams mehr Flexibilität in der Planung und Ressourcenzuweisung ermöglicht.
    
    
• Priorität 4 – Low
• • Reaktionszeit
    Für Fehler der niedrigsten Klasse sind oft keine festen Reaktionszeiten definiert, und diese werden nach Bedarf und Verfügbarkeit der Ressourcen behandelt.

• Schnelligkeit und Effektivität
  Die schnelle Behebung von kritischen Fehlern ist entscheidend, um die Auswirkungen auf den Testbetrieb und die Produktionsumgebung zu minimieren.
  
  
• Kommunikation und Transparenz
  Regelmäßige Updates und transparente Kommunikation zwischen allen beteiligten Parteien (wie dem Testteam, Entwicklern und dem Management) sind wesentlich, um den Prozess effizient zu gestalten.
  
  
• Dokumentation
  Eine gründliche Dokumentation des Fehlerbehebungsprozesses hilft, die Nachvollziehbarkeit der Maßnahmen zu gewährleisten und ist wichtig für zukünftige Referenzen und Qualitätsaudits.

• Detaillierte Verfahren
  Das Defectmanagementkonzept enthält detaillierte Informationen zum gesamten Defectprozess, einschließlich Richtlinien für die Fehlerdokumentation, Meldeverfahren und Kriterien für die Fehlerbehebung.