defect management process
Einführung in den Fehlermanagementprozess:
Der gezieltere Prozess und das Testen ermöglichen weniger fehlerhafte Software auf dem Markt.
Fehlervermeidung ist viel effizienter und effektiver bei der Reduzierung der Anzahl von Fehlern und ist auch sehr kostengünstig bei der Behebung der Fehler, die in der frühen Phase des Softwareprozesses festgestellt wurden. Die meisten Organisationen führen Fehlererkennung , Fehlerbehebung und dann Prozessverbesserung das ist kollektiv bekannt als Fehlermanagementprozess .
Was ist der beste E-Mail-Dienst zu verwenden
Was du lernen wirst:
- Ziele des Fehlermanagementprozesses (DMP)
- Lebenszyklus des Fehlermanagements
- Fehlermanagementprozess
- Fazit
- Literatur-Empfehlungen
Ziele des Fehlermanagementprozesses (DMP)
Nachfolgend sind die verschiedenen Ziele dieses Prozesses aufgeführt:
- Verhindern Sie den Defekt
- Früherkennung
- Minimieren Sie die Auswirkungen
- Behebung des Mangels
- Prozessverbesserung
Bevor wir uns mit dem Fehlermanagementprozess befassen, lassen Sie uns zunächst verstehen Was ist eigentlich ein Defekt oder Fehler?
Lebenszyklus des Fehlermanagements
Wenn ein System eine andere Ausgabe als die tatsächliche Geschäftsanforderung liefert, d. H. Wenn eine Abweichung von der tatsächlichen oder ursprünglichen Geschäftsanforderung vorliegt, können wir sagen, dass ein Fehler im System / in der Software vorliegt.
Wenn das Testteam die Testfälle ausführt, stößt es auf eine Situation, in der das tatsächliche Testergebnis vom erwarteten Ergebnis abweicht. Diese Variation wird als bezeichnet Defekt .
Grundsätzlich ist ein Softwarefehler eine Bedingung, die die Softwareanforderung nicht erfüllt. Der Fehler ist ein Fehler oder eine Störung, die zu einem unerwarteten oder falschen Verhalten im System führt.
Um die Projekte angemessen zu behandeln, müssen Sie wissen, wie Sie mit der Entwicklung und Freigabe umgehen, aber auch, wie Sie mit Fehlern umgehen.
Stellen Sie sich vor, was passiert, wenn das Testteam die Fehler mündlich meldet und das Entwicklungsteam den Fehlerstatus auch mündlich aktualisiert? Der Prozess wird komplizierter, da diese Fehler alle Fehler umfassen, wie tatsächlich behoben und wie erwartet funktionieren, behoben, aber immer noch nicht funktionieren, zurückgewiesen, verschoben und der Prozess fortgesetzt wird.
In dem obigen Fall wird die Situation bald sehr schlimm sein, wenn die Anzahl der Fehler zunimmt und die Kommunikation mündlich erfolgt. Um den Fehler effektiv zu kontrollieren und zu behandeln, benötigen Sie einen ordnungsgemäßen Fehlerlebenszyklus.
Der Fehlerlebenszyklus stellt sicher, dass der Prozess einheitlich und standardisiert ist. Ein Defekt erreicht im Lebenszyklus unterschiedliche Zustände. Nachdem ein Defekt gefunden wurde, durchläuft er während seiner Lebensdauer verschiedene Stadien und ist allgemein bekannt als Fehlerlebenszyklus .
Im Allgemeinen beginnt der Fehlerlebenszyklus in der Phase, in der der Fehler vom Testteam gefunden oder gemeldet wird, und endet, wenn ein Fehler geschlossen wird, indem sichergestellt wird, dass er nicht reproduzierbar ist oder von einem Entwicklungsteam zurückgewiesen wird. Die Anzahl der Zustände, die ein Defekt durchläuft, variiert von Projekt zu Projekt.
Weiterführende Literatur:
Was ist der Fehler- / Fehlerlebenszyklus beim Testen von Software? Tutorial zum Fehlerlebenszyklus
Hinweis: Der folgende Zyklus unterscheidet sich geringfügig von Organisation zu Organisation.
Der folgende Fehlerlebenszyklus deckt alle möglichen Status ab:
- Immer wenn das Testteam einen Fehler in der Anwendung feststellt, wird der Fehler mit dem Status „ NEU ”.
- Wenn ein neuer Fehler von einem QS-Leiter überprüft wird und der Fehler gültig ist, lautet der Status des Fehlers „ Öffnen Und es ist bereit, dem Entwicklungsteam zugewiesen zu werden.
- Wenn ein QS-Leiter den Fehler dem entsprechenden Entwickler zuweist, wird der Status des Fehlers als „ Zugewiesen ”. Ein Entwickler sollte in diesem Stadium mit der Analyse und Behebung des Fehlers beginnen.
- Wenn der Entwickler der Ansicht ist, dass der Fehler nicht echt oder gültig ist, lehnt der Entwickler den Fehler ab. Der Status des Defekts ist mit „ Abgelehnt Und zurück an das Testteam vergeben.
- Wenn der protokollierte Fehler zweimal wiederholt wird oder beide gemeldeten Fehler ähnliche Ergebnisse und Schritte zur Reproduktion aufweisen, wird ein Fehlerstatus in „ Duplikat ”.
- Wenn es in der aktuellen Version einige Probleme oder Hürden zur Behebung eines bestimmten Fehlers gibt, wird der Fehler in den kommenden Versionen anstelle der aktuellen Version übernommen und dann als „ Aufgeschoben ' oder ' Aufgeschoben ”.
- Wenn ein Entwickler den Fehler nicht durch die vom Testteam unter „Schritte zum Reproduzieren“ genannten Schritte reproduzieren kann, kann der Entwickler den Fehler als „ Nicht reproduzierbar' . In dieser Phase sollte das Testteam einem Entwickler detaillierte Reproduktionsschritte zur Verfügung stellen.
- Wenn dem Entwickler nicht klar ist, welche Schritte von einer Qualitätssicherung zur Reproduktion des Fehlers zu reproduzieren sind, kann er ihn als „ Benötigen Sie weitere Informationen ”. In diesem Fall muss das Testteam dem Entwicklungsteam die erforderlichen Details zur Verfügung stellen.
- Wenn ein Fehler bereits bekannt ist und derzeit in der Produktionsumgebung vorhanden ist, wird der Fehler als „ Bekannter Defekt ”.
- Wenn ein Entwickler die erforderlichen Änderungen vornimmt, wird der Fehler als „ Fest ”.
- Der Entwickler leitet den Fehler nun zur Überprüfung an das Testteam weiter, sodass der Entwickler den Status als „ Bereit für den erneuten Test ”.
- Wenn der Fehler keine weiteren Probleme aufweist und ordnungsgemäß überprüft wurde, markiert der Tester den Fehler als „ Geschlossen ”.
- Wenn der Tester beim erneuten Testen des Fehlers feststellt, dass der Fehler immer noch reproduzierbar oder teilweise behoben ist, wird der Fehler als „ Wiedereröffnet ”. Jetzt muss der Entwickler diesen Defekt erneut untersuchen.
Ein gut geplanter und kontrollierter Fehlerlebenszyklus gibt die Gesamtzahl der Fehler an, die in einer Version oder in allen Versionen gefunden wurden. Dieser standardisierte Prozess gibt ein klares Bild davon, wie der Code geschrieben wurde, wie ordnungsgemäß die Tests durchgeführt wurden, wie der Fehler oder die Software freigegeben wurden usw. Dies verringert die Anzahl der Fehler in der Produktion, indem die Fehler in den Tests gefunden werden Phase selbst.
Fehlermanagementprozess
Der Fehlermanagementprozess wird nachstehend ausführlich erläutert.
# 1) Fehlervermeidung:
Fehlervermeidung ist die beste Methode, um die Fehler in der frühen Testphase zu beseitigen, anstatt die Fehler in der späteren Phase zu finden und dann zu beheben. Diese Methode ist auch kostengünstig, da die Kosten für die Behebung der in den frühen Testphasen festgestellten Mängel sehr gering sind.
Es ist jedoch nicht möglich, alle Fehler zu beseitigen, aber Sie können zumindest die Auswirkungen des Fehlers und die Kosten für dessen Behebung minimieren.
Die wichtigsten Schritte zur Fehlervermeidung sind folgende:
- Kritisches Risiko identifizieren : Identifizieren Sie die kritischen Risiken im System, die sich stärker auswirken, wenn sie während des Tests oder in einem späteren Stadium auftreten.
- Schätzen Sie die erwarteten Auswirkungen : Berechnen Sie für jedes kritische Risiko, wie hoch die finanziellen Auswirkungen wären, wenn das Risiko tatsächlich auftritt.
- Minimieren Sie die erwarteten Auswirkungen : Wenn Sie alle kritischen Risiken identifiziert haben, gehen Sie die höchsten Risiken ein, die für das System schädlich sein können, wenn sie auftreten, und versuchen Sie, das Risiko zu minimieren oder zu beseitigen. Für Risiken, die nicht beseitigt werden können, verringert sich die Eintrittswahrscheinlichkeit und ihre finanziellen Auswirkungen.
# 2) Lieferbare Basislinie:
Wenn ein Ergebnis (System, Produkt oder Dokument) seinen vordefinierten Meilenstein erreicht, können Sie sagen, dass ein Ergebnis eine Basis ist. In diesem Prozess bewegt sich das Produkt oder das Liefergegenstand von einer Stufe zur anderen, und wenn sich das Liefergegenstand von einer Stufe zur anderen bewegt, werden die vorhandenen Fehler im System auch auf den nächsten Meilenstein oder die nächste Stufe übertragen.
Zum Beispiel, Betrachten Sie ein Szenario aus Codierung, Komponententest und anschließendem Systemtest. Wenn ein Entwickler Codierungs- und Komponententests durchführt, werden die Systemtests vom Testteam durchgeführt. Hier ist Codierung und Unit Testing ein Meilenstein und System Testing ein weiterer Meilenstein.
Wenn der Entwickler beim Testen von Einheiten einige Probleme feststellt, wird dies nicht als Fehler bezeichnet, da diese Probleme vor Ablauf der Meilensteinfrist erkannt werden. Sobald die Codierung und der Komponententest abgeschlossen sind, übergibt der Entwickler den Code für den Systemtest, und Sie können sagen, dass der Code ist 'Baselined' und bereit für den nächsten Meilenstein. In diesem Fall handelt es sich hier um „Systemtests“.
Wenn nun die Probleme während des Testens identifiziert werden, wird dies als der Defekt bezeichnet, der nach Abschluss des früheren Meilensteins, d. H. Codierung und Komponententest, identifiziert wird.
Grundsätzlich werden die zu erbringenden Leistungen zugrunde gelegt, wenn die Änderungen an den zu erbringenden Leistungen abgeschlossen sind und alle möglichen Mängel identifiziert und behoben wurden. Dann wird das gleiche Ergebnis an die nächste Gruppe weitergegeben, die daran arbeiten wird.
# 3) Fehlererkennung:
Es ist fast unmöglich, alle Fehler aus dem System zu entfernen und ein System fehlerfrei zu machen. Sie können die Fehler jedoch frühzeitig erkennen, bevor sie für das Projekt kostspieliger werden. Wir können sagen, dass der entdeckte Defekt bedeutet, dass er dem Entwicklungsteam offiziell zur Kenntnis gebracht wird, und nach Analyse dieses Defekts hat das Defektentwicklungsteam ihn auch als Defekt akzeptiert.
Die Schritte zur Fehlererkennung sind wie folgt:
- Finden Sie einen Defekt : Identifizieren Sie Fehler, bevor sie zu einem Hauptproblem für das System werden.
- Fehler melden : Sobald das Testteam einen Defekt feststellt, ist es dafür verantwortlich, das Entwicklungsteam darauf aufmerksam zu machen, dass ein Problem identifiziert wurde, das analysiert und behoben werden muss.
- Fehler bestätigen : Sobald das Testteam den Fehler dem Entwicklungsteam zugewiesen hat, liegt es in der Verantwortung des Entwicklungsteams, den Fehler anzuerkennen und weiter zu beheben, wenn es sich um einen gültigen Fehler handelt.
# 4) Fehlerbehebung:
Im obigen Prozess hat das Testteam den Fehler identifiziert und dem Entwicklungsteam gemeldet. Hier muss das Entwicklungsteam nun mit der Behebung des Fehlers fortfahren.
Die Schritte zur Fehlerbehebung sind wie folgt:
- Priorisieren Sie das Risiko : Das Entwicklungsteam analysiert den Fehler und priorisiert die Behebung des Fehlers. Wenn ein Defekt mehr Auswirkungen auf das System hat, hat die Behebung des Defekts eine hohe Priorität.
- Beheben Sie den Defekt : Basierend auf der Priorität behebt das Entwicklungsteam den Fehler, Fehler mit höherer Priorität werden zuerst behoben und Fehler mit niedrigerer Priorität werden am Ende behoben.
- Melden Sie die Lösung : Es liegt in der Verantwortung des Entwicklungsteams, sicherzustellen, dass das Testteam weiß, wann die Fehler behoben werden und wie der Fehler behoben wurde, d. H. Indem eine der Konfigurationsdateien geändert oder einige Codeänderungen vorgenommen werden. Dies ist hilfreich für das Testteam, um die Ursache des Defekts zu verstehen.
# 5) Prozessverbesserung:
Obwohl bei der Fehlerbehebung die Fehler priorisiert und behoben werden, bedeutet dies aus Prozesssicht nicht, dass Fehler mit niedrigerer Priorität nicht wichtig sind und keine großen Auswirkungen auf das System haben. Unter dem Gesichtspunkt der Prozessverbesserung sind alle identifizierten Fehler dieselben wie ein kritischer Fehler.
Selbst diese geringfügigen Mängel bieten die Möglichkeit zu lernen, wie der Prozess verbessert und das Auftreten von Fehlern verhindert werden kann, die sich in Zukunft auf Systemausfälle auswirken können. Die Identifizierung eines Fehlers mit geringeren Auswirkungen auf das System ist möglicherweise keine große Sache, aber das Auftreten eines solchen Fehlers im System selbst ist eine große Sache.
Zur Prozessverbesserung muss jeder im Projekt zurückblicken und prüfen, woher der Fehler stammt. Auf dieser Grundlage können Sie Änderungen im Validierungsprozess, im Basisdokument und im Überprüfungsprozess vornehmen, um die Fehler zu Beginn des Prozesses zu erkennen, die kostengünstiger sind.
Fazit
Der Fehlermanagementprozess sollte während des gesamten Softwareentwicklungsprozesses befolgt werden und nicht nur für bestimmte Test- oder Entwicklungsaktivitäten.
Wenn in der Testphase ein Fehler gefunden wurde, kann die Frage aufgeworfen werden, ob, wenn der Fehler in dieser Phase erkannt wird, was ist mit den anderen im System vorhandenen Fehlern, die einen Systemfehler verursachen können, wenn er auftritt und noch nicht entdeckt wurde.
Daher müssen alle Prozesse wie Überprüfungsprozess, statische Tests, Inspektion usw. verstärkt werden, und jeder im Projekt sollte den Prozess ernst nehmen und wo immer nötig dazu beitragen. Die Geschäftsleitung der Organisation sollte auch den Fehlermanagementprozess verstehen und unterstützen.
Devops interviewen Fragen und Antworten für erfahrene
Testansätze, Überprüfungsprozess usw. sollten basierend auf dem Projektziel oder dem Organisationsprozess ausgewählt werden.
Ich hoffe, dieser informative Artikel zum Fehlermanagementprozess hilft Ihnen immens.
Literatur-Empfehlungen
- Was ist eine fehlerbasierte Testtechnik?
- Fehler-Triage-Prozess und Möglichkeiten zur Behandlung von Fehler-Triage-Besprechungen
- Was ist der Fehler- / Fehlerlebenszyklus beim Testen von Software? Tutorial zum Fehlerlebenszyklus
- Bugzilla Tutorial: Praktisches Tutorial zum Fehlermanagement-Tool
- Methoden und Techniken zur Fehlervermeidung
- Tutorial zum IBM Rational Team Concert-Fehlermanagement-Tool
- So reproduzieren Sie einen nicht reproduzierbaren Fehler und machen Ihren Testaufwand lohnenswert
- Beim Testen von Software dreht sich alles um Ideen (und wie man sie generiert)