Menü

Live-Projekt-Bug-Tracking, Testmetriken und Testabmeldung - Kostenloser QS-Schulungstag 6

live project bug tracking

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Dies ist der abschließende Teil unseres „ Software-Test-Training für ein Live-Projekt ' Serie.

Es geht um Mängel und auch um einige verbleibende Themen, die den Abschluss der Testausführungsphase des STLC markieren.

In dem Vorheriger Artikel Während der Testausführung ist eine Situation aufgetreten, in der das erwartete Ergebnis des Testfalls nicht erreicht wurde. Außerdem haben wir während der Erkundungstests ein unerwartetes Verhalten festgestellt.

Live Project Bug Tracking, Testmetriken und Testabmeldung

Was passiert, wenn wir auf diese Abweichungen stoßen?

Wir müssen sie natürlich aufzeichnen und verfolgen, um sicherzustellen, dass diese Abweichungen behandelt und schließlich auf dem AUT behoben werden.

# 1) Diese Abweichungen werden als Defekte / Fehler / Probleme / Vorfälle / Fehler / Fehler bezeichnet.

#zwei) Alle folgenden Fälle können als Fehler protokolliert werden

  • Fehlende Anforderungen
  • Falsch funktionierende Anforderungen
  • Zusätzliche Anforderungen
  • Inkonsistenzen des Referenzdokuments
  • Umweltbezogene Fragen
  • Verbesserungsvorschläge

#3) Die Fehleraufzeichnung erfolgt meist in Excel-Tabellen oder mithilfe einer Fehlermanagement-Software / eines Fehlermanagement-Tools. Informationen zum Umgang mit Fehlern über Tools finden Sie unter den folgenden Links:

Was du lernen wirst:

So protokollieren Sie die Fehler effektiv

Wir werden nun versuchen, die im vorherigen Artikel aufgetretenen Fehler in einem Excel-Blatt zu protokollieren. Wie immer ist die Auswahl eines Standardformats oder einer Standardvorlage wichtig.

Was ist ein guter E-Mail-Service?

In der Regel sind die folgenden Spalten Teil des Fehlerberichts:

  • Fehler-ID: Zur eindeutigen Identifizierung.
  • Falsche Beschreibung: Dies ist wie ein Titel, um das Problem kurz zu beschreiben.
  • Modul / Abschnitt des AUT: Dies ist optional, um mehr Klarheit zu schaffen und den Bereich des AUT anzugeben, in dem das Problem aufgetreten ist.
  • Schritte zum Reproduzieren: Die genaue Reihenfolge der Operationen, die am AUT ausgeführt werden müssen, um den Fehler wiederherzustellen, ist hier aufzulisten. Wenn Eingabedaten für das Problem spezifisch sind, müssen diese Informationen ebenfalls eingegeben werden.
  • Schwere: Angabe der Intensität des Problems und eventueller Auswirkungen auf die Funktionsweise des AUT. Die Richtlinien zum Zuweisen und Zuweisen der Werte in diesem Feld finden Sie im Testplandokument. Bitte beziehen Sie sich auf die Testplandokument aus Artikel 3 .
  • Status: Wird im Artikel weiter besprochen.
  • Bildschirmfoto: Ein Schnappschuss der Anwendung, um den Fehler anzuzeigen, wenn er aufgetreten ist.

Dies sind einige der 'Must-Have' -Felder. Diese Vorlage kann erweitert (z. B. um den Namen des Testers, der das Problem gemeldet hat) oder vertraglich vereinbart (z. Zum Beispiel, der Modulname entfernt) nach Bedarf.

Befolgen Sie die obigen Richtlinien und verwenden Sie die obige Vorlage. Ein Beispiel für ein Fehlerprotokoll / einen Fehlerbericht könnte folgendermaßen aussehen:

Beispiel für einen Fehlerbericht für das OrangeHRM Live-Projekt:

OrangeHRM-Fehlerbericht

=> Klicken Sie hier, um den Fehlerbericht des Live-Projekts herunterzuladen

Unten finden Sie ein Beispiel für einen Fehlerbericht, der mit dem qTest Test Management-Tool erstellt wurde: (Klicken Sie auf das Bild, um es zu vergrößern)

Beispielfehlerbericht

Fehler sind nicht gut, wenn wir sie protokollieren und für uns behalten. Wir müssen sie in der richtigen Reihenfolge zuweisen, damit die betroffenen Teams auf sie einwirken. Der Prozess - wer zugewiesen werden soll oder welcher Reihenfolge zu folgen ist - finden Sie auch im Testplandokument. Es ist meistens ähnlich zu (Klicken Sie auf das Bild, um es zu vergrößern)

Fehlerzyklus:

Fehlerlebenszyklus 1

Aus dem obigen Prozess kann festgestellt werden, dass Fehler unterschiedliche Personen und unterschiedliche Entscheidungen durchlaufen, während sie identifiziert und behoben werden. Um zu verfolgen und Transparenz darüber zu schaffen, in welchem ​​Zustand sich ein bestimmter Fehler befindet, wird im Fehlerbericht ein Feld „Status“ verwendet. Der gesamte Prozess wird als 'Bug-Lebenszyklus' bezeichnet. Weitere Informationen zu allen Status und deren Bedeutung finden Sie hier Bug Life Cycle Tutorial .

Ein paar Hinweise beim Bug Tracking

  • Wenn wir neu in einem kreativen Team / Projekt / AUT sind, ist es immer am besten Besprechen Sie das Problem, auf das wir gestoßen sind mit einem Kollegen, um sicherzustellen, dass unser Verständnis, was wirklich zu einem Defekt führt, richtig ist oder nicht.
  • Zu Geben Sie alle Informationen an das ist notwendig, um das Problem zu reproduzieren. Ein Fehler, der bei einem Testteam mit dem Status 'Nicht genügend Informationen' auftritt, wirkt sich nicht sehr positiv auf uns aus. Schauen Sie sich diesen Beitrag an - So beheben Sie alle Fehler ohne die Bezeichnung 'Ungültiger Fehler' .
  • Überprüfen Sie, ob ein ähnliches Problem aufgetreten ist, bevor Sie ein neues erstellen. Probleme beim Duplizieren sind auch schlechte Nachrichten für das QA-Team.
  • Wenn es ein Problem gibt, das zufällig auftritt und wir nicht genau wissen, in welchen Schritten / Situationen wir das Problem neu erstellen können, sprechen Sie das Problem trotzdem an. Auf die Gefahr, dass das Problem eingestellt wird 'IrReproducible / nicht genug Informationen' - Wir müssen immer noch sicherstellen, dass wir alle möglichen Störungen so gut wie möglich behandelt haben.
  • Die allgemeine Praxis ist, dass das QS-Team während eines Tages die einzelnen Fehler in einem Excel-Blatt erstellt und am Ende des Tages konsolidiert.

Der vollständige Fehlerlebenszyklus

Für unser Live-Projekt, wenn wir den Fehlerlebenszyklus für Fehler 1 verfolgen würden,

VPN google chrom
  • Wenn ich (der Tester) es erstelle, ist sein Status ''Neu”. Wenn ich es dem QA-Teamleiter zuordne, ist der Status immer noch 'Neu', aber der Eigentümer ist jetzt der QA-Leiter.
  • Der QS-Leiter überprüft das Problem. Wenn festgestellt wird, dass es sich um ein gültiges Problem handelt, wird das Problem dem Entwicklungsleiter zugewiesen. In dieser Phase ist der Status ''Zugewiesen'' und der Besitzer ist Dev Blei.
  • Der Entwickler leitet dieses Problem dann einem Entwickler zu, der an der Behebung dieses Problems arbeitet. Der Status wird nun sein ''In Arbeit'' (oder etwas Ähnliches), der Eigentümer ist der Entwickler.
  • Bei Fehler 1 kann der Entwickler den Fehler nicht reproduzieren. Daher weist er ihn dem QA-Team zurück und setzt den Status auf ''Nicht reproduzierbar”.
  • Wenn der Entwickler in der Lage wäre, daran zu arbeiten und ein Problem zu beheben, würde der Status alternativ auf gesetzt ''behoben'' und das Problem würde wieder dem QS-Team zugewiesen.
  • Das QA-Team wird es dann abholen, das Problem erneut testen und, falls es behoben ist, den Status auf setzen ''Geschlossen'' . Wenn das Problem weiterhin besteht, wird der Status auf gesetzt ''Wieder öffnen'' und der Prozess geht weiter.
  • Abhängig von den anderen Situationen kann der Status als festgelegt werden ''Aufgeschoben'' , 'Nicht genug Information', ''Duplikat'' , ''wie vorgesehen arbeiten'' usw. vom Entwickler.
  • Diese Methode zum Aufzeichnen, Melden, Zuweisen und Verwalten von Fehlern ist eine der Hauptaktivitäten der QA-Teammitglieder während der Testausführungsphase. Dies erfolgt täglich, bis ein bestimmter Testzyklus abgeschlossen ist.
  • Sobald Zyklus 1 abgeschlossen ist, wird das Entwicklerteam ein oder zwei Tage brauchen, um alle Korrekturen zu konsolidieren und den Code in der nächsten Version neu zu erstellen, die für den nächsten Zyklus verwendet wird.
  • Der gleiche Vorgang wird auch für Zyklus 2 fortgesetzt. Am Ende des Zyklus besteht die Möglichkeit, dass noch einige Probleme in der Anwendung „offen“ oder nicht behoben sind.
  • Fahren wir zu diesem Zeitpunkt noch mit Zyklus 3 fort? Wenn ja, wann hören wir auf zu testen?

Beendigungskriterien für das Testen des OrangeHRM Live-Projekts

Hier setzen wir die sogenannten „Exit Criteria“ ein. Dies ist im Testplandokument vordefiniert. Es ist einfach in Form der Checkliste, die bestimmt, ob wir den Test nach Zyklus 2 abschließen oder einen weiteren Zyklus durchführen. Es sieht so aus, als ob im Folgenden unter Berücksichtigung einiger hypothetischer Antworten auf die folgenden Fragen zum OrangeHRM-Projekt Folgendes ausgefüllt wird:

Test-Exit-Kriterien

Wenn wir uns die obige Checkliste genau ansehen, werden dort Metriken und Abmeldungen erwähnt, die wir zuvor nicht besprochen haben. Lassen Sie uns jetzt darüber sprechen.

Testmetriken

Wir haben festgestellt, dass während der Testausführungsphase Berichte an alle anderen Mitglieder des Projektteams gesendet werden, um eine klare Vorstellung davon zu erhalten Was passiert in der QA-Ausführungsphase? . Diese Informationen sind für alle wichtig, um eine Validierung der Gesamtqualität des Endprodukts zu erhalten.

Stellen Sie sich vor, ich berichte, dass 10 Testfälle bestanden oder 100 Testfälle ausgeführt wurden. Diese Zahlen sind lediglich Rohdaten und geben keinen sehr guten Überblick über den Stand der Dinge.

Metriken spielen eine wichtige Rolle, um diese Lücke zu schließen. Metriken sind in einfachen Worten: intelligente Zahlen, die das Testteam sammelt und verwaltet . Zum Beispiel, Wenn ich sagte, dass 90% der Testfälle bestanden wurden, ist dies sinnvoller als zu sagen, dass 150 Testfälle bestanden wurden. Nicht wahr?

Während der Testausführungsphase werden verschiedene Arten von Metriken erfasst. Welche Metriken genau für welchen Zeitraum erfasst und gepflegt werden sollen - diese Informationen finden Sie im Testplandokument.

Die folgenden Testmetriken werden für die meisten Projekte am häufigsten erfasst:

  • Prozentsatz der Testfälle bestehen
  • Defekte Dichte
  • Prozentsatz kritischer Fehler
  • Mängel, Schweregrad

Probier das aus Statusbericht an diesen Artikel angehängt um zu sehen, wie diese Metriken verwendet werden.

Testabmelde- / Abschlussbericht

Da wir alle Beteiligten über den Beginn der Tests informieren müssen, ist es auch die Pflicht des QS-Teams, alle über den Abschluss der Tests zu informieren und die Ergebnisse zu teilen. Daher wird in der Regel eine E-Mail vom QA-Team (normalerweise vom Teamleiter / QA-Manager) gesendet, die angibt, dass das QA-Team das Produkt mit den Testergebnissen und der Liste der offenen / bekannten Probleme abgemeldet hat.

Beispieltest Abmelden E-Mail:

Zu: Kunde, PM, Entwicklerteam, DB-Team, BA, QA-Team, Umweltteam (und alle anderen, die einbezogen werden müssen)
Email: Hallo Team,

Das QA-Team meldet die OrangeHRM Version 3.0-Software nach erfolgreichem Abschluss der zwei Zyklen des Funktionstests der Website ab.

Die Testfälle und ihre Ausführungsergebnisse sind der E-Mail beigefügt. (Oder geben Sie den Ort an, an dem sie vorhanden sind. Wenn Sie eine Testverwaltungssoftware verwenden, geben Sie Details dazu an.)

Die Liste der bekannten Probleme wird ebenfalls an die E-Mail angehängt. (Auch hier können weitere sinnvolle Verweise hinzugefügt werden.)

Vielen Dank,
QA-Teamleiter.

Anhänge: Endgültiger Ausführungsbericht, Endgültiger Ausgabe- / Fehlerbericht, Liste bekannter Probleme

Sobald die Test-Abmelde-E-Mail vom QA-Team verschickt wurde, sind wir offiziell mit dem STLC-Prozess fertig. Dies markiert nicht unbedingt den Abschluss der Testphase des SDLC. Wir müssen noch die UAT-Tests abschließen, damit dies geschieht. Finden Weitere Details zu UAT-Tests finden Sie hier .

Nachdem die UAT abgeschlossen ist, wechselt der SDLC in die Bereitstellungsphase, in der er live geschaltet wird, und steht seinen Kunden / Endbenutzern zum Konsumieren zur Verfügung.

Das ist es!

Dies war unser Bestreben, unseren Lesern die bestmögliche Erfahrung mit QA-Projekten zu bieten. Bitte teilen Sie uns Ihre Kommentare und Fragen zu dieser kostenlosen Online-QA-Schulungsreihe zum Testen von Software mit.

Literatur-Empfehlungen

^