STLC - Kurzanleitung

STLC steht für Software Testing Life Cycle. STLC ist eine Folge verschiedener Aktivitäten, die vom Testteam ausgeführt werden, um die Qualität der Software oder des Produkts sicherzustellen.

STLC ist ein wesentlicher Bestandteil des Software Development Life Cycle (SDLC). STLC befasst sich jedoch nur mit den Testphasen.
STLC startet, sobald Anforderungen definiert sind oder SRD (Software Requirement Document) von den Stakeholdern geteilt wird.
STLC bietet einen schrittweisen Prozess, um die Qualität der Software sicherzustellen.
In der frühen Phase der STLC kann der Tester während der Entwicklung der Software oder des Produkts den Umfang der Tests, die Ein- und Ausstiegskriterien sowie die Testfälle analysieren und definieren. Dies hilft, die Testzykluszeit zu verkürzen und die Qualität zu verbessern.
Sobald die Entwicklungsphase beendet ist, sind die Tester mit Testfällen fertig und beginnen mit der Ausführung. Dies hilft, Fehler in der Anfangsphase zu finden.

STLC-Phasen

STLC hat die folgenden verschiedenen Phasen, es ist jedoch nicht zwingend erforderlich, alle Phasen zu befolgen. Die Phasen hängen von der Art der Software oder des Produkts, der Zeit und den Ressourcen ab, die für die Tests und das zu befolgende SDLC-Modell bereitgestellt werden.

Es gibt 6 Hauptphasen der STLC -

Requirement Analysis - Wenn die SRD bereit ist und mit den Stakeholdern geteilt wird, beginnt das Testteam mit einer Analyse auf hoher Ebene in Bezug auf die AUT (Application under Test).
Test Planning - Das Testteam plant die Strategie und den Ansatz.
Test Case Designing - Entwickeln Sie die Testfälle basierend auf Umfang und Kriterien.
Test Environment Setup - Wenn die integrierte Umgebung bereit ist, das Produkt zu validieren.
Test Execution - Echtzeitvalidierung des Produkts und Auffinden von Fehlern.
Test Closure - Nach Abschluss des Tests werden Matrix, Berichte und Ergebnisse dokumentiert.

In diesem Kapitel werden wir die Vergleichsfaktoren zwischen STLC und SDLC verstehen. Betrachten wir die folgenden Punkte und vergleichen Sie dabei STLC und SDLC.

STLC ist Teil von SDLC. Es kann gesagt werden, dass STLC eine Teilmenge des SDLC-Satzes ist.
STLC beschränkt sich auf die Testphase, in der die Qualität der Software oder des Produkts sichergestellt ist. SDLC spielt eine wichtige Rolle bei der vollständigen Entwicklung einer Software oder eines Produkts.
STLC ist jedoch eine sehr wichtige Phase von SDLC und das Endprodukt oder die Software können nicht freigegeben werden, ohne den STLC-Prozess zu durchlaufen.
STLC ist auch Teil des Post-Release / Update-Zyklus, der Wartungsphase von SDLC, in der bekannte Fehler behoben werden oder der Software eine neue Funktionalität hinzugefügt wird.

In der folgenden Tabelle sind die Vergleichsfaktoren zwischen SDLC und STLC anhand ihrer Phasen aufgeführt.

Phase	SDLC	STLC
Anforderungserfassung	Business Analyst sammelt Anforderungen. Das Entwicklungsteam analysiert die Anforderungen. Nach einem hohen Level beginnt das Entwicklungsteam mit der Analyse aus der Architektur- und Designperspektive.	Das Testteam überprüft und analysiert das SRD-Dokument. Identifiziert die Testanforderungen - Schlüsselpunkte für Umfang, Verifizierung und Validierung. Überprüft die Anforderungen an die logische und funktionale Beziehung zwischen verschiedenen Modulen. Dies hilft bei der frühzeitigen Erkennung von Lücken.
Design	Die Architektur von SDLC hilft Ihnen dabei, ein Design der Software auf hoher und niedriger Ebene basierend auf den Anforderungen zu entwickeln. Business Analyst arbeitet am Spötter des UI-Designs. Sobald das Design fertig ist, wird es von den Stakeholdern unterzeichnet.	In STLC planen normalerweise entweder der Testarchitekt oder ein Testleiter die Teststrategie. Identifiziert die Testpunkte. Die Ressourcenzuweisung und die Zeitpläne werden hier festgelegt.
Entwicklung	Das Entwicklungsteam beginnt mit der Entwicklung der Software. Integration in verschiedene Systeme. Sobald die Integration abgeschlossen ist, wird eine testfertige Software oder ein Produkt bereitgestellt.	Das Testteam schreibt die Testszenarien, um die Qualität des Produkts zu überprüfen. Detaillierte Testfälle werden für alle Module zusammen mit dem erwarteten Verhalten geschrieben. Hier werden die Voraussetzungen sowie die Ein- und Ausstiegskriterien eines Testmoduls festgelegt.
Umgebung einrichten	Das Entwicklungsteam richtet eine Testumgebung mit dem entwickelten Produkt zur Validierung ein.	Das Testteam bestätigt die anhand der Voraussetzungen eingerichtete Umgebung. Führt Rauchtests durch, um sicherzustellen, dass die Umgebung für das zu testende Produkt stabil ist.
Testen	Die eigentliche Prüfung wird in dieser Phase durchgeführt. Es umfasst Unit-Tests, Integrationstests, Systemtests, Fehler-Retesting, Regressionstests usw. Das Entwicklungsteam behebt den gemeldeten Fehler und sendet ihn zur erneuten Prüfung an den Tester zurück. UAT-Tests werden hier ausgeführt, nachdem Sie sich vom SIT-Test abgemeldet haben.	Das Testen der Systemintegration beginnt basierend auf den Testfällen. Gegebenenfalls gemeldete Fehler werden erneut getestet und behoben. Hier werden Regressionstests durchgeführt und das Produkt wird abgemeldet, sobald es die Ausstiegskriterien erfüllt.
Bereitstellung / Produktfreigabe	Sobald die Abmeldung von verschiedenen Testteams eingegangen ist, wird die Anwendung in einer Produktumgebung für echte Endbenutzer bereitgestellt.	Die Rauch- und Hygienetests in der Produktionsumgebung werden hier abgeschlossen, sobald das Produkt bereitgestellt wird. Testberichte und Matrixvorbereitung werden vom Testteam durchgeführt, um das Produkt zu analysieren.
Instandhaltung	Es behandelt die Unterstützung, Verbesserung und Aktualisierung nach der Bereitstellung, falls vorhanden.	In dieser Phase werden Testfälle, Regressionsanzüge und Automatisierungsskripte basierend auf den Verbesserungen und Aktualisierungen verwaltet.

Das gemeinsame Ziel des Testens ist es, Fehler so früh wie möglich zu finden. Und sobald die Fehler behoben sind, stellen Sie sicher, dass sie wie erwartet funktionieren und keine anderen Funktionen beeinträchtigen.

Um diese Ziele zu erreichen, werden sieben Grundprinzipien für Softwaretests angegeben:

Was zeigt das Testen?

Tests können zeigen, dass Mängel vorliegen, es kann jedoch nicht nachgewiesen werden, dass das Produkt keine Mängel aufweist. Testphasen stellen sicher, dass die zu testende Anwendung auf der Grundlage der angegebenen Anforderungen funktioniert, und tragen dazu bei, die Wahrscheinlichkeit unentdeckter Fehler in der Anwendung zu verringern. Aber selbst wenn keine Mängel festgestellt werden, bedeutet dies nicht, dass es absolut korrekt ist. Wir können davon ausgehen, dass AUT mit unseren Ausstiegskriterien übereinstimmt und die Anforderungen gemäß SRD einhält.

Ist eine umfassende Prüfung möglich?

Eine 100% ige Abdeckung oder Prüfung aller Kombinationen von Eingaben und möglichen Kombinationen ist nur in trivialen Fällen möglich. Anstelle umfassender Tests werden Risikoanalysen und Prioritäten verwendet, um den Testumfang zu definieren. Hier können die meisten Echtzeitszenarien auch das wahrscheinlichste negative Szenario berücksichtigen. Dies hilft uns, den Fehler zu verfolgen.

Frühes Testen

Die Testaktivitäten sollten so bald wie möglich beginnen und sich auf definierte Ziele in der Teststrategie und die erwarteten Ergebnisse konzentrieren. Die frühe Testphase hilft dabei, Anforderungsfehler oder Abweichungen auf Designebene zu identifizieren. Wenn diese Arten von Fehlern in der Anfangsphase erfasst werden, können wir Zeit sparen und sind auch kostengünstig. Die Antwort darauf, warum das Testen frühzeitig beginnen sollte, ist sehr einfach: Sobald die SRD eingegangen ist, können die Tester die Anforderung aus der Testperspektive analysieren und eine Anforderungsdiskrepanz feststellen.

Fehlerclustering

Basierend auf früheren Produktfehleranalysen kann gesagt werden, dass die meisten Fehler anhand eines kleinen Satzes von Modulen identifiziert werden, die für die Anwendung kritisch sind. Diese Module können anhand der Komplexität, der unterschiedlichen Systeminteraktion oder der Abhängigkeit von verschiedenen anderen Modulen identifiziert werden. Wenn Tester diese wichtigen Module identifizieren können, können sie sich stärker auf diese Module konzentrieren, um alle möglichen Fehler zu identifizieren. In einer Studie wurde festgestellt, dass 8 von 10 Defekten anhand einer 20% igen Funktionalität von AUT identifiziert wurden.

Pestizid paradox

Was ist ein Pestizid-Paradoxon? Wenn Pestizide häufig in Kulturpflanzen eingesetzt werden, kommt es vor, dass die Insekten eine bestimmte Art von Resistenz entwickeln und die so gesprühten Pestizide allmählich auf die Insekten unwirksam zu sein scheinen.

Das gleiche Konzept gilt auch für Tests. Hier sind Insekten Käfer, während Pestizide Testfälle sind, die immer wieder eingesetzt werden. Wenn dieselben Testfallgruppen immer wieder ausgeführt werden, werden diese Testfälle nach einem bestimmten Zeitraum unwirksam und die Tester können keinen neuen Fehler identifizieren.

Um diese Bedingungen zu überwinden, sollten Testfälle von Zeit zu Zeit überarbeitet und überprüft werden, und neue und unterschiedliche Testfälle können hinzugefügt werden. Dies hilft bei der Identifizierung neuer Fehler.

Das Testen ist kontextabhängig

Dieses Prinzip besagt, dass zwei verschiedene Anwendungstypen erst mit demselben Ansatz getestet werden können, wenn beide Anwendungen von gleicher Natur sind. Wenn ein Tester beispielsweise denselben Ansatz für webbasierte Anwendungen und mobile Anwendungen verwendet, ist dies völlig falsch und es besteht ein hohes Risiko für eine schlechte Qualität der Produktfreigabe. Tester sollten unterschiedliche Ansätze, Methoden, Techniken und Abdeckungen für unterschiedliche Arten und Arten von Anwendungen verwenden.

Fehlen von Fehlern - Irrtum

Dieses Prinzip besagt, dass Fehler gefunden und behoben werden müssen, bis die Anwendung oder das System stabil ist, zeitaufwändig ist und auch Ressourcen verbraucht. Selbst nach Behebung von 99% der Defekte besteht ein hohes Risiko einer instabilen Anwendung. Das erste wesentliche Element ist die Überprüfung der Stabilität der Anwendung und der Voraussetzungen der Umgebung. Wenn diese beiden Bedingungen erfüllt sind, können wir erst dann mit den detaillierten Tests beginnen.

Die Anforderungsanalyse ist die erste Phase der STLC und beginnt, sobald die SRD / SRS mit dem Testteam geteilt wird. Betrachten wir die folgenden Punkte, um die Anforderungsanalyse in STLC zu verstehen.

Das Einstiegskriterium dieser Phase ist die Bereitstellung von SRS (Software Requirement Specification); Es wird auch empfohlen, dass die Anwendungsarchitektur praktisch ist.
In dieser Phase analysiert das QS-Team auf einer höheren Ebene, was zu testen ist und wie zu testen ist.
Das QS-Team setzt sich mit verschiedenen Stakeholdern wie Business Analyst, Systemarchitektur, Client, Testmanager / Lead in Verbindung, falls Fragen oder Erläuterungen erforderlich sind, um die Anforderungen zu verstehen.
Anforderungen können funktional oder nicht funktional sein, wie Leistung, Sicherheit, Benutzerfreundlichkeit usw. oder sowohl funktional als auch nicht funktional.
Das Ausstiegskriterium dieser Phase besteht darin, das RTM-Dokument, den Machbarkeitsbericht für die Automatisierung und gegebenenfalls eine Liste von Fragen auszufüllen, um die Anforderungen genauer zu beschreiben.

Aktivitäten zur Anforderungsanalyse

In dieser Phase werden vom QA-Team drei Hauptaktivitäten durchgeführt. Die Aktivitäten wurden unten beschrieben.

Geltungsbereich definieren

Das QS-Team identifiziert den Umfang der Tests auf hoher Ebene und unterteilt sich in verschiedene Funktionsmodule. Das Team identifiziert auch die Arten von Tests, die für die Durchführung erforderlich sind - Rauchtests, Hygienetests, Funktionstests, Regressionstests usw. Das QS-Team analysiert die Voraussetzungen und die Umgebungsdetails, in denen Tests durchgeführt werden sollen. Das Team sammelt Details zu den Testprioritäten und konzentriert sich auf die Reihenfolge der zu validierenden Module. Außerdem werden Anforderungsfehler identifiziert, wenn Modulen widersprochen werden und die Funktionalität nicht zusammen mit anderen Modulen übertragen wird.

Bereiten Sie RTM vor

Bei der Anforderungsverfolgung werden die Verknüpfungen zwischen den Anforderungen und den Arbeitsprodukten dokumentiert, die zur Implementierung und Überprüfung dieser Anforderungen entwickelt wurden. Das RTM erfasst alle Anforderungen der Anforderungsanalyse sowie deren Rückverfolgbarkeit in einem einzigen Dokument. All dies wird am Ende des Lebenszyklus geliefert.

Die Matrix wird zu Beginn eines Projekts erstellt, da sie die Grundlage für den Umfang und die Ergebnisse des Projekts bildet, die erstellt werden.

Die Matrix ist bidirektional, da sie die Anforderung vorwärts verfolgt, indem sie die Ausgabe der zu erbringenden Leistungen untersucht, und rückwärts, indem sie die Geschäftsanforderungen betrachtet, die für ein bestimmtes Merkmal des Produkts angegeben wurden.

Automatisierungsanalyse

In der Anforderungsphase analysiert das QS-Team den Umfang der Automatisierung für Regressionstests. Wenn der Umfang der Automatisierung hinzugefügt wird, entscheidet das Team, welches Tool verwendet werden kann, welche Funktionen als Automatisierung behandelt werden, wie viel Zeitrahmen und welche Ressourcenzuweisung für die Automatisierungsentwicklung erforderlich sind. Sobald diese Analyse abgeschlossen ist, stellt das QS-Team verschiedenen Stakeholdern den Machbarkeitsbericht für die Automatisierung zur Verfügung, um die Genehmigung zu erteilen.

In diesem Kapitel werden die Ein- und Ausstiegskriterien auf verschiedenen Ebenen in STLC angezeigt. Die folgenden Punkte müssen berücksichtigt werden, um die Kriterien zu verstehen.

Im Idealfall fährt das QS-Team erst mit der nächsten Phase fort, wenn die Ausstiegskriterien der aktuellen Phase erfüllt sind. Die Einstiegskriterien sollten den Abschluss der Ausstiegskriterien der vorherigen Phase umfassen.

In Echtzeit kann nicht auf die nächste Phase gewartet werden, bis die Beendigungskriterien erfüllt sind. Jetzt kann die nächste Phase eingeleitet werden, wenn die kritischen Ergebnisse der vorherigen Phase abgeschlossen wurden.

In jeder Phase der STLC sollten die Ein- und Ausstiegskriterien definiert werden.

Aufnahmekriterien

Eintrittskriterien für STLC-Phasen können als spezifische Bedingungen definiert werden; oder alle Dokumente, die zum Starten einer bestimmten Phase der STLC erforderlich sind, sollten vor dem Eintritt in eine der STLC-Phasen vorhanden sein.

Eingabekriterien sind eine Reihe von Bedingungen, die die Ausführung einer Aufgabe ermöglichen. Wenn keine dieser Bedingungen vorliegt, kann die Aufgabe nicht ausgeführt werden.

Beim Festlegen der Eingabekriterien ist es auch wichtig, den Zeitrahmen zu definieren, in dem das Element für die Eingabekriterien verfügbar ist, um den Prozess zu starten.

Um beispielsweise die Entwicklungsphase für Testfälle zu starten, sollten die folgenden Bedingungen erfüllt sein:

Das Anforderungsdokument sollte verfügbar sein.
Ein vollständiges Verständnis des Anwendungsflusses ist erforderlich.
Das Testplandokument sollte fertig sein.

Abbruchkriterium

Beendigungskriterien für STLC-Phasen können als Elemente / Dokumente / Aktionen / Aufgaben definiert werden, die abgeschlossen sein müssen, bevor die aktuelle Phase abgeschlossen und mit der nächsten Phase fortgefahren werden kann.

Ausstiegskriterien sind eine Reihe von Erwartungen; Dies sollte vor Abschluss der STLC-Phase erreicht werden.

Um beispielsweise die Entwicklungsphase für Testfälle abzuschließen, sollten die folgenden Erwartungen erfüllt werden:

Testfälle sollten geschrieben und überprüft werden.
Testdaten sollten identifiziert und bereit sein.
Das Testautomatisierungsskript sollte gegebenenfalls bereit sein.

Akzeptanzkriterien sind das erwartete Verhalten einer Funktionalität, eines Moduls und einer Anwendung, wie in den Anforderungsdokumenten aufgeführt. Es sind Überprüfungsstufen / Kontrollpunkte, um festzustellen, ob das Softwaresystem die Anforderungsspezifikationen erfüllt hat oder nicht. Der Hauptzweck dieses Tests besteht darin, die Übereinstimmung des Systems mit den Geschäftsanforderungen zu bewerten und zu überprüfen, ob es die erforderlichen Kriterien erfüllt.

Akzeptanzkriterien sind eine Reihe von Aussagen, in denen das erwartete Bestehen / Nichtbestehen-Ergebnis klar erwähnt wird. Die Akzeptanzkriterien legen sowohl funktionale als auch nicht funktionale Anforderungen fest. Diese Anforderungen stellen „Bedingungen der Zufriedenheit oder des erwarteten Verhaltens“ dar. Es gibt keine teilweise Akzeptanz; Entweder ist ein Kriterium erfüllt oder es ist nicht erfüllt.

Diese Kriterien definieren die Grenzen und Parameter einer Funktionalität / eines Moduls und bestimmen, ob die Funktionalität / das Modul abgeschlossen ist und wie erwartet funktioniert.

Kriterien für die Akzeptanz auf hoher Ebene werden auf der Ebene des Testplans erwähnt. Die Akzeptanzkriterien werden in eine Liste von zu überprüfenden Punkten oder erwarteten Ergebnissen auf der Ebene der Testfälle konvertiert.

Akzeptanzkriterien werden anhand der folgenden Attribute definiert:

Funktionale Korrektheit und Vollständigkeit
Datenintegrität
Datenkonvertierung
Usability
Performance
Timeliness
Vertraulichkeit und Verfügbarkeit
Installations- und Upgrade-Fähigkeit
Scalability
Documentation

Ein Testplan beschreibt die Strategie, die zum Testen einer Anwendung verwendet wird, die Ressourcen, die verwendet werden, die Testumgebung, in der die Tests durchgeführt werden, sowie die Einschränkungen der Tests und den Zeitplan der Testaktivitäten. In der Regel ist der Leiter des Qualitätssicherungsteams für die Erstellung eines Testplans verantwortlich.

Was beinhaltet ein Testplan?

Ein Testplan enthält Folgendes.

Einführung in das Testplandokument.
Annahmen beim Testen der Anwendung.
Liste der Testfälle, die beim Testen der Anwendung enthalten sind.
Liste der zu testenden Funktionen.
Der Ansatz, der beim Testen der Software verwendet werden soll.
Liste der zu testenden Ergebnisse.
Die zum Testen der Anwendung zugewiesenen Ressourcen.
Alle während des Testprozesses verbundenen Risiken.
Ein Zeitplan mit zu erreichenden Aufgaben und Meilensteinen.

Wichtige Punkte für die Testplanung

Die folgenden Punkte müssen für die Testplanung in STLC berücksichtigt werden.

Im Idealfall erstellt der Testanalyst (Lead) / der Manager die Teststrategie / das Testplandokument.
Die Analyse konzentriert sich mehr auf anwendungsbezogene Daten / Informationen.
Dies ist die erste Phase der eigentlichen Testaufgaben.
In dieser Phase werden die Fragen „WAS soll getestet werden?“ Und „WAS RESSOURCEN zum Testen erforderlich sind“ beantwortet.
Die grundlegenden Einstiegskriterien dieser Phase sind die Bereitstellung von Anforderungsdokumenten (aktualisierte Version unklarer / fehlender / geklärter Anforderungen) zusammen mit der Anforderungsrückverfolgbarkeitsmatrix.
Wenn der Umfang der Automatisierung liegt, sollte vor Beginn dieser Phase ein Machbarkeitsbericht für die Automatisierung erstellt werden.
Das Ausstiegskriterium dieser Phase ist der Abschluss des Teststrategie- / Testplandokuments und des Testaufwandsschätzungsdokuments.

Aspekte der Testplanungsphase

Das Hauptziel dieser Phase ist die Erstellung eines Testplans / Teststrategiedokuments. Es umfasst drei Hauptaspekte: Leistungsumfang, Aufwandsschätzung und Ressourcenplan.

Leistungsumfang

Folgende Aktivitäten müssen durchgeführt werden, um über den Umfang der zu erbringenden Leistungen zu schließen:

Identifizieren Sie das geeignete Engagement- und Liefermodell.
Definieren Sie Testziele, Testumfang, Testphasen und Aktivitäten.
Überprüfen Sie die Geschäftsanforderungen und Systemanforderungen, um die Durchführbarkeit des Tests zu ermitteln.
Definieren Sie den Testprozess, die Art des Tests und die Verfahren.
Definieren Sie Fehlermanagement- und Änderungsmanagementverfahren.
Identifizieren Sie Testwerkzeuge, -techniken und Best Practices.
Risikoanalyse definieren.
Definieren Sie eine Automatisierungslösung und identifizieren Sie gegebenenfalls geeignete Kandidaten für die Automatisierung.

Bemühungsschätzung

Schätzung ist der Prozess des Findens einer Schätzung oder Annäherung. Dies ist ein Wert, der für einen bestimmten Zweck verwendet werden kann, selbst wenn die Eingabedaten unvollständig, unsicher oder instabil sind.

Die Schätzung bestimmt, wie viel Geld, Aufwand, Ressourcen und Zeit für die Erstellung eines bestimmten Systems oder Produkts erforderlich sind. Die Schätzung basiert auf -

Vergangene Daten / Erfahrungen aus der Vergangenheit
Verfügbare Dokumente / Kenntnisse
Assumptions
Identifizierte Risiken

Die vier grundlegenden Schritte beim Testen der Schätzung sind:

Schätzung der Größe des AUT (Application Under Test).
Schätzung des Aufwands in Personenmonaten oder Personenstunden.
Schätzung des Zeitplans in Kalendermonaten.
Schätzung der Projektkosten in vereinbarter Währung.

Ressourcenplan

Ressourcenpläne sind das Schlüsselelement in Testphasen. Diese Pläne sind umgekehrt proportional zu der Zeit, die das Testteam benötigt, um eine bestimmte Aufgabe zu erledigen. Durch Erhöhen der Anzahl der Ressourcen wird die Anzahl der Fertigstellungstage für ein bestimmtes Limit verringert, danach wird es gesättigt, und das Erhöhen der Ressource hat keine großen Auswirkungen und führt möglicherweise nicht zu einer Verringerung der Fertigstellungstage.

Ein Ressourcenanforderer, normalerweise ein Projektmanager, erstellt Ressourcenpläne, um nach Ressourcen zu fragen, Aufwand und Kosten zu verfolgen. Ein Ressourcenmanager kann Ressourcenpläne ändern und genehmigen, bevor die Pläne verwendet werden.

Der normale Workflow für einen Ressourcenplan lautet:

Planung durch Projektmanager
Anfrage des Projektmanagers
Genehmigen / Ändern / Ablehnen durch Resource Manager
Abgeschlossen - Schließen der Anforderung nach Abmeldung durch Resource Manager

Sobald der Testplan fertig ist, initiiert das QA-Team die Entwicklung von Testfällen. Das Hauptziel dieser Phase ist die Vorbereitung von Testfällen für eine einzelne Einheit. Diese funktionalen und strukturellen Testfälle decken die im Testplan genannten Funktionen, Verifizierungs- und Validierungspunkte ab.

Die folgenden Punkte müssen für die Testfallentwicklung in STLC berücksichtigt werden.

In dieser Phase schreibt das QS-Team den Testfall schrittweise. Der Testfall wird dann von einem Business Analyst abgemeldet, nachdem Testfälle überprüft oder überarbeitet wurden, falls Änderungen erforderlich sind.
Sobald die Testfälle fertig sind, bereitet das QS-Team die Testdaten auf der Grundlage der Voraussetzungen vor.
Das Einstiegskriterium dieser Phase ist, dass die Aktivitäten in der Testplanung abgeschlossen und der Testplan fertig sein sollte.
Das Beendigungskriterium dieser Phase ist, dass die Testfälle abgemeldet werden, die Testdaten bereit sind und die Testskripte vorbereitet werden, wenn die Automatisierung im Umfang ist.
Testfälle sollten mit der Anforderungsrückverfolgbarkeitsmatrix abgebildet werden, um die Abdeckung von Anforderungen zu verfolgen, wenn etwas übersehen wird.

Aktivitäten in der Testfallentwicklungsphase

Im Folgenden sind die drei Aktivitäten aufgeführt, die in der Testfallentwicklungsphase ausgeführt werden:

Identifizierung von Testszenarien

Szenarien erleichtern das Testen und Bewerten eines komplexen Systems. Die folgenden Strategien helfen bei der Erstellung guter Szenarien:

Zählen Sie mögliche Benutzer, ihre Aktionen und Ziele auf.
Bewerten Sie Benutzer mit der Einstellung des Hackers und listen Sie mögliche Szenarien für Systemmissbrauch auf.
Listen Sie die Systemereignisse auf und wie behandelt das System solche Anforderungen?
Listen Sie die Vorteile auf und erstellen Sie End-to-End-Aufgaben, um sie zu überprüfen.
Lesen Sie mehr über ähnliche Systeme und deren Verhalten.
Untersuchung von Beschwerden über Konkurrenzprodukte und deren Vorgänger.

Schreiben von Testfällen

Ein Testfall ist ein Dokument, das Testdaten, Voraussetzungen, erwartete Ergebnisse und Nachbedingungen enthält, die für ein bestimmtes Testszenario entwickelt wurden, um die Einhaltung einer bestimmten Anforderung zu überprüfen.

Der Testfall dient als Ausgangspunkt für die Testausführung. Nach dem wird eine Reihe von Eingabewerten angewendet; Die Anwendung hat ein endgültiges Ergebnis und verlässt das System an einem Endpunkt, der auch als Ausführungsnachbedingung bezeichnet wird.

Vorbereitung der Testdaten

Testdaten werden verwendet, um die Tests auf Testware auszuführen. Die Testdaten müssen präzise und vollständig sein, um die Mängel aufzudecken. Um diese drei Ziele zu erreichen, folgt ein schrittweiser Ansatz wie unten angegeben:

Identifizieren Sie Testressourcen oder -anforderungen
Identifizieren Sie die zu testenden Bedingungen / Funktionen
Legen Sie die Prioritätstestbedingungen fest
Wählen Sie die Testbedingungen aus
Bestimmen Sie das erwartete Ergebnis der Verarbeitung von Testfällen
Erstellen Sie Testfälle
Testbedingungen dokumentieren
Test durchführen
Überprüfen und korrigieren Sie Testfälle anhand von Änderungen

Aktivitätsblockdiagramm

Das folgende Diagramm zeigt die verschiedenen Aktivitäten, die Teil der Testfallentwicklung sind.

Die Testumgebung besteht aus Elementen, die die Testausführung mit konfigurierter Software, Hardware und Netzwerk unterstützen. Die Konfiguration der Testumgebung muss die Produktionsumgebung imitieren, um Probleme im Zusammenhang mit der Umgebung / Konfiguration aufzudecken.

Die folgenden Punkte müssen in einem Testumgebungs-Setup berücksichtigt werden.

Es ist eine Kombination aus Hardware- und Softwareumgebung, in der die Tests ausgeführt werden.
Es umfasst Hardwarekonfiguration, Betriebssystemeinstellungen, Softwarekonfiguration, Testterminals und andere Unterstützung für die Durchführung des Tests.
Dies ist der wichtigste Aspekt des Testprozesses. Nichtverfügbarkeit oder fehlerhafte Einrichtung der Umgebung können alle Testbemühungen ruinieren.
In der Praxis kann das QS-Team nicht mit der eigentlichen Arbeit beginnen, ohne über die richtige Umgebung zum Testen zu verfügen.
Es ist eine unabhängige Aktivität und kann zusammen mit der Entwicklung von Testfällen gestartet werden.
Im Allgemeinen wird diese Aktivität von Entwicklern unter technischen Gesichtspunkten ausgeführt, während die Anforderungsbedingungen von Kunden / Geschäftsanalysten ausgeführt werden können.
Die Bereitschaft der Testumgebung kann durch Rauchtests überprüft und vom QS-Team durchgeführt werden.
Im Idealfall können wir sagen, dass die Einstiegskriterien dieser Phase die Bereitstellung eines Testplans, die Bereitschaft für Rauchtestfälle und die Vorbereitung von Testdaten sind.
Das Austrittskriterium dieser Phase ist, dass die Testumgebung bereit sein sollte und Rauchtests mit den erwarteten Ergebnissen erfolgreich durchgeführt werden sollten.

Aktivitäten zur Einrichtung der Testumgebung

Die folgenden Aktivitäten werden in dieser Phase ausgeführt.

Designtestumgebung

Folgende Faktoren spielen eine wichtige Rolle beim Entwurf einer Testumgebung.

Stellen Sie fest, ob die Testumgebung archiviert werden muss, um Backups zu erstellen.
Überprüfen Sie die Netzwerkkonfiguration.
Identifizieren Sie das erforderliche Server-Betriebssystem, Datenbanken und andere Komponenten.
Identifizieren Sie die Anzahl der vom Testteam benötigten Lizenzen.

Einrichtung der Umgebung

Analysieren Sie die Anforderungen für die Einrichtung der Umgebung und erstellen Sie eine Liste der Software- und Hardwareanforderungen für die Einrichtung. Holen Sie sich die offizielle Bestätigung für die Einrichtung der Testumgebung und konfigurieren Sie den Zugriff auf die Testumgebung.

Rauchprüfung

Sobald die Umgebung eingerichtet ist und das QS-Team Zugriff darauf hat, sollte eine kurze Rauchprüfung durchgeführt werden, um die Stabilität der Testumgebung zu überprüfen. Wenn die Ergebnisse wie erwartet sind, kann das QA-Team mit der nächsten Phase fortfahren, andernfalls auf die Unstimmigkeiten hinweisen und nach Korrekturen auf die Bereitstellung warten.

Bei der Testausführung wird der Code ausgeführt und die erwarteten und tatsächlichen Ergebnisse verglichen. Folgende Faktoren müssen für einen Testausführungsprozess berücksichtigt werden:

Wählen Sie basierend auf einem Risiko eine Teilmenge der Testsuite aus, die für diesen Zyklus ausgeführt werden soll.
Weisen Sie die Testfälle in jeder Testsuite den Testern zur Ausführung zu.
Führen Sie Tests durch, melden Sie Fehler und erfassen Sie den Teststatus kontinuierlich.
Beheben Sie auftretende Blockierungsprobleme.
Melden Sie den Status, passen Sie die Zuordnungen an und überdenken Sie Pläne und Prioritäten täglich.
Ergebnisse und Status des Testzyklus melden.

Die folgenden Punkte müssen bei der Testausführung berücksichtigt werden.

In dieser Phase führt das QS-Team die tatsächliche Validierung der AUT anhand vorbereiteter Testfälle durch und vergleicht das schrittweise Ergebnis mit dem erwarteten Ergebnis.
Das Einstiegskriterium für diese Phase ist der Abschluss des Testplans und der Testfallentwicklungsphase. Die Testdaten sollten ebenfalls bereit sein.
Die Validierung des Testumgebungs-Setups wird immer durch Rauchtests empfohlen, bevor die Testausführung offiziell beginnt.
Die Beendigungskriterien erfordern die erfolgreiche Validierung aller Testfälle. Mängel sollten geschlossen oder zurückgestellt werden; Testfallausführung und Fehlerzusammenfassungsbericht sollten bereit sein.

Aktivitäten zur Testdurchführung

Das Ziel dieser Phase ist die Echtzeitvalidierung von AUT, bevor mit der Produktion / Freigabe fortgefahren wird. Um sich von dieser Phase abzumelden, führt das QS-Team verschiedene Arten von Tests durch, um die Produktqualität sicherzustellen. Neben dieser Fehlerberichterstattung und erneuten Prüfung ist auch in dieser Phase eine wichtige Aktivität. Im Folgenden sind die wichtigen Aktivitäten dieser Phase aufgeführt:

Testen der Systemintegration

Hier beginnt die eigentliche Validierung von Produkt / AUT. System Integration Testing (SIT) ist eine Black-Box-Testtechnik, mit der die Konformität des Systems anhand der festgelegten Anforderungen / Testfälle bewertet wird.

Systemintegrationstests werden normalerweise für eine Teilmenge des Systems durchgeführt. Die SIT kann mit minimalem Einsatz von Testwerkzeugen durchgeführt, auf die ausgetauschten Interaktionen überprüft und das Verhalten jedes Datenfelds innerhalb einer einzelnen Schicht untersucht werden. Nach der Integration gibt es drei Hauptzustände des Datenflusses:

Datenstatus innerhalb der Integrationsschicht
Datenstatus innerhalb der Datenbankschicht
Datenstatus innerhalb der Anwendungsschicht

Note- Bei SIT-Tests versucht das QA-Team, so viele Fehler wie möglich zu finden, um die Qualität sicherzustellen. Das Hauptziel hierbei ist es, so viele Fehler wie möglich zu finden.

Fehlerberichterstattung

Ein Softwarefehler tritt auf, wenn das erwartete Ergebnis nicht mit dem tatsächlichen Ergebnis übereinstimmt. Dies kann ein Fehler, ein Fehler, ein Fehler oder ein Fehler in einem Computerprogramm sein. Die meisten Fehler entstehen durch Fehler und Irrtümer von Entwicklern oder Architekten.

Während der Durchführung von SIT-Tests stellt das QA-Team diese Art von Fehlern fest und diese müssen den betroffenen Teammitgliedern gemeldet werden. Die Mitglieder ergreifen weitere Maßnahmen und beheben die Mängel. Ein weiterer Vorteil der Berichterstattung besteht darin, dass der Status von Fehlern leichter nachverfolgt werden kann. Es gibt viele beliebte Tools wie ALM, QC, JIRA, Version 1 und Bugzilla, die die Fehlerberichterstattung und -verfolgung unterstützen.

Die Fehlerberichterstattung ist ein Prozess zum Auffinden von Fehlern in der zu testenden Anwendung oder zum getesteten Produkt, indem das Feedback von Kunden getestet oder aufgezeichnet wird und neue Versionen des Produkts erstellt werden, mit denen die Fehler basierend auf dem Feedback des Kunden behoben werden.

Die Fehlerverfolgung ist auch ein wichtiger Prozess in der Softwareentwicklung, da komplexe und geschäftskritische Systeme Hunderte von Fehlern aufweisen. Einer der schwierigsten Faktoren ist die Verwaltung, Bewertung und Priorisierung dieser Fehler. Die Anzahl der Fehler wird über einen bestimmten Zeitraum vervielfacht. Um sie effektiv zu verwalten, wird das Fehlerverfolgungssystem verwendet, um die Arbeit zu erleichtern.

Fehlerzuordnung

Sobald ein Fehler gemeldet und protokolliert wurde, sollte er den betreffenden fehlgeschlagenen / blockierten Testfällen und den entsprechenden Anforderungen in der Anforderungsrückverfolgbarkeitsmatrix zugeordnet werden. Diese Zuordnung erfolgt durch den Defect Reporter. Es hilft, einen ordnungsgemäßen Fehlerbericht zu erstellen und die Unschärfe des Produkts zu analysieren. Sobald die Testfälle und Anforderungen mit dem Fehler verknüpft sind, können die Stakeholder analysieren und entscheiden, ob der Fehler basierend auf Priorität und Schweregrad behoben / verschoben werden soll.

Erneutes Testen

Beim erneuten Testen wird ein zuvor fehlgeschlagener Test gegen AUT ausgeführt, um zu überprüfen, ob das Problem behoben ist. Nachdem ein Fehler behoben wurde, wird ein erneuter Test durchgeführt, um das Szenario unter denselben Umgebungsbedingungen zu überprüfen.

Während des erneuten Testens suchen Tester nach detaillierten Details im geänderten Funktionsbereich, während Regressionstests alle Hauptfunktionen abdecken, um sicherzustellen, dass aufgrund dieser Änderung keine Funktionen beeinträchtigt werden.

Regressionstests

Sobald sich alle Fehler im Status "Geschlossen", "Zurückgestellt" oder "Zurückgewiesen" befinden und keiner der Testfälle in Bearbeitung / Fehlgeschlagen / Kein Ausführen ist, kann gesagt werden, dass das Testen der Systemintegration vollständig auf Testfällen und Anforderungen basiert. Es ist jedoch eine schnelle Testrunde erforderlich, um sicherzustellen, dass keine der Funktionen aufgrund von Codeänderungen / Fehlerkorrekturen beeinträchtigt wird.

Regressionstests sind eine Black-Box-Testtechnik, bei der die Tests erneut ausgeführt werden, die sich aufgrund von Codeänderungen ausgewirkt haben. Diese Tests sollten während des gesamten Lebenszyklus der Softwareentwicklung so oft wie möglich durchgeführt werden.

Arten von Regressionstests

Final Regression Tests- Ein "abschließender Regressionstest" wird durchgeführt, um den Build zu validieren, der über einen bestimmten Zeitraum keine Änderung erfahren hat. Dieser Build wird bereitgestellt oder an Kunden ausgeliefert.
Regression Tests - Ein normaler Regressionstest wird durchgeführt, um zu überprüfen, ob der Build durch die letzten Codeänderungen zur Fehlerbehebung oder zur Verbesserung KEINE anderen Teile der Anwendung beschädigt hat.

Aktivitätsblockdiagramm

Das folgende Blockdiagramm zeigt die wichtigen Aktivitäten in dieser Phase. es zeigt auch die Abhängigkeit von den vorherigen Phasen -

Der Fehlerlebenszyklus, auch als Fehlerlebenszyklus bezeichnet, ist die Reise eines Fehlers, der Zyklus, den ein Fehler während seiner Lebensdauer durchläuft. Dies variiert von Organisation zu Organisation und auch von Projekt zu Projekt, da es vom Softwaretestprozess gesteuert wird und auch von den verwendeten Tools abhängt.

Fehlerlebenszyklus - Workflow

Das folgende Diagramm zeigt den Workflow eines Fehlerlebenszyklus.

Zustände eines Defektlebenszyklus

Im Folgenden sind die verschiedenen Zustände eines Fehlerlebenszyklus aufgeführt.

New - Möglicher Fehler, der gemeldet wird und noch validiert werden muss.
Assigned - Zugewiesen an ein zu adressierendes Entwicklungsteam.
Active- Der Fehler wird vom Entwickler behoben und die Untersuchung ist im Gange. Zu diesem Zeitpunkt gibt es zwei mögliche Ergebnisse - Zurückgestellt oder Abgelehnt.
Test / Fixed / Ready for Retest - Der Defekt ist behoben und bereit zum Testen.
Verified - Der erneut getestete Fehler und der Test wurden von der Qualitätssicherung überprüft.
Closed - Der Endzustand des Defekts, der nach der erneuten Qualitätssicherung geschlossen werden kann oder geschlossen werden kann, wenn der Defekt doppelt vorhanden ist oder als NICHT defekt angesehen wird.
Reopened - Wenn der Fehler NICHT behoben ist, öffnet / reaktiviert die Qualitätssicherung den Fehler erneut.
Deferred - Wenn ein Fehler in diesem bestimmten Zyklus nicht behoben werden kann, wird er auf eine zukünftige Version verschoben.
Rejected - Ein Defekt kann aus einem der drei Gründe zurückgewiesen werden - doppelter Defekt, KEIN Defekt, nicht reproduzierbar.

Fehler werden aus Sicht des QS-Teams als klassifiziert Priority und aus entwicklungsperspektive als Severity(Komplexität des Codes, um es zu beheben). Dies sind zwei Hauptklassifikationen, die eine wichtige Rolle im Zeitrahmen und im Arbeitsaufwand für die Behebung von Fehlern spielen.

Was ist Priorität?

Priorität ist definiert als die Reihenfolge, in der die Mängel behoben werden sollen. Der Prioritätsstatus wird normalerweise vom QA-Team festgelegt, während der Fehler gegen das Entwicklerteam angehoben wird, wobei der Zeitrahmen für die Behebung des Fehlers angegeben wird. Der Prioritätsstatus wird basierend auf den Anforderungen der Endbenutzer festgelegt.

Wenn das Firmenlogo beispielsweise falsch auf der Webseite des Unternehmens platziert ist, ist die Priorität hoch, aber von geringer Schwere.

Prioritätsliste

Eine Priorität kann folgendermaßen kategorisiert werden:

Low - Dieser Fehler kann behoben werden, nachdem die kritischen behoben wurden.
Medium - Der Fehler sollte in den nachfolgenden Builds behoben werden.
High - Der Fehler muss sofort behoben werden, da der Fehler die Anwendung in erheblichem Maße beeinträchtigt und die entsprechenden Module erst nach Behebung verwendet werden können.
Urgent - Der Fehler muss sofort behoben werden, da der Fehler die Anwendung oder das Produkt stark beeinträchtigt und das Produkt erst verwendet werden kann, wenn es behoben wurde.

Was ist Schweregrad?

Der Schweregrad ist definiert als die Unschärfe eines Fehlers in der Anwendung und die Komplexität des Codes, um ihn aus Entwicklungssicht zu beheben. Ithängt mit dem Entwicklungsaspekt des Produkts zusammen. Der Schweregrad kann basierend darauf entschieden werden, wie schlecht / entscheidend der Defekt für das System ist. Der Schweregradstatus kann eine Vorstellung von der Abweichung der Funktionalität aufgrund des Defekts geben.

Example - Für die Flugbetriebswebsite ist ein Fehler bei der Generierung der Ticketnummer gegen Reservierung von hoher Schwere und auch von hoher Priorität.

Schweregradliste

Der Schweregrad kann folgendermaßen kategorisiert werden:

Critical /Severity 1- Der Fehler wirkt sich auf die wichtigsten Funktionen der Anwendung aus, und das QS-Team kann die Validierung der zu testenden Anwendung nicht fortsetzen, ohne sie zu beheben. Beispielsweise stürzt die App / das Produkt häufig ab.
Major / Severity 2- Defekt wirkt sich auf ein Funktionsmodul aus; Das QA-Team kann dieses bestimmte Modul nicht testen, sondern mit der Validierung anderer Module fortfahren. Zum Beispiel funktioniert die Flugreservierung nicht.
Medium / Severity 3- Der Fehler hat ein Problem mit einem einzelnen Bildschirm oder hängt mit einer einzelnen Funktion zusammen, aber das System funktioniert weiterhin. Der Defekt hier blockiert keine Funktionalität. Beispielsweise ist Ticket # eine Darstellung, die nicht den richtigen alphanumerischen Zeichen wie den ersten fünf Zeichen und den letzten fünf als numerischen Zeichen folgt.
Low / Severity 4- Es hat keinen Einfluss auf die Funktionalität. Dies kann ein kosmetischer Defekt, eine Inkonsistenz der Benutzeroberfläche für ein Feld oder ein Vorschlag zur Verbesserung der Endbenutzererfahrung auf der Seite der Benutzeroberfläche sein. Beispielsweise stimmt die Hintergrundfarbe der Schaltfläche "Senden" nicht mit der der Schaltfläche "Speichern" überein.

Eine Überprüfung anhand der Testausgangskriterien ist sehr wichtig, um zu behaupten, dass der Test nun abgeschlossen ist. Vor Beendigung des Testprozesses wird die Produktqualität anhand der Testabschlusskriterien gemessen.

Das Einstiegskriterium dieser Phase ist, dass die Ausführung des Testfalls abgeschlossen ist, Testergebnisse vorliegen und der Fehlerbericht fertig ist.

Die Kriterien für den Testabschluss umfassen Folgendes:

Die angegebene Abdeckung wurde erreicht.
Nein showstoppers oder kritische Mängel
Es sind nur sehr wenige Fehler mit mittlerer oder niedriger Priorität bekannt. Diese haben keinen Einfluss auf die Verwendung des Produkts.

Das Ausstiegskriterium dieser Phase ist die Bereitstellung von Testabschlussberichten und die Erstellung von Matrizen, die später vom Kunden abgemeldet werden.

Lassen Sie uns nun das diskutieren activities involved in the closure of Test Cycle.

Testabschlussbericht

Die Testabschlussberichterstattung ist ein Prozess, bei dem die Testmetriken in einem zusammengefassten Format gemeldet werden, um die Stakeholder zu aktualisieren. Dies ermöglicht es ihnen, eine fundierte Entscheidung zu treffen.

Der Testabschlussbericht enthält die folgenden Informationen.

Testzusammenfassungsbericht-ID
Summary
Variances
Zusammenfassende Ergebnisse
Evaluation
Geplante und tatsächliche Anstrengungen
Abmelden

Ein guter Testabschlussbericht zeigt die Qualität an, misst ausstehende Risiken und identifiziert das Niveau einer getesteten Software.

Testabschlussmatrix

Nach Abschluss des Tests werden verschiedene Matrizen gesammelt, um die Testberichte zu erstellen. Die Kriterien für die Erstellung der Berichte umfassen Folgendes:

Anzahl der ausgeführten Tests
Anzahl der bestandenen Tests
Anzahl fehlgeschlagener Tests
Anzahl der fehlgeschlagenen Tests basierend auf jedem Modul
Anzahl der während des Ausführungszyklus ausgelösten Testfehler
Anzahl der akzeptierten Testfehler
Anzahl der zurückgewiesenen Testfehler
Anzahl der zurückgestellten Testfehler
Status der aktiven Mängel
Berechnung des Qualitätsindex des Builds

Testergebnisse

Während Sie einen Testfall ausführen, Fehler erneut testen und einen Regressionstestfall durchführen, Test results articulate sollte gespeichert werden und kann zusammen mit den Abschlussdokumenten des Testzyklus erstellt werden, um den Abschluss der Testausführung zu unterstützen.

Artikulationen können Screenshots, Ergebnisse von Datenbankabfragen, Aufzeichnungen, Protokolldateien usw. sein.