defect severity priority testing with examples
In diesem Lernprogramm erfahren Sie anhand von Beispielen, wie Sie den Schweregrad und die Priorität von Fehlern beim Testen festlegen, wie Sie die Priorität und den Schweregrad von Fehlern festlegen, um das Konzept klar zu verstehen.
Wir werden auch detailliert beschreiben, wie die Fehler unter verschiedenen Eimern klassifiziert werden und wie sie für den Fehlerlebenszyklus relevant sind. Wir werden auch die entscheidende Rolle der Klassifizierung anhand einer Reihe von Beispielen behandeln.
Einreichungsfehler sind sehr wichtig Teil des Software Testing Life Cycle . Es sind mehrere Best Practices für definiert effektive Fehlerberichterstattung über das Internet oder in Organisationen.
Was du lernen wirst:
- Fehlerverfolgungsübersicht
Fehlerverfolgungsübersicht
Einer der wichtigen Aspekte des Fehlerlebenszyklus auf allgemeiner Ebene ist die Fehlerverfolgung. Dies ist wichtig, da Testteams beim Testen einer Software mehrere Fehler aufweisen, die nur dann multipliziert werden, wenn das zu testende System komplex ist. In einem solchen Szenario kann das Verwalten dieser Fehler und das Analysieren dieser Fehler zum Schließen des Laufwerks eine entmutigende Aufgabe sein.
In Übereinstimmung mit den Verfahren zur Fehlerwartung muss ein Tester, wenn er einen Fehler einreicht, abgesehen von der Methode / Beschreibung, um das festgestellte Problem zu reproduzieren, auch einige kategoriale Informationen bereitstellen, die eine ungenaue Klassifizierung des Fehlers unterstützen. Dies würde wiederum zu effizienten Prozessen zur Fehlerverfolgung / -wartung beitragen und auch die Grundlage für eine schnellere Fehlerumlaufzeit bilden.
Die beiden Hauptparameter, die die Grundlage für eine effektive Fehlerverfolgung und -behebung bilden, sind:
- Fehlerpriorität beim Testen
- Fehlerschweregrad beim Testen
Diese Konzepte sind oft verwirrend und werden nicht nur von Testteams, sondern auch von Entwicklungsteams fast synonym verwendet. Es gibt eine feine Linie zwischen den beiden und es ist wichtig zu verstehen, dass es tatsächlich Unterschiede zwischen den beiden gibt.
Lassen Sie uns die theoretischen Definitionen der beiden Parameter im nächsten Abschnitt kurz verstehen.
Was ist der Schweregrad und die Priorität von Fehlern?
Die Priorität der englischen Definition wird beim Vergleich von zwei Dingen oder Bedingungen verwendet, bei denen einem mehr Bedeutung beigemessen werden muss als dem anderen und zuerst angegangen / gelöst werden muss, bevor mit dem nächsten fortgefahren wird. Daher würde im Zusammenhang mit Mängeln die Priorität eines Mangels die Dringlichkeit anzeigen, mit der er behoben werden müsste.
Der Schweregrad nach englischer Definition wird verwendet, um den Schweregrad eines unerwünschten Ereignisses zu beschreiben. Wenn es um Fehler geht, zeigt der Schweregrad eines Fehlers die Auswirkung auf das System in Bezug auf seine Auswirkungen an.
Wer definiert diese?
Die Qualitätssicherung klassifiziert den Fehler anhand der Komplexität und Kritikalität der Fehler unter angemessener Schwere.
Alle Geschäftsinteressenten, einschließlich der Projektmanager, Geschäftsanalysten und Produktbesitzer, definieren die Priorität der Fehler.
Die folgende Abbildung zeigt die Rolle, die die Kritikalität und Schwere der Fehler besitzt und klassifiziert.
Wie wähle ich diese Ebenen aus?
Wie bereits erwähnt, wird der Schweregradparameter vom Tester bewertet, während der Prioritätsparameter hauptsächlich vom Produktmanager oder im Grunde vom Triage-Team bewertet wird. Auch wenn dies der Fall ist, ist die Schwere eines Defekts definitiv einer der bestimmenden und beeinflussenden Faktoren für die Priorisierung des Defekts. Daher ist es als Tester wichtig, den richtigen Schweregrad auszuwählen, um Verwechslungen mit Entwicklungsteams zu vermeiden.
Unterschied zwischen Schweregrad und Priorität
Die Priorität ist mit der Planung verbunden, und der „Schweregrad“ ist mit Standards verbunden.
'Priorität' bedeutet, dass etwas gewährt wird oder vorherige Aufmerksamkeit verdient; Vorrang nach Wichtigkeit (oder Dringlichkeit).
'Schweregrad' ist der Zustand oder die Qualität des Schweregrads; schwerwiegend impliziert die Einhaltung strenger Standards oder hoher Prinzipien und deutet oft auf Härte hin; schwerwiegend ist gekennzeichnet durch oder erfordert die strikte Einhaltung strenger Standards oder hoher Grundsätze. Zum Beispiel, ein strenger Verhaltenskodex.
Die Wörter Priorität und Schweregrad tauchen bei der Fehlerverfolgung auf.
Eine Vielzahl von kommerziellen Software-Tools zur Problemverfolgung / -verwaltung ist verfügbar. Diese Tools geben dem Team mit der detaillierten Eingabe von Software-Testingenieuren vollständige Informationen, damit Entwickler den Fehler verstehen, sich ein Bild vom Schweregrad machen, ihn reproduzieren und beheben können.
Die Korrekturen basieren auf dem Projekt 'Prioritäten' und 'Schweregrad' der Fehler.
Der „Schweregrad“ eines Problems wird gemäß der Risikobewertung des Kunden definiert und in seinem ausgewählten Tracking-Tool aufgezeichnet.
Buggy-Software kann die Zeitpläne „stark“ beeinflussen, was wiederum zu einer Neubewertung und Neuverhandlung von „Prioritäten“ führen kann.
Was ist Priorität?
Wie der Name schon sagt, geht es bei der Priorität darum, einen Fehler anhand der Geschäftsanforderungen und der Schwere des Fehlers zu priorisieren. Priorität bezeichnet die Wichtigkeit oder Dringlichkeit der Behebung eines Mangels.
Während des Öffnens eines Fehlers weist der Tester die Priorität im Allgemeinen zunächst zu, wenn er das Produkt aus der Sicht des Endbenutzers betrachtet. In Übereinstimmung mit diesen gibt es verschiedene Ebenen:
Grundsätzlich kann die Priorität der Mängel wie folgt klassifiziert werden:
Priorität 1) Sofort / Kritisch (P1)
Dies muss sofort innerhalb von 24 Stunden behoben werden. Dies tritt im Allgemeinen in Fällen auf, in denen eine gesamte Funktionalität blockiert ist und daher kein Test durchgeführt werden kann. In bestimmten anderen Fällen, in denen erhebliche Speicherlecks auftreten, wird der Fehler im Allgemeinen als Priorität -1 klassifiziert, was bedeutet, dass das Programm / die Funktion im aktuellen Status unbrauchbar ist.
Jeder Defekt, der sofortige Aufmerksamkeit erfordert und sich auf den Testprozess auswirkt, wird in die unmittelbare Kategorie eingestuft
All die Kritische Schwere Mängel fallen unter diese Kategorie (sofern sie nicht von Unternehmen / Stakeholdern neu priorisiert werden)
Priorität 2) Hoch (P2)
Sobald die kritischen Fehler behoben wurden, ist ein Fehler mit dieser Priorität der nächste Kandidat, der behoben werden muss, damit eine Testaktivität die „Exit“ -Kriterien erfüllt. Normalerweise kann ein Fehler für Priorität 2 qualifiziert werden, wenn eine Funktion aufgrund eines Programmfehlers nicht so verwendet werden kann, wie es sein soll, oder wenn neuer Code geschrieben werden muss oder manchmal sogar, weil ein Umweltproblem durch den Code behandelt werden muss .
Dies ist der Fehler oder das Problem, das behoben werden sollte, bevor die Freigabe erfolgt. Diese Mängel sollten behoben sein, sobald die kritischen Probleme behoben sind.
All die Haupt Schwere Mängel fallen in diese Kategorie.
Priorität 3) Mittel (P3)
Ein Fehler mit dieser Priorität muss in Konflikt geraten, um behoben zu werden, da er auch Funktionsprobleme behandeln kann, die nicht den Erwartungen entsprechen. Manchmal können sogar kosmetische Fehler, wie das Erwarten der richtigen Fehlermeldung während des Fehlers, als Fehler der Priorität 3 eingestuft werden.
Dieser Fehler sollte behoben werden, nachdem alle schwerwiegenden Fehler behoben wurden.
Sobald die kritischen und die Fehler mit hoher Priorität behoben sind, können wir die Fehler mit mittlerer Priorität beheben.
All die Geringer Schwere Mängel fallen in diese Kategorie.
Priorität 4) Niedrig (P4)
Ein Fehler mit niedriger Priorität weist darauf hin, dass definitiv ein Problem vorliegt, das jedoch nicht behoben werden muss, um die 'Exit' -Kriterien zu erfüllen. Dies muss jedoch behoben werden, bevor die GA abgeschlossen ist. Typischerweise können einige Tippfehler oder sogar kosmetische Fehler, wie zuvor erläutert, hier kategorisiert werden.
Manchmal werden auch Fehler mit niedriger Priorität geöffnet, um einige Verbesserungen im vorhandenen Design oder eine Anforderung zur Implementierung einer kleinen Funktion zur Verbesserung der Benutzererfahrung vorzuschlagen.
Dieser Mangel kann in Zukunft behoben werden und bedarf keiner sofortigen Aufmerksamkeit Geringe Schwere Mängel fallen in diese Kategorie.
Wie bereits erwähnt, bestimmt die Priorität, wie schnell die Fehlerbearbeitungszeit sein muss. Wenn mehrere Fehler vorliegen, entscheidet die Priorität, welcher Fehler sofort behoben und überprüft werden muss, und welcher Fehler etwas später behoben werden kann.
Was ist Schweregrad?
Der Schweregrad definiert das Ausmaß, in dem ein bestimmter Fehler Auswirkungen auf die Anwendung oder das System haben kann.
Der Schweregrad ist ein Parameter, der die Auswirkung eines Fehlers auf das System angibt. Wie kritisch ist der Fehler und wie wirkt sich der Fehler auf die Funktionalität des gesamten Systems aus? Der Schweregrad ist ein vom Tester festgelegter Parameter, während er einen Defekt öffnet und hauptsächlich die Kontrolle über den Tester hat. Wiederum haben verschiedene Organisationen unterschiedliche Tools für Fehler, aber auf allgemeiner Ebene sind dies die folgenden Schweregrade:
Zum Beispiel, Betrachten Sie die folgenden Szenarien
- Wenn der Benutzer versucht, online einzukaufen, und die Anwendung nicht geladen wird oder eine nicht verfügbare Servermeldung angezeigt wird.
- Der Benutzer fügt einen Artikel zum Warenkorb hinzu. Die Anzahl der hinzugefügten Mengen ist falsch. Es wird ein falsches Produkt hinzugefügt.
- Der Benutzer leistet die Zahlung und nach der Zahlung bleibt die Bestellung als reserviert im Warenkorb, statt bestätigt.
- Das System nimmt die Bestellung an, storniert sie jedoch nach einer halben Stunde aufgrund von Problemen.
- Das System akzeptiert die Option 'In den Warenkorb' nur per Doppelklick anstatt mit einem einzigen Klick.
- Die Schaltfläche In den Warenkorb wird als In den Warenkorb geschrieben geschrieben.
Wie wäre die Benutzererfahrung, wenn eines der oben genannten Szenarien eintreten könnte?
Grundsätzlich können die Mängel wie folgt klassifiziert werden:
# 1) Kritisch (S1)
Ein Defekt, der das Testen des Produkts / der Funktion vollständig behindert oder blockiert, ist ein kritischer Defekt. Ein Beispiel wäre der Fall von UI-Tests, bei denen die UI nach dem Durchlaufen eines Assistenten nur in einem Bereich hängt oder nicht weiter geht, um die Funktion auszulösen. Oder in einigen anderen Fällen, wenn das selbst entwickelte Feature im Build fehlt.
Aus irgendeinem Grund kann der Fehler als kritisch eingestuft werden, wenn die Anwendung abstürzt oder unbrauchbar wird / nicht mehr fortfahren kann.
Jegliche katastrophalen Systemausfälle können dazu führen, dass der Benutzer nicht verwendbar ist. Die Anwendungen können dem kritischen Schweregrad zugeordnet werden
Zum Beispiel, Bei E-Mail-Dienstanbietern wie Yahoo oder Google Mail stürzt das System nach Eingabe des richtigen Benutzernamens und des richtigen Kennworts ab, anstatt sich anzumelden, und gibt die Fehlermeldung aus. Dieser Fehler wird als kritisch eingestuft, da dieser Fehler die gesamte Anwendung unbrauchbar macht.
Das oben diskutierte Szenario zu Punkt 1 könnte als kritischer Fehler eingestuft werden, da die Online-Bewerbung vollständig unbrauchbar wird.
# 2) Major (S2)
Alle implementierten Hauptfunktionen, die nicht den Anforderungen / Anwendungsfällen entsprechen und sich anders als erwartet verhalten, können unter Schweregrad klassifiziert werden.
Ein schwerwiegender Fehler tritt auf, wenn die Funktionalität weit außerhalb der Erwartungen funktioniert oder nicht das tut, was sie tun sollte. Ein Beispiel könnte sein: Angenommen, ein VLAN muss auf dem Switch bereitgestellt werden, und Sie verwenden eine UI-Vorlage, die diese Funktion auslöst. Wenn diese Vorlage zum Konfigurieren von VLAN auf dem Switch fehlschlägt, wird sie als schwerwiegender Funktionsnachteil eingestuft.
Zum Beispiel, Wenn Sie im E-Mail-Dienstanbieter wie Yahoo oder Google Mail nicht mehr als einen Empfänger im CC-Bereich hinzufügen dürfen, wird dieser Fehler als Hauptfehler eingestuft, da die Hauptfunktionalität der Anwendung nicht ordnungsgemäß funktioniert.
Was das Verhalten des CC-Abschnitts in der Mail erwartet, sollte es dem Benutzer ermöglichen, mehrere Benutzer hinzuzufügen. Wenn die Hauptfunktionalität der Anwendung nicht ordnungsgemäß funktioniert oder sich anders als erwartet verhält, liegt ein schwerwiegender Fehler vor.
Die oben diskutierten Szenarien zu Punkt 2 und 3 könnten als schwerwiegender Fehler eingestuft werden, da erwartet wird, dass die Bestellung reibungslos in die nächste Phase des Auftragslebenszyklus übergeht, in Wirklichkeit jedoch im Verhalten variiert.
Jeder Fehler, der zu falscher Datenpersistenz, Datenproblemen oder falschem Anwendungsverhalten führen kann, kann grob dem Schweregrad Major zugeordnet werden.
# 3) Klein / Mittel (S3)
Jede implementierte Funktion, die ihren Anforderungen / Anwendungsfällen nicht entspricht und sich anders als erwartet verhält, deren Auswirkungen jedoch bis zu einem gewissen Grad vernachlässigbar sind oder die keine wesentlichen Auswirkungen auf die Anwendung haben, kann als geringfügiger Schweregrad eingestuft werden.
Ein mäßiger Fehler tritt auf, wenn das Produkt oder die Anwendung bestimmte Kriterien nicht erfüllt oder dennoch ein unnatürliches Verhalten aufweist. Die Funktionalität insgesamt wird jedoch nicht beeinträchtigt. Beispielsweise würde in der oben bereitgestellten VLAN-Vorlagenbereitstellung ein mäßiger oder normaler Fehler auftreten, wenn die Vorlage erfolgreich auf dem Switch bereitgestellt wird. Es wird jedoch kein Hinweis an den Benutzer gesendet.
Zum Beispiel, In dem E-Mail-Dienstanbieter wie Yahoo oder Google Mail gibt es die Option 'Allgemeine Geschäftsbedingungen'. In dieser Option gibt es mehrere Links zu den Nutzungsbedingungen der Website. Wenn einer der mehreren Links nicht ordnungsgemäß funktioniert, Es wird als geringfügiger Schweregrad bezeichnet, da es nur geringfügige Funktionen der Anwendung beeinträchtigt und keinen großen Einfluss auf die Benutzerfreundlichkeit der Anwendung hat.
Das oben diskutierte Szenario zu Punkt 5 könnte als geringfügiger Fehler eingestuft werden, da es keinen Datenverlust oder -fehler in der Systemflussreihenfolge gibt, sondern eine leichte Unannehmlichkeit in Bezug auf die Benutzererfahrung.
Diese Arten von Fehlern führen zu einem minimalen Verlust an Funktionalität oder Benutzererfahrung.
# 4) Niedrig (S4)
Alle kosmetischen Mängel, einschließlich Rechtschreibfehler oder Ausrichtungsprobleme oder Schriftgehäuse, können unter Niedriger Schweregrad klassifiziert werden.
Ein kleiner Fehler mit niedrigem Schweregrad tritt auf, wenn die Funktionalität fast nicht beeinträchtigt wird, es sich jedoch immer noch um einen gültigen Fehler handelt, der behoben werden sollte. Beispiele hierfür können Rechtschreibfehler in an Benutzer gedruckten Fehlermeldungen oder Fehler sein, um das Erscheinungsbild einer Funktion zu verbessern.
Zum Beispiel, Bei dem E-Mail-Dienstanbieter wie Yahoo oder Google Mail hätten Sie die 'Lizenzseite' bemerkt. Wenn die Seite Rechtschreibfehler oder Fehlausrichtungen aufweist, wird dieser Fehler als 'Niedrig' eingestuft.
Das oben diskutierte Szenario zu Punkt 6 könnte als Low Defect klassifiziert werden, da die Schaltfläche Add in einem falschen Gehäuse angezeigt wird. Diese Art von Defekt hat keine Auswirkungen auf das Systemverhalten oder die Datenpräsentation oder den Datenverlust oder den Datenfluss oder sogar die Benutzererfahrung, ist jedoch sehr kosmetisch.
Zusammenfassend zeigt die folgende Abbildung die breite Fehlerklassifizierung basierend auf Schweregrad und Priorität:
Beispiele
Wie bereits erwähnt, wird es, da verschiedene Organisationen unterschiedliche Tools für die Fehlerverfolgung und die damit verbundenen Prozesse verwenden, zu einem gemeinsamen Verfolgungssystem zwischen verschiedenen Managementebenen und dem technischen Personal.
Da der Schweregrad des Fehlers eher im Bereich der Funktionalität liegt, legt der Testingenieur den Schweregrad des Fehlers fest. Manchmal sind die Entwickler an der Beeinflussung der Fehlerschwere beteiligt, aber meistens hängt dies vom Tester ab, der bewertet, wie stark eine bestimmte Funktion die Gesamtfunktion beeinflussen kann.
Wenn es andererseits darum geht, die Fehlerpriorität einzustellen, Obwohl der Fehlerursacher anfangs die Priorität festlegt, wird diese vom Produktmanager tatsächlich definiert, da er einen Überblick über das Produkt hat und wie schnell ein bestimmter Fehler behoben werden muss . Ein Tester ist keine ideale Person, um die Fehlerpriorität festzulegen.
So schockierend dies auch erscheinen mag, es gibt zwei verschiedene Beispiele dafür, warum:
Beispiel 1) Bedenken Sie, dass es eine Situation gibt, in der der Benutzer einen Fehler bei der Benennung des Produkts selbst oder ein Problem mit der UI-Dokumentation findet. Ein Tester öffnet normalerweise einen geringfügigen / kosmetischen Defekt und ist möglicherweise sehr einfach zu beheben. Wenn es jedoch um das Erscheinungsbild und die Benutzererfahrung des Produkts geht, kann dies schwerwiegende Auswirkungen haben.
Beispiel 2) Es kann bestimmte Bedingungen geben, unter denen ein bestimmter Defekt auftritt, die äußerst selten oder gar nicht in der Kundenumgebung auftreten können. Auch wenn dies in Bezug auf die Funktionalität für einen Tester aufgrund seiner Seltenheit und der hohen Kosten für die Behebung wie ein Fehler mit hoher Priorität erscheint, wird dies als Fehler mit niedriger Priorität eingestuft.
Daher wird die Fehlerpriorität in der Regel vom Produktmanager in einer Besprechung zur Fehlerbehebung festgelegt.
Verschiedene Level
Unter Priorität und Schweregrad befinden sich einige Klassifizierungen, anhand derer bestimmt werden kann, wie der Fehler behandelt werden muss. Viele verschiedene Organisationen haben verschiedene Tools zur Fehlerprotokollierung , daher können die Ebenen variieren.
Werfen wir einen Blick auf die verschiedenen Ebenen für Priorität und Schweregrad.
- Hohe Priorität, hoher Schweregrad
- Hohe Priorität, niedriger Schweregrad
- Hoher Schweregrad, niedrige Priorität
- Niedriger Schweregrad, niedrige Priorität
Die folgende Abbildung zeigt die Klassifizierung der Kategorien in einem einzelnen Snippet.
# 1) Hoher Schweregrad und hohe Priorität
Jeder kritische / schwerwiegende Geschäftsfallfehler wird automatisch in diese Kategorie befördert.
Fehler, aufgrund derer die Prüfung nicht um jeden Preis fortgesetzt werden kann oder zu einem schwerwiegenden Systemfehler führt, fallen in diese Kategorie. Zum Beispiel, Durch Klicken auf eine bestimmte Schaltfläche wird die Funktion selbst nicht geladen. Wenn Sie eine bestimmte Funktion ausführen, wird der Server konsistent heruntergefahren und es kommt zu Datenverlust. Die roten Linien in der obigen Abbildung zeigen diese Art von Fehlern an.
Zum Beispiel,
Das System stürzt ab, nachdem Sie die Zahlung getätigt haben oder wenn Sie die Artikel nicht in den Warenkorb legen können. Dieser Fehler wird als Fehler mit hohem Schweregrad und hoher Priorität markiert.
Ein anderes Beispiel Dies wäre eine Funktion für Geldautomatenautomaten, bei der der Automat nach Eingabe des richtigen Benutzernamens und des richtigen Passworts kein Geld ausgibt, sondern das überwiesene Geld von Ihrem Konto abzieht.
# 2) Hohe Priorität und niedriger Schweregrad
Alle geringfügigen Schweregradfehler, die sich direkt auf die Benutzererfahrung auswirken könnten, werden automatisch in diese Kategorie befördert.
Fehler, die behoben werden müssen, aber keine Auswirkungen auf die Anwendung haben, fallen unter diese Kategorie.
Zum Beispiel, Es wird erwartet, dass die Funktion dem Benutzer einen bestimmten Fehler in Bezug auf seinen Rückkehrcode anzeigt. In diesem Fall gibt der Code funktionell einen Fehler aus, aber die Nachricht muss für den generierten Rückkehrcode relevanter sein. Die blauen Linien in der Abbildung zeigen diese Art von Fehlern an.
Zum Beispiel,
Das Logo des Unternehmens auf der Titelseite ist falsch, es wird angenommen Hohe Priorität und niedriger Schweregrad Defekt .
Beispiel 1) Wenn auf der Online-Shopping-Website das FrontPage-Logo falsch geschrieben ist, wird es beispielsweise anstelle von Flipkart als Flipkart geschrieben.
Beispiel 2) Im Banklogo wird anstelle von ICICI ICCCI geschrieben.
In Bezug auf die Funktionalität hat dies keine Auswirkungen, sodass wir ihn als niedrigen Schweregrad markieren können. Dies wirkt sich jedoch auf die Benutzererfahrung aus. Diese Art von Defekt muss mit hoher Priorität behoben werden, obwohl sie auf der Anwendungsseite nur sehr geringe Auswirkungen haben.
# 3) Hoher Schweregrad und niedrige Priorität
Jeder Fehler, der funktional nicht den Anforderungen entspricht oder funktionale Auswirkungen auf das System hat, aber von den Stakeholdern in Bezug auf die Geschäftskritikalität in den Hintergrund gedrängt wird, wird automatisch in diese Kategorie befördert.
Mängel, die behoben werden müssen, aber nicht sofort. Dies kann insbesondere bei Ad-hoc-Tests auftreten. Dies bedeutet, dass die Funktionalität stark beeinträchtigt wird, jedoch nur beobachtet wird, wenn bestimmte ungewöhnliche Eingabeparameter verwendet werden.
Wo finden Sie den Netzwerksicherheitsschlüssel?
Zum Beispiel, Eine bestimmte Funktionalität kann nur in einer späteren Version der Firmware verwendet werden. Um dies zu überprüfen, führt der Tester tatsächlich ein Downgrade seines Systems durch, führt den Test durch und stellt ein schwerwiegendes Funktionsproblem fest, das gültig ist. In einem solchen Fall werden die Fehler in diese Kategorie eingeteilt, die durch rosa Linien gekennzeichnet ist, da von Endbenutzern normalerweise eine höhere Version der Firmware erwartet wird.
Zum Beispiel,
Wenn auf einer Social-Networking-Site eine Beta-Version einer neuen Funktion veröffentlicht wird und nicht viele aktive Benutzer diese Funktion derzeit verwenden. Jeder bei dieser Funktion festgestellte Fehler kann als niedrige Priorität eingestuft werden, da die Funktion aufgrund der Geschäftsklassifizierung als nicht wichtig in den Hintergrund tritt.
Obwohl diese Funktion einen Funktionsfehler aufweist, da sie die Endkunden nicht direkt betrifft, kann ein Geschäftsinteressent den Fehler mit niedriger Priorität klassifizieren, obwohl er schwerwiegende funktionale Auswirkungen auf die Anwendung hat.
Dies ist ein Fehler mit hohem Schweregrad, kann jedoch mit niedriger Priorität priorisiert werden, da er mit der nächsten Version als Änderungsanforderung behoben werden kann. Geschäftsinteressenten priorisieren diese Funktion auch als selten verwendete Funktion und wirken sich nicht auf andere Funktionen aus, die sich direkt auf die Benutzererfahrung auswirken. Diese Art von Defekt kann unter klassifiziert werden Hoher Schweregrad, aber niedrige Priorität Kategorie.
# 4) Niedriger Schweregrad und niedrige Priorität
Rechtschreibfehler / Schreibweise / Fehlausrichtung im Absatz 3rdoder 4thSeite der Anwendung und nicht in der Haupt- oder Titelseite / Titel.
Diese Fehler werden wie in der Abbildung gezeigt in den grünen Linien klassifiziert und treten auf, wenn keine Auswirkungen auf die Funktionalität auftreten, die Standards jedoch in geringem Maße nicht erfüllt werden. Im Allgemeinen werden hier kosmetische Fehler oder beispielsweise Abmessungen einer Zelle in einer Tabelle auf der Benutzeroberfläche klassifiziert.
Zum Beispiel,
Wenn die Datenschutzrichtlinie der Website einen Rechtschreibfehler enthält, wird dieser Fehler als festgelegt Niedriger Schweregrad und niedrige Priorität.
Richtlinien
Nachfolgend sind einige Richtlinien aufgeführt, die jeder Tester befolgen muss:
- Verstehen Sie zunächst die Konzepte von Priorität und Schweregrad gut. Vermeiden Sie es, sich gegenseitig zu verwechseln und austauschbar zu verwenden. Befolgen Sie in diesem Zusammenhang die von Ihrer Organisation / Ihrem Team veröffentlichten Schweregradrichtlinien, damit sich alle auf derselben Seite befinden.
- Wählen Sie den Schweregrad immer basierend auf dem Problemtyp aus, da dies die Priorität beeinflusst. Einige Beispiele sind:
- Bei einem kritischen Problem, bei dem das gesamte System ausfällt und nichts unternommen werden kann, sollte dieser Schweregrad nicht zur Behebung von Programmfehlern verwendet werden.
- Bei einem schwerwiegenden Problem, z. B. in Fällen, in denen die Funktion nicht wie erwartet funktioniert, kann dieser Schweregrad verwendet werden, um neue Funktionen zu beheben oder die aktuelle Arbeitsweise zu verbessern.
Denken Sie daran, dass die Auswahl des richtigen Schweregrads wiederum den Fehler verursacht. Dies ist die gebührende Priorität.
- Als Tester - verstehen, wie eine bestimmte Funktionalität, sondern weiter ausgeführt wird - verstehen, wie sich ein bestimmtes Szenario oder ein bestimmter Testfall auf den Endbenutzer auswirken würde. Dies beinhaltet viel Zusammenarbeit und Interaktion mit dem Entwicklungsteam, Business Analysten, Architekten, Testleiter und Entwicklungsleiter. In Ihren Diskussionen müssen Sie auch berücksichtigen, wie viel Zeit zur Behebung des Fehlers erforderlich ist, basierend auf seiner Komplexität und Zeit, um diesen Fehler zu überprüfen.
- Endlich Es ist immer der Produktbesitzer, der das Vetorecht der Freigabe besitzt. Der Fehler sollte behoben werden. Da die Fehler-Triage-Sitzungen jedoch verschiedene Mitglieder enthalten, um ihre Sichtweise auf den Fehler im Einzelfall darzulegen, hilft dies zu einem solchen Zeitpunkt, wenn Entwickler und Tester synchron sind, sicherlich bei der Beeinflussung der Entscheidung.
Fazit
Beim Öffnen von Fehlern liegt es in der Verantwortung des Testers, den Fehlern den richtigen Schweregrad zuzuweisen. Ein falscher Schweregrad und damit eine Prioritätszuordnung können sehr drastische Auswirkungen auf den gesamten STLC-Prozess und das Produkt insgesamt haben. In mehreren Vorstellungsgesprächen werden verschiedene Fragen zu Priorität und Schweregrad gestellt, um sicherzustellen, dass Sie als Tester diese Konzepte einwandfrei im Kopf haben.
Außerdem hatten wir Live-Beispiele gesehen, wie der Fehler unter verschiedenen Schweregrad- / Prioritätsbereichen klassifiziert werden kann. Ich wünschte, Sie hätten inzwischen genügend Klarheit über die Fehlerklassifizierung sowohl bei Schweregrad- als auch bei Prioritätsbereichen.
Ich hoffe, dieser Artikel ist eine vollständige Anleitung zum Verständnis der Fehlerpriorität und des Schweregrads. Teilen Sie uns Ihre Gedanken / Fragen in den Kommentaren unten mit.
Literatur-Empfehlungen
- Was ist eine fehlerbasierte Testtechnik?
- Was ist der Fehler- / Fehlerlebenszyklus beim Testen von Software? Tutorial zum Fehlerlebenszyklus
- Fehlermanagementprozess: So verwalten Sie einen Fehler effektiv
- So reproduzieren Sie einen nicht reproduzierbaren Fehler und machen Ihren Testaufwand lohnenswert
- 7 Prinzipien des Softwaretests: Fehlerclustering und Pareto-Prinzip
- Methoden und Techniken zur Fehlervermeidung
- Genauer Unterschied zwischen Verifikation und Validierung anhand von Beispielen
- 3 Strategien zum Umgang mit einem Blockerdefekt