Software Tester Arbeit - Top Testplanung und Testfehler

Inhaltsverzeichnis:

Anonim

Einführung in Software Tester Work

Woran denken Sie als Erstes, wenn Sie an einen Softwaretest-Job denken? Eine nicht codierende Arbeit? Oder ein Beruf, der sehr einfach ist, da Sie die Möglichkeit haben, Fehler in der Arbeit anderer zu finden (Fehler in anderen zu finden, ist die einfachste Aufgabe für uns alle)? Oder verstehen Sie es als den Beruf, bei dem es darum geht, die Korrektheit des Produkts zu überprüfen? All diese Gedanken sind richtig und die täglichen Aktivitäten für eine Software-Tester-Arbeit. Das Testen von Software ist jedoch nicht nur auf diese Aktivitäten beschränkt.

Die Anwendung verstehen

Die Anwendung kann aus einer beliebigen Domäne stammen - Gesundheitswesen, Versicherungen, Finanzen usw. Das Erlernen der Anwendungsdomäne ist für jede Softwarearbeit sehr wichtig, um beim Testen der Anwendung die Türen zum Denken aus verschiedenen Blickwinkeln und aus verschiedenen Benutzerperspektiven zu öffnen. Die offensichtlichen und nicht so offensichtlichen Anwendungspfade aufzudecken und zu validieren, ist dabei immer die primäre Erwartung. Vertiefte Kenntnisse der Anwendung helfen dabei, das Produkt effektiv zu validieren, und gleichzeitig kann der Tester zu einer Bereicherung für ein Projekt werden, bei dem er / sie als eine der wichtigsten Wissensquellen in Bezug auf das Produktverhalten betrachtet wird.

Während das Erlernen von Domäne und Funktionalität ein fortlaufender Prozess ist, ist der andere wichtige Faktor, Kenntnisse über den Testprozess zu haben.

Testprozess

Der Testprozess kann von Unternehmen zu Unternehmen oder sogar von Projekt zu Projekt unterschiedlich sein. Heute gibt es verschiedene Softwareentwicklungsmodelle wie das V-Modell, das Prototyping-Modell oder eine ganz andere Methodik wie den Agile-Ansatz der Softwareentwicklung. Mit der Änderung des Entwicklungsmodells ändert sich auch der zu verfolgende Testansatz. Das Arbeiten in einem V-Modell wird gut definierte Prozesse haben, während das Arbeiten in einer agilen Methodik unter sich ständig ändernden Bedingungen getestet werden soll.

Der Job ist noch nicht reibungslos mit akzeptablen Domänenkenntnissen und dem Verständnis des Testprozesses. Die nächste Herausforderung, die mit dem Leben verbunden ist, ist das Erlernen verschiedener Tools.

Werkzeuge

Zu den Tools gehören Testmanagement-Tools, Fehlerprotokollierungs-Tools, Datenbankmanagement-Tools usw.

Mit verschiedenen Fehlerprotokollierungssoftware-Qualitäten und -Tools, von denen einige Open Source und andere lizenziert sind, ist es immer von Vorteil, Kenntnisse über mehr als ein Tool zu haben. Es hilft dabei, Projekte oder Teams, die verschiedenen Tools folgen, einfach umzustellen. Mit ausreichenden Kenntnissen über den Bereich, den Prozess und die Tools kann das Leben von Software Tester mehr, was seine Arbeitstage herausfordernd und aufregend macht. Die Zusammenarbeit in Teams ist einer der wichtigsten Faktoren für den Erfolg eines Projekts. Für eine effektive Zusammenarbeit spielt die Kommunikation eine sehr wichtige Rolle.

Empfohlene Kurse

  • Schließen Sie den J2EE-Gesamtkurs ab
  • Online R-Programmierungstraining
  • Zum Programmierkurs
  • Online-Zertifizierungstraining im Haskell-Programm

Kommunikation

Die Kommunikation spielt eine sehr wichtige Rolle für die Qualität der Software, da die Mitglieder des Testteams bereits in der Anfangsphase der Softwareentwicklung (als Best Practice) in die Erörterung der Anforderungen einbezogen werden und die Geschäftsanalysten bei Fragen oder Lücken befragt werden. Ein Tester mit effektiven Kommunikationsfähigkeiten kann die Risiken effektiv kommunizieren, kann effektiv mit dem Entwicklungsteam kommunizieren und kann die Testergebnisse und Testberichte effektiv kommunizieren.

Planung von Software Tester Works

Wie der Name schon sagt, ist die Testplanung die Phase, in der die Vorbereitung für den Test erfolgt. Die Vorbereitung für einen Taster umfasst verschiedene Arten von Aktivitäten, die ein Taster ausführt, um die Anwendung effektiv durchzuführen. Dies hilft bei der Validierung der Anwendung und der effektiven Aufdeckung von Fehlern in der Anwendung. Um mit der Planung zu beginnen, durchläuft ein Test die Anforderungen, um die Erwartungen zu verstehen.

1. Voraussetzungen

Anforderungen konnten an das Testteam in Form von Drahtgittern, Storyboards und Excel-Tabellen gestellt werden. Ziel all dieser Dokumente ist es, die Kundenanforderungen auf effiziente und leicht verständliche Weise darzustellen. Wireframe-Dokument ist nichts anderes als ein Dokument, das in Form einer PowerPoint-Präsentation vorliegen kann und die Anforderungen des Kunden darstellt. Auf den gleichen Linien zeigen Storyboards normalerweise das gewünschte Aussehen / Design der Bildschirme. Heutzutage sind verschiedene Tools auf dem Markt verfügbar, mit denen die erforderlichen Dokumente erstellt werden können. Die Erstellung der erforderlichen Dokumente liegt in der Hauptverantwortung eines Business Analyst. Von einem Geschmack wird erwartet, dass er die Anforderungen genau versteht. Damit sowohl der Test als auch die Entwickler die Anforderungen richtig verstehen, halten Business Analysts das Forum für alle offen, um Fragen zu den jeweiligen Anforderungen zu beantworten. Die Plattform zur Diskussion und Kommunikation der offenen Fragen und Abfragen ist von Projekt zu Projekt unterschiedlich. Es kann sich um eine E-Mail-Kette, eine Telefonkonferenz oder sogar ein gemeinsam genutztes Laufwerks-Repository handeln, um alle offenen Fragen und deren Antworten zu verfolgen, die vom Geschäftsanalysten bereitgestellt werden.

Klare Kommunikation und Aufzeichnung der Kommunikation spielen für einen Beweis eine sehr wichtige Rolle. Eine kleine Annahme in der Anforderung kann manchmal zu einem großen Defekt des Produkts führen. In jeder Phase wird einem Software-Tester empfohlen, die Kommunikation sauber zu halten. Software Tester Arbeitskommunikation kann mit Geschäftsanalysten oder sogar innerhalb eines Teams erfolgen. Klare Kommunikation hilft, Annahmen während der Planung und Ausführung fernzuhalten. Gleichzeitig wird eine Aufzeichnung der Kommunikation empfohlen (vorzugsweise E-Mail-Kommunikation). Eine schriftliche Mitteilung zu Anfragen in Anforderungen hilft in späteren Phasen der Testausführung, wenn die Funktionalität möglicherweise nicht so entwickelt wurde, wie in der aufgezeichneten Mitteilung bestätigt.

2. Szenario

Sobald die Anforderungen verstanden sind, beginnt der Tester mit der Dokumentation der Szenarien im Dokument Testszenario. Wie der Name schon sagt, handelt es sich bei einem Szenario um einen Funktionsablauf, dem der Benutzer folgt, um eine Aufgabe auszuführen.

Beispiele für Szenarien -

  1. Der Benutzer sollte sich erfolgreich anmelden können.
  2. Der Benutzer sollte in der Lage sein, Tickets im System zu buchen.
  3. Der Benutzer sollte in der Lage sein, Tickets im System zu stornieren.
  4. Der Benutzer sollte in der Lage sein, die Profildetails anzuzeigen / zu aktualisieren.

Dies sind die logischen Aufgaben, die ein Benutzer im System ausführt. Wenn diese logischen Aufgaben in Gruppen zusammengefasst sind, können Sie alle möglichen Szenarien notieren, die ein Benutzer ausführen soll. Diese Szenarien werden normalerweise in den Excel-Tabellen dokumentiert oder manchmal mithilfe einiger Tools. Ein Prüfer ist bestrebt, all diese Szenarien aus den Anforderungsdokumenten zu extrahieren. Ein Dokument, das solche Szenarien enthält, heißt Szenariodokument testen (oder irgendwo als High-Level-Szenariodokument). Dieses Dokument dient als Eingabedokument für die Erstellung von Testfällen.

3. Fall

In diesem Fall handelt es sich um die detailliertere Version des Software Tester-Arbeitsszenarios, in der das Szenario in detailliertere Schritte unterteilt ist, die der Benutzer während der Verwendung der Anwendung tatsächlich ausführt. Ein einfaches Beispiel basierend auf den oben genannten Szenarien ist:

Szenario - Der Benutzer sollte sich erfolgreich anmelden können.

Testfälle:

  1. Stellen Sie sicher, dass der Benutzer den richtigen Benutzernamen eingeben kann.
  2. Stellen Sie sicher, dass der Benutzer das Kennwort eingeben kann.
  3. Überprüfen Sie, ob der Benutzer sich erfolgreich anmelden kann, wenn Sie auf die Schaltfläche Anmelden klicken, nachdem Sie den richtigen Benutzernamen und das richtige Kennwort eingegeben haben.

Eine solche Liste dieser Fälle kann eine Validierungsprüfung für jedes Feld, die Prüfung negativer Szenarien usw. beinhalten.

Im Folgenden finden Sie einige zusätzliche Beispiele für diese Fälle:

  1. Überprüfen Sie, ob der Benutzername nicht eingegeben wurde. Das System gibt einen entsprechenden Fehler aus.
  2. Überprüfen Sie das Kennwort, wenn Sie es nicht eingeben. Das System gibt einen entsprechenden Fehler aus.
  3. Vergewissern Sie sich, dass Benutzername und Passwort nicht eingegeben wurden. Das System gibt einen entsprechenden Fehler aus.
  4. Vergewissern Sie sich, dass das System bei der Eingabe eines falschen Kennworts eine entsprechende Fehlermeldung ausgibt.
  5. Vergewissern Sie sich, dass das System bei der Eingabe eines falschen Benutzernamens eine entsprechende Fehlermeldung ausgibt.

4. Anforderungsrückverfolgbarkeitsmatrix (RTM)

Anforderungsrückverfolgbarkeitsmatrix, wie der Name schon sagt, hilft zu prüfen und die Abdeckung der von Business bereitgestellten Anforderungen in die Testdokumente wie Szenarien und Testfälle zu integrieren.

Als bewährte Methode ist dies ein separates Dokument, das die Zuordnung der Anforderungsnummer zu den Szenarien / Fällen zeigt, in denen diese Anforderung enthalten ist.

Dieses Dokument kann möglicherweise nicht von allen Arten von Projekten verwendet werden, aber wenn es verwendet wird, hilft es auf starke Weise, die übergeordneten Szenarien zu verfolgen, die den Anforderungen entsprechen. Es zeigt die Abdeckung an und kann verwendet werden, um das Vorhandensein von mindestens einem dieser Fälle gegen jede einzelne Anforderung zu überprüfen. Das Erstellen und Verwalten des RTM-Dokuments wird als die beste Vorgehensweise angesehen, jedoch verwenden nicht alle Arten von Projekten (wie Agile) Software, um das Arbeitsdokument zu prüfen. Wenn sich die Anforderungen sehr häufig ändern, kann die Verwaltung dieses Dokuments abgehört werden. Um diesen Mehraufwand zu vermeiden und gleichzeitig die Nachverfolgung von Anforderungen zu ermöglichen, wird bei einigen Projekten der Rückverfolgbarkeitsteil in den Software Tester-Workcase oder in das Szenariodokument selbst integriert.

Der wichtige Aspekt ist, eine Möglichkeit zu haben, Szenarien / Fälle zu Anforderungen zurückzuverfolgen und umgekehrt. Gut dokumentierte Anforderungen erleichtern es Prover, diese Dokumente zu erstellen und zu verwalten. Mehrdeutige Anforderungen und sich ständig ändernde Anforderungen machen das Leben des Prüfers schwieriger und können zu inkonsistenten zu liefernden Dokumenten führen, wodurch eine gewisse Validierung und damit ein Defekt des Endprodukts ausbleibt.

Die bisherige Reise für einen Tester war das Planen und Vorbereiten von Tests. Da die Kriegsvorbereitung Teil des Krieges ist, gilt dies auch hier. Je präziser diese Dokumente erstellt werden, desto einfacher ist es für den Prüfer, die Funktionalität zu validieren und fast alle Mängel aufzudecken. Die nächste Phase der Reise des Testers ist die Ausführung.

Die Ausführung des Software-Testers funktioniert

Dies ist die Phase, in der alle oben genannten Dokumente in Gebrauch genommen werden. Anforderungen wurden zum Erstellen eines Szenarios verwendet, Szenario wurde zum Erstellen von Fällen verwendet. Dieses Falldokument ist das eigenständige Dokument hier, um mit der Validierung der Anwendung zu beginnen. Prover beginnt mit der Validierung der Anwendung, indem Schritte aus diesem Falldokument ausgeführt werden. Mehrere dieser Fälle könnten verwendet werden, um ein einzelnes Szenario zu validieren, oder sogar ein einzelner Testfall kann einem einzelnen Testszenario entsprechen. Es hängt alles von der Komplexität der Szenarien oder manchmal vom im Testteam verfolgten Standard ab. Daher kann ein einzelnes Testfalldokument 20-50 Testfälle oder 100-120 Testfälle enthalten. Diese Zahlen dienen nur zu Erklärungszwecken und können von Projekt zu Projekt stark variieren. Das Ergebnis dieser Phase sind Testfehler. Die Anzahl der in dieser Phase aufgetretenen gültigen Mängel vermittelt einen guten Eindruck von der Stabilität der Anwendung, der Testqualität, der Verarbeitungsqualität und vieler solcher Faktoren, die sich direkt auf das Produkt auswirken. Diese Phase ist die wichtigste Phase, da der Tester alle Testfälle abdeckt (um fast alle erforderlichen Benutzerpfade zu validieren) und gleichzeitig so viele gültige Fehler wie möglich aufwirft. Alle Vorbereitungen, Kommunikationsfähigkeiten und Fragen, die für das Unternehmen gestellt werden, müssen in dieser Testphase berücksichtigt werden.

Defects Of Software Tester funktioniert

Während der Ausführung dieses Falls wird jedes Verhalten, das nicht dem erwarteten Ergebnis entspricht, als Fehler gewertet. Jeder Testfall hat eine Beschreibung, ein erwartetes Ergebnis und eine Spalte für das tatsächliche Ergebnis. Während dieser Planung enthält das Software Tester-Arbeitsdokument eine Beschreibung und die erwarteten Ergebnisse sowie eine leere Spalte für die tatsächlichen Ergebnisse. Während der Ausführung der Testfälle soll der Tester die eigentliche Ergebnisspalte ausfüllen. Wenn das tatsächliche Ergebnis nicht mit dem erwarteten Ergebnis übereinstimmt, wird gleichzeitig der Fehler protokolliert. Das Protokollieren eines Fehlers bedeutet nicht, den Entwickler über das Problem zu informieren. Es ist wieder ein formaler Prozess, der normalerweise mit Hilfe eines Werkzeugs durchgeführt wird. Derzeit gibt es verschiedene Tools auf dem Markt, einige Open Source und einige lizenziert. Jedes Fehlerprotokollierungs-Tool verfügt über die folgenden Felder:

  1. Projekt- / Release-Name
  2. Fehlerübersicht
  3. Fehlerdetailbeschreibung
  4. Schweregrad des Mangels
  5. Fehlerpriorität
  6. Phase, in der der Defekt festgestellt wurde
  7. Zugewiesen an
  8. Anhänge

Wie wir sehen können, besteht der Zweck all dieser Felder darin, einen formellen Prozess in Bezug auf Details des gefundenen Problems zu haben. Dies hilft Entwicklern, den Fehler in ihrer Umgebung zu reproduzieren und zu beheben. Nachfolgend finden Sie eine kurze Beschreibung aller dieser Felder -

  1. Projekt- / Versionsname - Name der Version, in der der Fehler gefunden wurde. In der Regel hat ein Projekt mehrere Versionen und dasselbe Projekt kann mehrere Unterprojekte haben. In diesem Feld wird ein Problem für eine bestimmte Version angezeigt.
  2. Fehlerzusammenfassung - Eine kurze einzeilige Beschreibung des gefundenen Fehlers.
  3. Fehlerdetailbeschreibung - Dies ist die Detailbeschreibung des Fehlers. Sie sollte Details wie die Umgebung, in der der Fehler gefunden wurde, und die verwendeten Testdaten, die erwarteten tatsächlichen Ergebnisse und alle zusätzlichen Informationen enthalten, die den Beteiligten wertvollere Informationen zum Verständnis des Fehlers liefern Defekt.
  4. Schwere des Mangels - Zeigt an, wie schwer der Mangel ist. Normalerweise hat es ähnliche Werte wie Kritisch, Hoch, Mittel, Niedrig oder numerische Werte wie 4, 3, 2, 1.
  5. Fehlerpriorität - Zeigt an, wie dringend es ist, den Fehler zu beheben.
  6. Phase, in der der Fehler festgestellt wurde - Da es viele Phasen gibt, in denen ein Fehler protokolliert werden kann, gibt es Unit-Test-Phase, SIT (Systemintegrationstest), UAT (Benutzerakzeptanztest) oder sogar Produktionsphase.
  7. Zugewiesen an - Name des Entwicklers oder Entwicklungsleiters.
  8. Anhänge - Mit dieser Option kann der Tester den Schnappschuss des Bildschirms anhängen, auf dem das Problem aufgetreten ist.

Die Testausführung und Fehlerprotokollierung ist die Phase, in der ein Tester mit vielen Herausforderungen konfrontiert sein kann. Einige von ihnen kommunizieren effektiv mit den Entwicklern. Könnten wir argumentieren, dass das Protokollieren eines Fehlers mit allen erforderlichen Informationen nicht ausreicht, damit die Entwickler den Fehler verstehen?

In einigen Fällen ist eine zusätzliche Erläuterung / Diskussion mit den Entwicklern erforderlich. Es gibt Fälle, in denen ein Tester auf ein unerwartetes Verhalten stößt, bei dem er möglicherweise nicht sicher ist, ob es sich um einen Defekt handelt. Diese Umstände treten in der Regel bei Beweisen auf, die neu im Team sind, über begrenzte Domänenkenntnisse verfügen oder die Anforderungen nicht genau kennen. Nun, der Tester ist hier nicht schuld, wenn es enge Fristen und sich ständig ändernde Anforderungen gibt und in den meisten Fällen der Prüfer während der Planung und Ausführung von Testfällen etwas über die Domäne erfährt. Wie wir sehen können, ist der Weg eines Testers nicht so einfach, wie er wahrgenommen wird. Es erfordert immer Lernbereitschaft, gute Kommunikationsfähigkeiten, gute Fähigkeiten zur Zusammenarbeit und die Bereitschaft, sich an Bedingungen anzupassen, in denen sich Bereiche, Werkzeuge und Prozesse ändern. Während wir über die Reise der manuellen Tester sprachen, gilt der Gesamtprozess auch für Automatisierungstester. Die Automatisierung hingegen hat erhebliche Änderungen im Prozess zur Folge, da der Umfang der Tests und der Planung sowie der Ausführung erheblich variiert.

In Anbetracht der Reise des Prüfers, wie oben diskutiert, können wir immer noch sagen, dass die Arbeit von Software-Tester-Qualitäten einfacher ist als die eines Entwicklers?

Es kann gesagt werden, dass es sinnvoller ist, zu diskutieren, wie die Zusammenarbeit von zwei zu einem großen Erfolg des gesamten Produkts führen kann, als die Rollen der Entwickler des Testers zu vergleichen. Wir vergessen manchmal, dass es die Aufgabe des Testers ist, Probleme in der Anwendung zu finden und nicht auf Fehler der Entwickler hinzuweisen. Wenn wir die Idee unseres Jobs vergessen, führt dies manchmal zu unnötigen Diskussionen. Es wurde jedoch festgestellt, dass es ebenso gute Entwicklungsteams gibt, bei denen jeder versteht, dass das Endziel darin besteht, dass die Anwendung wie erwartet funktioniert. Hoffen wir, dass alle die positive Seite des Testauftrags als eine Rolle betrachten, die bei der Reinigung des Produkts hilft, und nicht als eine Rolle, die nur Fehler findet!

Empfohlene Artikel

Dies war ein Leitfaden, um die offensichtlichen und nicht so offensichtlichen Anwendungspfade aufzudecken und zu validieren. Dies ist immer die primäre Erwartung an eine Software-Tester-Arbeit. Dies sind die folgenden externen Links, die sich auf Software-Tester beziehen.

  1. Fehlerlebenszyklus beim Testen von Software
  2. Die 6 erstaunlichsten Fragen im Zusammenhang mit Softwaretests
  3. Karriere im Softwaretest