Fehlerlebenszyklus - Wie Sie vielleicht bereits wissen, ist die Testausführung die Phase, in der der Tester die Testskripte tatsächlich ausführt. Der Ablauf der Ausführung von Testskripten ist von Unternehmen zu Unternehmen unterschiedlich und kann auch in verschiedenen Projekten innerhalb desselben Unternehmens unterschiedlich sein.
Mittlerweile stehen Tools für die Testausführung zur Verfügung, z. B. Quality Center, Microsoft Visual Studio usw. Der tatsächliche Ausführungsprozess zum Durchführen jedes Schritts zum Vergleichen des tatsächlichen und des erwarteten Ergebnisses bleibt für den Funktionstester unabhängig von den verwendeten Werkzeugen derselbe.
- Was ist, wenn das tatsächliche Verhalten nicht dem erwarteten Verhalten entspricht?
Wenn ein Tester feststellt, dass das tatsächliche Testergebnis nicht dem erwarteten Ergebnis entspricht, wird ein Fehler protokolliert.
- Wie melde ich einen Defekt?
Heutzutage sind viele Tools verfügbar. Einige der Tools für die Fehlerprotokollierung sind ClearQuest von IBM, das HP Quality Center, Open-Source-Tools wie der Fehlerlebenszyklus in JIRA und so weiter.
Es gibt einige der Pflichtfelder, die in den verschiedenen Tools zur Fehlerprotokollierung gemeinsam sind. Diese Felder sind:
- Fehlerlebenszyklus Beschreibung
- Zusammenfassung des Fehlerlebenszyklus
- Fehler protokolliert von
- Defekt zugeordnet zu
- Schweregrad des Mangels
- Fehlerpriorität
- Zusätzliche Schnappschüsse
- Versionsnummer / Name
Fehler Lebenszyklus
Fehler Der Lebenszyklus beginnt mit der Protokollierung eines neuen Fehlers. Wenn ein Defekt protokolliert wird, wechselt er in den Status "Neu".
Tester - Neuer Defekt
Wem soll ein neuer Defekt zugeordnet werden?
Ein Tester kann einem Entwickler oder einem Entwicklungsleiter einen Defekt zuweisen. Diese Entscheidung über die Fehlerzuordnung ist von Projekt zu Projekt unterschiedlich. An einigen Arbeitsplätzen gibt es einen Fehlerlebenszyklusprozess, um ihn direkt einem jeweiligen Entwickler zuzuweisen, und an einigen Stellen wird der Fehler zuerst einem Entwickler-Lead zugewiesen und der Entwickler-Lead weist ihn wiederum einem Entwickler zu.
Fehlerzuweisung (neu) - Defect Life Cycle Developer
Fehlerzuweisung (neu) - Entwickler von Dev Leadà
Fehleranalyse
Der Entwickler wird den Fehler analysieren, um zu überprüfen, ob er reproduzierbar ist. Hier ist der wichtigste Beitrag des Testers, alle notwendigen Details in den Defekt einzubeziehen. Fehlerzusammenfassung, Fehlerbeschreibung sind die Felder, die den Beteiligten helfen, den Fehler auf einen Schlag zu verstehen. Die Fehlerzusammenfassung sollte immer nur die allgemeinen Informationen zum Fehler enthalten. Gleichzeitig sollte es über ausreichende Informationen verfügen, um die Fehlerübersicht in einer Zeile zu beschreiben.
Die Fehlerbeschreibung ist der Ort, an dem der Tester alle erforderlichen Informationen wie Umgebung, Szenario, verwendete Testdaten, erwartetes Ergebnis, tatsächliches Ergebnis, Verweis auf Dateien / Daten und Verweis auf Momentaufnahme enthalten soll.
Hier ist eine kurze Übersicht über verschiedene Elemente der detaillierten Fehlerbeschreibung -
Umgebung
Testumgebung, in der der Defekt festgestellt wurde. Oft haben Projekte mehrere Testumgebungen, in denen das Testteam Tests durchführt. Zum Beispiel - AT (Assembly Testing Environment), PT (Product Testing Environment), UAT (User Acceptance Testing Environment) und so weiter. Verschiedene Umgebungen bieten Flexibilität für das Entwicklungs- und Testteam, damit der Code in einer der verfügbaren Umgebungen bereitgestellt werden kann, um die Tests rechtzeitig zu starten.
Es gibt Zeiten, in denen sich der Produkttest (auch als Systemtest bezeichnet) und der UAT-Test überschneiden. Daher ist es ein Muss, mehrere Umgebungen gleichzeitig zu testen.
In einigen Fällen benötigt das Entwicklungsteam eine zusätzliche Umgebung, um die vom Testteam gemeldeten Probleme zu beheben. Das Entwicklerteam verfügt auch über eine dedizierte Umgebung für Unit-Testing-Aufgaben.
Daher muss bei mehreren Umgebungen im Defekt eine bestimmte Umgebung angegeben werden, in der das Problem aufgetreten ist.
Szenario
Das Szenario besteht aus einer Reihe von Schritten, die vom Tester ausgeführt wurden und zu einem Defekt geführt haben. Hier muss ein Tester alle Schritte nennen, die der Entwickler ausführen kann, um den Defekt zu reproduzieren. Oft gibt es Zeiten, in denen der Fehler vom Tester gemeldet wird, der Entwickler jedoch nicht in der Lage ist, den Fehler zu reproduzieren, und der Fehler daher zurückgewiesen wird. Dies kann aufgrund falscher oder fehlender Schritte in der Beschreibung geschehen. Klare Schritte helfen jedem, den Defekt zu verstehen und zu reproduzieren, ohne sich an einen Tester zu wenden, um Eingaben zu erhalten. Ein gut dokumentiertes Szenario ist leicht zu lesen, leicht zu verstehen und es müssen genaue Schritte befolgt werden, um den Fehler zu reproduzieren.
Testdaten
Ein Tester soll die während des Testflusses verwendeten Daten angeben, die zu einem Problem geführt haben. Diese Informationen geben dem Entwickler die Möglichkeit, die ähnlichen Daten zu verwenden, um den Fehler zu reproduzieren und die Grundursache dafür zu finden.
Es gibt einige Szenarien, in denen ein Tester einen Fehler anhand bestimmter Daten findet, aber dasselbe Problem lässt sich mit ähnlichen Daten nicht reproduzieren. Dies kann auf eine Beschädigung der Daten zurückzuführen sein. Wenn Sie also Daten eingeben, können Sie die Fehlerursache herausfinden. Ein Entwickler greift möglicherweise nicht auf Code-Ebene zurück, wenn Datenbeschädigungen vorliegen. Diese Art von Defekt kann in einen Datendefekt umgewandelt werden.
Erwartetes und tatsächliches Ergebnis
Dies ist der Höhepunkt eines detaillierten Beschreibungsfeldes, in dem ein Tester nachweist, dass der aufgetretene Fehler tatsächlich ein Fehler ist. Die eindeutige Erwähnung des erwarteten Ergebnisses macht es für jeden Beteiligten klar, dass der Fehler ein Mangel ist. Stellen Sie sich vor, ein Defekt wird mit allen Details protokolliert, gibt jedoch nicht das erwartete Ergebnis des Szenarios an!
Normalerweise gibt ein Tester nur das erwartete Ergebnis in einer oder zwei Zeilen ein. Es ist jedoch sehr wichtig, die Quelle des erwarteten Ergebnisses anzugeben. Quelle hier Verweis auf das Dokument, in dem das erwartete Ergebnis erwähnt wird. Dies kann ein Anforderungsdokument oder eine Storyboard-Referenz sein.
Verweis auf Dateien / Daten
Manchmal besteht der Fehler in der Erzeugung einer Datei oder der Eingabe als Datei. In solchen Szenarien soll der Tester Informationen zu der Datei bereitstellen, die verwendet wurde und die das Problem in der Anwendung verursacht hat. Diese Dateien können mit dem Fehlermanagement-Tool angehängt werden oder es kann die Referenz für dieselbe bereitgestellt werden. Diese Referenzstandorte sollten für alle Beteiligten zugänglich sein.
Verweis auf Snapshot
Schnappschüsse spielen eine sehr wichtige Rolle, wenn Sie ihnen die genaue Fehlermeldung für den Seitenumbruch anzeigen möchten, die auf dem Bildschirm angezeigt wird, oder wenn Sie die Bildschirmnavigationsdetails anzeigen möchten. Der Schnappschuss gibt einen schnellen Überblick über den aufgetretenen Fehler, den Bildschirm, auf dem der Fehler festgestellt wurde, die auf dem Bildschirm verwendeten Daten usw. Jedes Fehlermanagement-Tool bietet die Möglichkeit, die Schnappschüsse anzufügen. Manchmal hängt der Tester auch die Excel-Tabellen oder Word-Dokumente an.
Dies waren die verschiedenen Komponenten der Fehlerprotokollierung und Best Practices für jeden von ihnen. Zurück zum Fehlerlebenszyklus: Sobald der Fehler einem Entwickler zugewiesen wurde, analysiert er ihn anhand der im Fehlerartikel angegebenen Daten. Wenn gemäß der Analyse das protokollierte Problem tatsächlich ein Fehler ist, wird der Entwickler den Fehler „öffnen“, um an seiner Korrektur zu arbeiten.
Empfohlene Kurse
- Webservices im Java-Schulungspaket
- Training zur Spieleentwicklung in C ++
- Absolviere das Ethical Hacking Training
- Vegas Pro 13-Schulungskurse
Neu offen
Ein Defekt im Status "Offen" zeigt an, dass es sich in der Entwicklungsplatte befindet und die Entwickler an der Fehlerbehebung arbeiten. Wenn die Analyse herausfindet, dass das protokollierte Problem kein Fehler ist, kann dies passieren, wenn Unklarheiten im erwarteten Verhalten des Systems bestehen. Wenn die Analyse ergibt, dass der Defekt ungültig ist, wird der Entwickler den Defekt zurückweisen. Die Terminologie lautet "Abgelehnt" oder "Zurück zum Testen".
Neu - Zurück zum Testen.
Wie soll der Tester prüfen, ob der Defekt tatsächlich ein ungültiger Defekt war?
Dies ist das Szenario, in dem ein genaues Anforderungsdokument jedem im Team hilft, zu dem Schluss zu kommen, dass der protokollierte Fehler ungültig oder gültig war. Der Verweis auf Anforderungsdokumente hilft Testern und Entwicklern, zu derselben Schlussfolgerung zu gelangen, und erleichtert den Diskussionsprozess erheblich.
Es gibt Szenarien, in denen die Richtigkeit von Konstruktions- und Anforderungsdokumenten in Frage gestellt wird, während diese Dokumente in Zeiten von Fehlerdiskussionen referenziert werden. In solchen Fällen wird das Zurückgreifen auf Business Analyst als die beste Option zur Klärung der Abfragen angesehen.
Als Best Practice sollten Anforderungs- und Konstruktionsdokumente immer auf dem neuesten Stand sein, um sie unmissverständlich zu referenzieren.
Im Status "Offen" arbeitet das Entwicklungsteam an der Behebung des Fehlers. Sobald der Fehler behoben ist, ändert sich der Status in "Bereit zur Bereitstellung".
Offen - Bereit für die Bereitstellung
Die Bereitstellung ist der Prozess, bei dem die Änderungen auf den Server hochgeladen werden, damit das Testteam an der festen Version des Codes arbeiten kann. Normalerweise hat jedes Projekt ein separates Bereitstellungsteam für diese Aufgabe.
Auf hoher Ebene besteht ein Softwareteam hauptsächlich aus diesen drei Gruppen -
- Entwicklung
- Fehlerlebenszyklus beim Testen
- Bereitstellung (oder manchmal als Build-Team bezeichnet)
Sobald der Build bereitgestellt wurde und der Fehler erneut zum Testen verfügbar ist, wird er einem geeigneten Tester für die Aufgabe des erneuten Testens zugewiesen.
Defekt zugeordnet - Prüfleitung.
Prüfleitung - Einzeltester.
Defekt zugewiesen - einzelner Tester.
An einigen Arbeitsplätzen wird der Defekt zuerst der Prüfleitung zugewiesen und diese wiederum dem einzelnen Prüfer. An einigen Stellen wird der Defekt jedoch direkt dem Prüfer zugewiesen, der ihn testen würde, oder demjenigen, der den Defekt verursacht hat.
Der Status ändert sich hier von Bereit für die Bereitstellung - Bereit für SIT-Tests.
Jetzt ist der Defekt in der Testplatte. Das Testteam überprüft den Fehler und es gibt zwei Möglichkeiten: Entweder funktioniert der Fix ordnungsgemäß, oder dasselbe Problem tritt erneut auf. Je nach Ergebnis kann der Defekt folgende Zustände annehmen:
Ready SIT Testing - Geschlossen
Ready SIT Testing - Wiedereröffnung
In beiden obigen Szenarien muss der Tester die Kommentare der durchgeführten Tests hinzufügen. Dies schließt die Erwähnung der getesteten Szenarien und der verwendeten Daten ein. Wenn der Defekt wieder geöffnet wird, sollte der Tester die genauen Schritte bereitstellen, die erneut zum Fehler geführt haben.
Der Status "Neu öffnen" entspricht dem Status "Neu".
Sobald der Defekt wieder geöffnet wird, folgt er wieder demselben Zyklus.
Defekte Lebenszyklus-Herausforderungen
- Entscheidung über die Schwere des Fehlers - dies ist eines der häufigsten Diskussionsthemen (häufig Kämpfe) zwischen Testern und Entwicklern.
- Der Fehler ist auf dem Entwicklersystem nicht reproduzierbar.
- In dem Szenario aufgetretener Fehler, der in den Anforderungen und Konstruktionsdokumenten nicht erwähnt wird.
- Es wurde ein Fehler festgestellt, der jedoch nicht geltend gemacht werden kann, da das Auftreten des Szenarios in der Produktionsumgebung nicht möglich ist.
Wie sollte ein Tester die Herausforderungen meistern?
- Der Schweregrad ist direkt proportional zu den Auswirkungen, die der Defekt auf die Anwendung hat. Wenn der Tester aufgrund des Defekts nicht fortfahren kann, wird er mit Sicherheit mit dem höchsten Schweregrad gekennzeichnet.
- Wenn eine Problemumgehung zum Fortsetzen des Tests vorhanden ist, sollte diese als mittelschwer markiert werden. Neben der Berücksichtigung der Auswirkungen weiterer Fehlerlebensdauertests kann der Schweregrad auch unter Berücksichtigung der Situation bestimmt werden, in der ein gesamtes Modul ausfällt. In diesem Fall kann zwar ein Test eines anderen Moduls durchgeführt werden, der Schweregrad des aktuellen Moduls ist jedoch hoch Daher sollte der Defekt mit der höchsten Schwere gekennzeichnet werden.
- Wenn ein Fehler auf dem System des Entwicklers nicht reproduzierbar ist, besteht die Möglichkeit, dass die Entwicklungs- und Testumgebung nicht synchron sind. Ein auf dem Testsystem reproduzierbarer Mangel gilt immer als gültiger Mangel.
- Es gibt Situationen, in denen ein Fehler in Anbetracht des gesamten Geschäftsszenarios protokolliert wird, das direkte Szenario jedoch in den Anforderungen oder im Konstruktionsdokument nicht erwähnt wird. Es wird immer als Best Practice angesehen, die tatsächlichen Geschäftsszenarien zu berücksichtigen, anstatt nur den Testschritten zu folgen. Die Kommunikation mit Geschäftsanalysten und anderen Produktbeteiligten spielt eine wichtige Rolle, um solche Fehler aufzuzeichnen.
- Es gibt Szenarien, in denen ein Tester während der Testphase eine Lücke in der Geschäftslogik feststellt. Das Auffinden solcher Lücken wird wiederum als großes Plus für einen Tester angesehen. Konstruktionslücken werden in der Regel über Erweiterungen geschlossen.
- Verbesserung - Wenn ein Verhalten während der Testphase des Software-Lebenszyklus geändert werden muss, wird eine Verbesserung erstellt, die in der aktuellen oder nächsten Version unter Berücksichtigung der Zeitpläne und der Bandbreite der Entwicklungs- und Testteams berücksichtigt werden kann.
- Es gibt einige Szenarien, die ein Tester möglicherweise während eines Ad-hoc-Tests testet. Dabei kann es sich tatsächlich um ungültige Szenarien handeln, wenn die Möglichkeit ihres Auftretens in der Produktion berücksichtigt wird.
Wer ist der beste Freund des Testers?
Wohin sollte ein Tester bei Unklarheiten gehen? Die Beantwortung hängt von der Art der Anfrage ab. Wenn eine Anfrage Anforderungen betrifft, ist es ratsam, diese zuerst im Team zu besprechen, um ein korrektes Verständnis des Systems zu gewährleisten. Dies kann durch Konsultation älterer Mitglieder geschehen. Nächster Ansprechpartner sollten Business Analysten sein.
Wenn die Abfrage den Testprozess betrifft, ist es ratsam, sich an den Testleiter oder Testmanager zu wenden.
Wenn bei der Abfrage die technischen Details der Anwendung erörtert werden sollen, ist möglicherweise das Mitglied des Entwicklungsteams der richtige Ansprechpartner.
Da das Testen ein Prozess ist, der ein umfassendes Verständnis des Systems erfordert, hilft die Kommunikation einem Tester, eine schnelle Antwort auf die Fragen zu erhalten. Es kommt nur darauf an, den richtigen Personen die richtigen Fragen zu stellen. Wenn Sie nicht rechtzeitig Fragen stellen, kann dies zu einem Defekt in der Produktionsumgebung führen.
Wie wichtig ist heute die Rolle eines Testers im Unternehmen?
Es gibt Projekte, bei denen das Testteam genauso wichtig ist wie das Entwicklungsteam, und in einigen Szenarien besteht eine größere Abhängigkeit vom Testteam als vom Entwicklungsteam. Das spätere Szenario ist selten, aber an einigen Arbeitsplätzen vorhanden. Dies ist im Laufe der Zeit passiert und möglicherweise für einen bestimmten Zeitraum, in dem das Entwicklerteam im Vergleich zum Testteam nicht viel Erfahrung hat. Es gibt Leute, die den Gesamtfluss und die Funktionalität besser verstehen als die meisten anderen Teammitglieder. Eine solche Person könnte Teil eines Test- / Entwicklungsteams sein. Dies ist einer der Faktoren, die über die Abhängigkeit von einem Team / einer Person für das jeweilige Projekt entscheiden.
Was ist der Karriereweg für einen Tester?
Es kann eine Weile dauern, bis eine Person den gesamten Testprozess, die Domäne und andere Aufgaben, an denen sie im täglichen Leben arbeiten soll, verstanden hat. Auf der Grundlage dieses Verständnisses ist es ratsam, die Entscheidung zu treffen, weitere Bereiche zu erkunden, die ein Tester möglicherweise einnehmen könnte. Dabei gibt es immer wieder Möglichkeiten, verschiedene Abläufe zu automatisieren. Das Erstellen kleiner Dienstprogramme kann dem Team auch auf große Weise helfen. Wenn ein Tester gut programmieren kann, wird dies als großes Plus angesehen. Dies eröffnet Möglichkeiten für Automatisierungsrollen. Leistungstests sind auch eine der Karrierestrecken für Tester. Business Analyst ist eine weitere Option. Gute Fachkenntnisse mit guten Kommunikationsfähigkeiten sind die erforderlichen Fähigkeiten, um ein Business Analyst zu sein. Das Testen eröffnet den Testern viele Möglichkeiten, an verschiedenen Domänen, Tools, Prozessen usw. zu arbeiten. Es ist nur eine Frage der Person, ob sie in einen der Kernbereiche des Tests vordringt. Es gibt viele spezifische Zertifizierungen für verschiedene Werkzeuge, um sich auf einen der Testbereiche zu spezialisieren. Die Zertifizierung des Standardanbieters ist ein Vorteil, um die Karriere voranzutreiben, aber das Zertifikat allein kann Ihnen auf lange Sicht nicht helfen, wenn es nicht mit der richtigen Berufserfahrung kombiniert wird.
Empfohlene Artikel
In den folgenden Artikeln erfahren Sie mehr über das Testen von Software. Klicken Sie einfach auf den Link.
- Die 6 erstaunlichsten Fragen im Zusammenhang mit Softwaretests
- Karriere im Softwaretest
- So verbessern Sie Ihr Karrierewachstum bei der Arbeit mit Software-Testern