Menü

Erste Schritte mit der Verfolgung und Verwaltung von Vorfällen beim Testen von Software (Beispielvorlagen enthalten)

  • Haupt
  • Bug Defect Tracking
  • Erste Schritte mit der Verfolgung und Verwaltung von Vorfällen beim Testen von Software (Beispielvorlagen enthalten)

getting started with incident tracking

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Im heutigen Artikel werden wir alles über die Prozess zur Verfolgung und Verwaltung von Vorfällen - Verfolgen und Verwalten von Vorfällen beim Testen von Software mit Beispielvorlagen.

Denken Sie: „STH hat viele Inhalte veröffentlicht Fehler- / Fehlerverfolgung Wie wird das anders sein? “ Genau aus diesem Grund müssen wir uns zuerst ansehen, was wir unter Vorfall verstehen.

Vorfallverfolgung und -verwaltung

Wie öffne ich Torrent-Dateien?

Was du lernen wirst:

Was ist ein Vorfall?

Vorfälle kann in einfachen Worten als ein Ereignis definiert werden, das während des Testens auftritt und überprüft werden muss.

Beim Testen, ob das tatsächliche Ergebnis vom erwarteten Ergebnis abweicht, wird es als Fehler, Defekt, Fehler, Problem, Fehler oder Vorfall bezeichnet. Meistens sind alle diese Begriffe synonym.

Vorfälle sind jedoch eine spezielle Kategorie von Problemen, die aufgrund von Fehlkonfiguration, beschädigten Daten oder Serverabsturz usw. auftreten können. Beispiele sind: Speicherplätze voll, Fehler bei der Ausführung (Laufzeitfehler), Dienst nicht verfügbar usw.

Vorfälle können auch aufgrund einiger Probleme bei der Softwareentwicklung, der Hardware-Nutzung oder bei Fehlern bei Serviceanfragen auftreten.

Unterschied zwischen Fehler, Defekt, Fehler und Vorfällen:

  1. Error :: Eine vom Menschen ausgeführte Aktion, die zu unerwartetem Systemverhalten führt.
    G.; falsche Syntax, falsche Berechnung der Werte, Missverständnis der Software
    Anforderung usw.
  2. Defekt: Dies ist ein Begriff, der normalerweise von Testern verwendet wird. Wenn der Tester einen Fehler oder ein Problem findet, wird dies als Fehler bezeichnet.
  3. Fehler: Fehler ist die Terminologie des Entwicklers. Sobald ein von einem Tester gefundener Fehler vom Entwickler akzeptiert wurde, wird er als Fehler bezeichnet. Das Beheben aller Fehler im System wird als Fehlerbehebung bezeichnet.
  4. Vorfall: Vorfall ist eine ungeplante Unterbrechung. Wenn der Betriebsstatus einer Aktivität von 'Arbeiten' in 'Fehlgeschlagen' wechselt und sich das System ungeplant verhält, handelt es sich um einen Vorfall. Ein Problem kann mehr als einen Vorfall verursachen, der behoben werden soll, vorzugsweise so bald wie möglich.

Schauen wir uns nun einige verwandte Begriffe an:

  1. Incident Repository :: Incident Repository kann als Datenbank definiert werden, die alle wichtigen und relevanten Daten zu allen im System auftretenden Incidents enthält. Diese Informationen werden anschließend zum Erstellen des Vorfallberichts verwendet. Es enthält Felder wie Daten, erwartete Ergebnisse, tatsächliches Ergebnis, Datum und Uhrzeit, Status des Vorfalls usw.
  2. Schwere: Die möglichen Auswirkungen des Vorfalls bestimmen die Schwere des Vorfalls. Es kann Major, Minor, Fatal oder Critical für eine sofortige Lösung sein.
  3. Priorität :: Je nach Schweregrad und Einfluss auf den Arbeitsstatus des Systems einstellen. Die Werte können hoch, mittel, niedrig, sehr hoch oder dringend / sofort sein.
  4. Vorfallstatus : Der aktuelle Status, in dem sich die Behandlung des Vorfalls befindet. Es kann neu, in Bearbeitung, gelöst und geschlossen sein.

Was ist Incident Management?

Incident Management ist ein Prozess zum Protokollieren, Aufzeichnen und Beheben von Incidents so schnell wie möglich, um den Geschäftsprozess oder Service wieder normal zu machen.

Incident Management-Prozess

Incident Management ist der gesamte Prozess, der von der Protokollierung von Incidents bis zur Lösung dieser Vorfälle reicht.

Dies ist ein sehr kritischer Prozess, da dadurch sichergestellt wird, dass die Vorfälle systematisch und effektiv behoben werden. Durch die Rationalisierung des gesamten Prozesses besteht außerdem eine gute Chance, dass die Probleme frühzeitig behoben werden.

Das Folgende ist eine schematische Darstellung des Prozesses und wir werden jede Stufe als nächstes im Detail diskutieren.

Incident Management-Prozess

# 1. Identifizierung und Protokollierung von Vorfällen ::
Die Identifizierung von Vorfällen erfolgt entweder durch Testen (mithilfe von Tools oder auf andere Weise), Benutzerfeedback, Überwachung der Infrastruktur usw.

Das Protokollieren eines Vorfalls bedeutet einfach das Aufzeichnen der folgenden Informationen:

  • Genaues / angemessenes Datum und Uhrzeit des Auftretens.
  • Vorfalltitel zusammen mit Typ und Kurzbeschreibung
  • Name der Person, die den Vorfall protokolliert hat, und detailliertere Beschreibung
    ggf. mit Fehlercodes
  • Angaben zu der Person, die dem Vorfall zur Nachverfolgung zugeordnet ist
  • Aktueller Status des Vorfalls
  • Anhänge einschließlich technischer Diskussionen, Entscheidungen und Genehmigungen

# 2. Klassifizierung und Priorisierung:

Durch die Klassifizierung von Vorfällen können wir sie nach Typ (Software, Hardware, Serviceanforderung usw.) partitionieren, um die Berichterstellung und Analyse zu vereinfachen. Die Priorisierung hilft dabei, die Reihenfolge / Priorität der zu behandelnden Vorfälle zu ermitteln. Dies hängt von der Auswirkung, dem Schweregrad und vor allem vom Risikofaktor ab.

#3. Untersuchung und Analyse: Dieser Schritt dient dazu, das Problem besser zu verstehen, damit wir es nicht nur sofort beheben, sondern auch Informationen sammeln, um ein erneutes Auftreten zu verhindern.

# 4. Auflösung und Wiederherstellung: Es werden Schritte unternommen, um den Vorfall zu beseitigen und das System wieder in seinen vorherigen Betriebszustand zu versetzen.

# 5. Schließung von Vorfällen: Die Lösung wird erneut getestet und falls das System wie beabsichtigt funktioniert, wird der Vorfall geschlossen.

Incident Management System

Das Incident Management kann sehr gut manuell oder statisch mithilfe von Tabellenkalkulationen durchgeführt werden, ist jedoch viel effektiver, dynamischer und systematischer, wenn es über ein Tool durchgeführt wird.

Ein Incident-Management-System wird von vielen Callcentern des Kundensupports verwendet, um Aktualisierungen zu erstellen und Vorfälle zu beheben.

Beliebte Tools für das Incident Management:

Einige beliebte Tools für das Incident Management, die zusätzlich zu Fehlern oder Defekten zum Verfolgen von Incidents verwendet werden können, sind:

# 1. Sitzen! (Support Incident Tracking):

Incident Tracking Tool 1

  • Support Incident Tracker (SiT) ist eine kostenlose Open Source- und webbasierte Anwendung, die PHP und MySQL für alle Plattformen verwendet und unterstützt. Es wird auch allgemein als 'Helpdesk' oder 'Support Ticket System' bezeichnet.
  • Nützlich, um E-Mails direkt von SiT zu senden, Dateien anzuhängen und jede Kommunikation im Vorfallprotokoll aufzuzeichnen. SiT ist sich der Service Level Agreements bewusst, und Vorfälle werden gekennzeichnet, wenn sie außerhalb von ihnen liegen.

# 2. JIRA:

Incident Tracking Tool 2
JIRA ist auch ein beliebtes proprietäres Incident Management-Tool, das von Atlassian entwickelt wurde und zur Fehler-, Fehler- oder Incident-Verfolgung verwendet wird. Es ist ein Java-basiertes Tool, das für Software und mobile Apps verwendet wird. Das JIRA-Schema umfasst Workflows, Berechtigungen, Konfigurationen, Problemtypen usw. JIRA unterstützt auch agile Tests.

Weitere Informationen und ein Tutorial finden Sie unter: JIRA-Tutorials.

#3. Incident Tracking System:
Incident Tracking System ist eine Software zur Verfolgung von Vorfällen. Es hilft, die Grundursache des Vorfalls zusammen mit einer geeigneten Lösung zu bestimmen und zu analysieren. Das Incident Tracking System ist einfach zu bedienen und bietet Datenbankunterstützung für die Verfolgung und Aufzeichnung des Incident.

Testvorfallbericht:

  1. Der Testvorfallbericht ist ein Eintrag, der im Fehlerrepository mit einer eindeutigen ID für jeden aufgetretenen Vorfall erstellt wurde. Der Testvorfallbericht dokumentiert alle Probleme, die während der verschiedenen Testphasen festgestellt wurden.
  2. IEEE 829-1998 ist das Standardformat für den Testvorfallbericht, mit dem jeder Vorfall dokumentiert wird, der während des Tests auftritt.

Die Übersicht über die IEEE 829-1998-Vorlage ist unten angegeben:

=> Laden Sie hier die IEEE Incident Tracking-Vorlage herunter.

Das Folgende ist eine kurze Erklärung der Felder:

# 1. Identifizieren : Gibt eine eindeutige ID und eine vom Unternehmen generierte Nummer an, um einen Vorfall zu identifizieren und zu lokalisieren.

wie man einem Array Java ein Element hinzufügt

# 2. Zusammenfassung : Fasst den Vorfall kurz zusammen. Enthält ausreichende Details, um verwandte Fakten zu verstehen, nämlich. Referenzen, zugehörige Testverfahren, Version der Software, Testfälle usw.

#3. Beschreibung des Vorfalls: Beschreibt den Vorfall mit folgenden Details: Eingaben

  • erwartetes Ergebnis
  • Tatsächliche Ergebnis
  • Versuch es zu wiederholen
  • Anomalien
  • Datum (und Uhrzeit
  • Verfahrensschritt
  • Name des Testers

Das Format des Incident Tracking-Berichts kann gemäß den Industriestandards und Geschäftsanforderungen geändert werden.

Ein Beispiel für eine Verwendung in einem Unternehmen ist:

=> Laden Sie hier die geänderte Vorlage für Vorfallberichte herunter.

Fazit:

Da dieser Artikel zeigt, dass sich das Incident Management nicht wesentlich von der Fehlerverfolgung unterscheidet, ist dies eine wunderbare Zusammenfassung des Prozesses mit einigen ISO-Standard- und praktischen Vorlagen aus dem wirklichen Leben.

Ein weiteres Wort der Vorsicht, mit dem wir Sie alle verlassen möchten, bevor Sie diesen Artikel beenden, lautet: Versuchen Sie, sich nicht zu sehr an die Definition von Fehler / Defekt / Vorfall usw. zu halten, da die meisten Unternehmen nicht zwischen einem Begriff und dem anderen unterscheiden. Daher werden sie alle die meiste Zeit synonym verwendet. Außerdem gibt es einige Unternehmen, die ihre Dokumentationsinkonsistenzen als Vorfälle und andere Probleme mit der Anrufumgebung als Vorfälle bezeichnen. Sie sehen also, dass sich die Dialekte mit den Regionen ändern, ebenso wie die technische Qualitätssicherung Terminologie. Was wir Ihnen bringen, ist die Mehrheit, nicht die Norm - Ausnahmen existieren immer.

Fröhliches Lesen!

Literatur-Empfehlungen

^