Ein Testplan ist ein detailliertes Dokument, das Softwaretestbereiche und -aktivitäten beschreibt. Es beschreibt die Teststrategie, die Ziele, den Testplan, die erforderlichen Ressourcen (Personal, Software und Hardware), die Testschätzung und die Testergebnisse.

Der Testplan ist die Grundlage für das Testen jeder Software. Es ist die wichtigste Aktivität, die die Verfügbarkeit aller Listen geplanter Aktivitäten in der richtigen Reihenfolge gewährleistet.

Der Testplan ist eine Vorlage für die Durchführung von Softwaretestaktivitäten als definierter Prozess, der vollständig vom Testmanager überwacht und gesteuert wird. Der Testplan wird vom Testleiter (60 %), dem Testmanager (20 %) und dem Testingenieur (20 %) erstellt.

Arten von Testplänen

Es gibt drei Arten von Testplänen

Grenze mit CSS

• Master-Testplan
• Phasentestplan
• Testtypspezifische Testpläne

Master-Testplan

Der Mastertestplan ist eine Art Testplan mit mehreren Testebenen. Es beinhaltet eine vollständige Teststrategie.

Phasentestplan

Ein Phasentestplan ist eine Art Testplan, der eine beliebige Phase der Teststrategie abdeckt. Zum Beispiel eine Liste von Tools, eine Liste von Testfällen usw.

Spezifische Testpläne

Spezifischer Testplan für wichtige Testarten wie Sicherheitstests, Lasttests, Leistungstests usw. Mit anderen Worten: ein spezifischer Testplan für nichtfunktionale Tests.

So schreiben Sie einen Testplan

Die Erstellung eines Testplans ist die wichtigste Aufgabe des Testmanagementprozesses. Befolgen Sie gemäß IEEE 829 die folgenden sieben Schritte, um einen Testplan zu erstellen.

• Analysieren Sie zunächst die Produktstruktur und -architektur.
• Entwerfen Sie nun die Teststrategie.
• Definieren Sie alle Testziele.
• Definieren Sie den Testbereich.
• Definieren Sie alle nutzbaren Ressourcen.
• Planen Sie alle Aktivitäten angemessen.
• Bestimmen Sie alle Testergebnisse.

Testplankomponenten oder -attribute

Der Testplan besteht aus verschiedenen Teilen, die uns helfen, die gesamte Testaktivität abzuleiten.

Ziele: Es besteht aus Informationen über Module, Funktionen, Testdaten usw., die das Ziel der Anwendung angeben, also das Anwendungsverhalten, das Ziel usw.

Umfang: Es enthält Informationen, die mit der jeweiligen Anwendung getestet werden müssen. Der Geltungsbereich kann weiter in zwei Teile unterteilt werden:

• Im Visier
• Außer Reichweite

Im Visier: Dies sind die Module, die gründlich (im Detail) getestet werden müssen.

Unser Umfang: Dies sind die Module, die nicht rigoros getestet werden müssen.

Zum Beispiel Angenommen, wir möchten eine Gmail-Anwendung testen zu testende Funktionen wie zum Beispiel E-Mails verfassen, gesendete Elemente, Posteingang, Entwürfe und das Funktionen, die nicht getestet werden wie zum Beispiel Helfen usw. Das bedeutet, dass wir in der Planungsphase anhand der im Produkt vorgegebenen Frist entscheiden, welche Funktionalität überprüft werden muss oder nicht.

Jetzt Wie entscheiden wir, welche Funktionen nicht getestet werden?

Wir haben die folgenden Aspekte, bei denen wir entscheiden können, welche Funktion nicht getestet werden soll:

• Wie wir oben sehen Helfen Die Funktionen werden nicht getestet, da sie vom technischen Redakteur geschrieben und entwickelt und von einem anderen professionellen Autor überprüft wurden.
• Nehmen wir an, dass wir eine Anwendung haben, die Folgendes hat P, Q, R und S Funktionen, die entsprechend den Anforderungen entwickelt werden müssen. Aber hier wurde die S-Funktion bereits von einem anderen Unternehmen entwickelt und verwendet. Daher wird das Entwicklungsteam S von diesem Unternehmen kaufen und zusätzliche Funktionen wie P, Q und R integrieren.

Derzeit werden wir keine Funktionstests für die S-Funktion durchführen, da diese bereits in Echtzeit verwendet wurde. Wir werden jedoch die Integrationstests und Systemtests zwischen P-, Q-, R- und S-Funktionen durchführen, da die neuen Funktionen möglicherweise nicht ordnungsgemäß mit der S-Funktion funktionieren, wie wir im folgenden Bild sehen können:

• Angenommen, in der ersten Version des Produkts sind die Elemente, die entwickelt wurden, wie z P, Q, R, S, T, U, V, W…..X, Y, Z . Jetzt stellt der Kunde die Anforderungen für die neuen Funktionen bereit, die das Produkt in der zweiten Version verbessern, und die neuen Funktionen sind A1, B2, C3, D4 und E5.

Danach schreiben wir den Umfang während des Testplans als

Umfang

Zu testende Funktionen

A1, B2, C3, D4, E5 (neue Funktionen)

P, Q, R, S, T

Funktionen, die nicht getestet werden dürfen

W…..X, Y, Z

Deshalb werden wir zuerst die neuen Funktionen prüfen und dann mit den alten Funktionen fortfahren, da diese nach dem Hinzufügen der neuen Funktionen möglicherweise betroffen sein könnten, was bedeutet, dass sie sich auch auf die Auswirkungsbereiche auswirken werden, also werden wir eine Runde Regressionstests für P, Q durchführen , R…, T-Funktionen.

Testmethodik:

Es enthält Informationen zur Durchführung verschiedener Arten von Tests wie Funktionstests, Integrationstests und Systemtests usw. für die Anwendung. Dabei entscheiden wir, welche Art von Tests durchgeführt werden sollen. Je nach Anwendungsanforderung führen wir die verschiedenen Funktionen aus. Und hier sollten wir auch definieren, welche Art von Tests wir in den Testmethoden verwenden werden, damit jeder, wie das Management, das Entwicklungsteam und das Testteam, es leicht verstehen kann, da die Testbegriffe nicht standardisiert sind.

Zum Beispiel, für eigenständige Anwendungen wie z Adobe Photoshop Wir führen die folgenden Arten von Tests durch:

Smoke-Tests → Funktionstests → Integrationstests → Systemtests → Ad-hoc-Tests → Kompatibilitätstests → Regressionstests → Globalisierungstests → Barrierefreiheitstests → Usability-Tests → Zuverlässigkeitstests → Wiederherstellungstests → Installations- oder Deinstallationstests

Und nehmen wir an, wir müssen das testen https://www.jeevansathi.com/ Daher führen wir folgende Arten von Tests durch:

Ansatz

Dieses Attribut wird verwendet, um den Ablauf der Anwendung während der Durchführung von Tests zu beschreiben und als zukünftige Referenz.

Wir können den Ablauf der Bewerbung anhand der folgenden Aspekte verstehen:

Durch das Schreiben der High-Level-Szenarien Durch Schreiben des Flussdiagramms

Durch das Schreiben der High-Level-Szenarien

Zum Beispiel Nehmen wir an, wir testen das Google Mail Anwendung:

• Melden Sie sich bei Gmail an – sendet eine E-Mail und prüft, ob sie sich auf der Seite „Gesendete Elemente“ befindet
• Einloggen in …….
• ……
• …....

Wir schreiben dies, um die Ansätze zu beschreiben, die zum Testen des Produkts verwendet werden müssen, und nur für die kritischen Funktionen, für die wir die High-Level-Szenarien schreiben werden. Hier konzentrieren wir uns nicht darauf, alle Szenarien abzudecken, da der jeweilige Testingenieur entscheiden kann, welche Funktionen getestet werden müssen oder nicht.

Durch Schreiben des Flussdiagramms

Das Flussdiagramm wird geschrieben, weil das Schreiben der High-Level-Szenarien etwas zeitaufwändig ist, wie wir im folgenden Bild sehen können:

Wir erstellen Flussdiagramme, um die folgenden Vorteile zu erzielen:

• Die Abdeckung ist einfach
• Das Zusammenführen ist einfach

Der Ansatz lässt sich in zwei Teile unterteilen:

• Ansatz von oben nach unten
• Ansatz von unten nach oben

Annahme

Es enthält Informationen zu einem Problem oder Problem, das möglicherweise während des Testprozesses aufgetreten ist. Wenn wir die Testpläne schreiben, werden die gesicherten Annahmen wie Ressourcen und Technologien usw. getroffen.

Risiko

Dies sind die Herausforderungen, denen wir uns stellen müssen, um die Anwendung in der aktuellen Version zu testen. Wenn die Annahmen fehlschlagen, sind die Risiken damit verbunden.

Zum Beispiel, Für eine Anwendung wird das Veröffentlichungsdatum verschoben.

Schadensbegrenzungsplan oder Notfallplan

Es handelt sich um einen Backup-Plan, der darauf vorbereitet ist, die Risiken oder Probleme zu bewältigen.

Java unveränderliche Liste

Sehen wir uns ein Beispiel für Annahme, Risiko und den Notfallplan zusammen an, da sie miteinander in Zusammenhang stehen.

In jedem Produkt ist die Annahme Wir werden sicherstellen, dass alle drei Testingenieure bis zur Fertigstellung des Produkts dort sein werden und jedem von ihnen unterschiedliche Module wie P, Q und R zugewiesen werden. In diesem speziellen Szenario sind die Risiko Könnte sein, dass der Testingenieur das Projekt mittendrin verlassen würde.

deshalb, die Notfallplan Jeder Funktion wird ein primärer und untergeordneter Eigentümer zugewiesen. Wenn also ein Testingenieur das Unternehmen verlässt, übernimmt der untergeordnete Eigentümer diese spezifische Funktion und hilft auch dem neuen Testingenieur, damit dieser die ihm zugewiesenen Module verstehen kann.

Die Annahmen, Risiken und Schadensbegrenzungs- oder Notfallpläne beziehen sich immer auf das Produkt selbst. Die verschiedenen Arten von Risiken sind wie folgt:

• Kundenperspektive
• Ressourcenansatz
• Technische Meinung

Rolle & Verantwortung

Es definiert die vollständige Aufgabe, die vom gesamten Testteam ausgeführt werden muss. Wenn ein großes Projekt kommt, dann das Testmanager ist eine Person, die den Testplan schreibt. Wenn es 3-4 kleine Projekte gibt, weist der Testmanager jedes Projekt jedem Testleiter zu. Und dann schreibt der Testleiter den Testplan für das ihm zugewiesene Projekt.

Sehen wir uns ein Beispiel an, in dem wir die Rollen und Verantwortlichkeiten des Testmanagers, des Testleiters und der Testingenieure verstehen.

Rolle: Testmanager

Name: Ryan

Verantwortung:

• Bereiten Sie den Testplan vor (schreiben und überprüfen).
• Führen Sie das Treffen mit dem Entwicklungsteam durch
• Führen Sie das Treffen mit dem Testteam durch
• Führen Sie das Treffen mit dem Kunden durch
• Führen Sie ein monatliches Stand-up-Meeting durch
• Versionshinweis abzeichnen
• Umgang mit Eskalationen und Problemen

Rolle: Testleiter

Name: Harvey

Verantwortung:

• Bereiten Sie den Testplan vor (schreiben und überprüfen).
• Führen Sie tägliche Stand-up-Meetings durch
• Überprüfen und genehmigen Sie den Testfall
• Bereiten Sie das RTM und die Berichte vor
• Module zuweisen
• Abwicklungsplan

Rolle: Testingenieur 1, Testingenieur 2 und Testingenieur 3

Name: Louis, Jessica, Donna

Weisen Sie die Module M1, M2 und M3 zu

Verantwortung:

• Schreiben, überprüfen und führen Sie die Testdokumente aus, die aus Testfällen und Testszenarien bestehen
• Lesen, überprüfen, verstehen und analysieren Sie die Anforderung
• Schreiben Sie den Ablauf der Anwendung
• Führen Sie den Testfall aus
• RTM für die jeweiligen Module
• Fehlerverfolgung
• Bereiten Sie den Testausführungsbericht vor und teilen Sie ihn dem Testleiter mit.

Zeitplan

Es wird verwendet, um den Zeitpunkt der Arbeit zu erklären, was getan werden muss, oder deckt dieses Attribut ab, wann genau jede Testaktivität beginnen und enden sollte? Und auch zu jeder Testaktivität zum jeweiligen Termin werden die genauen Daten genannt.

Wie wir im Bild unten sehen können, gibt es daher für die jeweilige Aktivität ein Startdatum und ein Enddatum; Für jeden Test zu einem bestimmten Build gibt es das angegebene Datum.

Zum Beispiel

• Testfälle schreiben
• Ausführungsprozess

Fehlerverfolgung

Dies erfolgt im Allgemeinen mithilfe von Tools, da wir den Status jedes Fehlers nicht manuell verfolgen können. Und wir kommentieren auch, wie wir die während des Testprozesses identifizierten Fehler kommunizieren und an das Entwicklungsteam zurücksenden und wie das Entwicklungsteam darauf antwortet. Hier erwähnen wir auch die Priorität der Fehler wie hoch, mittel und niedrig.

Im Folgenden sind verschiedene Aspekte der Fehlerverfolgung aufgeführt:

Techniken zur Fehlerverfolgung
…..
……
……
……Tools zur Fehlerverfolgung
Wir können den Namen des Tools kommentieren, das wir zur Fehlerverfolgung verwenden werden. Zu den am häufigsten verwendeten Bug-Tracking-Tools gehören Jira, Bugzilla, Mantis und Trac usw.<Schwere
Der Schweregrad könnte wie folgt sein:
Blocker oder Showstopper
…..
….. (Erklären Sie es anhand eines Beispiels im Testplan)
Zum Beispiel , liegt ein Defekt im Modul vor; Wir können nicht weitergehen, um andere Module zu testen, denn wenn der Fehler blockiert wird, können wir mit der Überprüfung anderer Module fortfahren.
Kritisch
……
….. (Erklären Sie es anhand eines Beispiels im Testplan)
In dieser Situation wirken sich die Mängel auf das Geschäft aus.
Wesentlich
….
…. (Erklären Sie es anhand eines Beispiels im Testplan)
Unerheblich
…..
….. (Erklären Sie es anhand eines Beispiels im Testplan)
Bei diesen Mängeln handelt es sich um solche, die das Erscheinungsbild der Anwendung beeinträchtigen.Priorität
Hoch-P1
…..
Mittel-P2
…..
Niedrig-P3
…..
…..
P4

Basierend auf der Priorität der Fehler (z. B. hoch, mittel und niedrig) werden wir sie daher in P1, P2, P3 und P4 kategorisieren.

Testumgebungen

Dies sind die Umgebungen, in denen wir die Anwendung testen werden, und hier haben wir zwei Arten von Umgebungen, nämlich: Software Und Hardware Aufbau.

Der Softwarekonfiguration bedeutet die Details über verschiedene Betriebssysteme wie zum Beispiel Windows, Linux, UNIX und Mac und vielfältig Browser wie Google Chrome, Firefox, Opera, Internet Explorer , und so weiter.

Und das Hardwarekonfiguration bedeutet die Information über verschiedene Größen von RAM, ROM und die Prozessoren .

Zum Beispiel

• Der Software beinhaltet Folgendes:

Server

Hinweis: Die oben genannten Server sind die Server, die vom Testteam zum Testen der Anwendung verwendet werden.

Klient

Hinweis: Die obigen Details geben die verschiedenen Betriebssysteme und Browser an, in denen das Testteam die Anwendung testen wird.

• Der Hardware beinhaltet Folgendes:

Server : Sun StarCat 1500

Dieser spezielle Server kann vom Testteam zum Testen seiner Anwendung verwendet werden.

Klient:

Es hat die folgende Konfiguration:

Hinweis: Es stellt die Konfiguration der Systeme der Testingenieure bereit, die das Testteam bilden.

Prozess zur Installation der Software
……
…..
…..

Das Entwicklungsteam stellt die Konfiguration zur Installation der Software bereit. Wenn das Entwicklungsteam den Prozess noch nicht bereitstellt, schreiben wir ihn als Task-Based Development (TBD) in den Testplan.

Ein- und Ausstiegskriterien

Dies ist eine notwendige Bedingung, die erfüllt sein muss, bevor der Testprozess gestartet und beendet wird.

NPM Clean Cache Force

Aufnahmekriterien

Die Einreisekriterien beinhalten folgende Bedingungen:

• Der White-Box-Test sollte abgeschlossen sein.
• Verstehen und analysieren Sie die Anforderung und bereiten Sie die Testdokumente vor oder wenn die Testdokumente fertig sind.
• Die Testdaten sollten bereit sein.
• Der Build bzw. die Anwendung muss vorbereitet werden
• Module oder Features müssen den verschiedenen Testingenieuren zugewiesen werden.
• Die erforderliche Ressource muss bereit sein.

Abbruchkriterium

Die Ausstiegskriterien beinhalten folgende Bedingungen:

• Wenn alle Testfälle ausgeführt werden.
• Die meisten Testfälle müssen es sein bestanden .
• Hängt von der Schwere der Fehler ab, was bedeutet, dass es keinen Blocker oder größeren Fehler geben darf, während einige kleinere Fehler vorhanden sind.

Bevor wir mit der Durchführung von Funktionstests beginnen, alle oben genannten Punkte Aufnahmekriterien sollte befolgt werden. Nachdem wir Funktionstests durchgeführt haben und bevor wir Integrationstests durchführen, dann die Ausstiegskriterien von Die Funktionstests sollten befolgt werden, da der Prozentsatz der Ausstiegskriterien durch das Treffen mit dem Entwicklungs- und Testmanager festgelegt wird, da der Prozentsatz durch ihre Zusammenarbeit erreicht werden kann. Wenn jedoch die Abschlusskriterien des Funktionstests nicht befolgt werden, können wir nicht mit dem Integrationstest fortfahren.

Hier basierend auf der Schwere Der Fehler bedeutet, dass das Testteam beschlossen hätte, in den nächsten Phasen weiterzumachen.

Testautomatisierung

Dabei werden wir Folgendes beschließen:

• Welche Funktion muss automatisiert werden und welche nicht automatisiert werden?
• Welches Testautomatisierungstool werden wir auf welchem ​​Automatisierungsframework verwenden?

Wir automatisieren den Testfall erst nach der ersten Veröffentlichung.

Hier stellt sich die Frage, auf welcher Grundlage Wir Wille entscheiden, welche Funktionen getestet werden müssen?

Im obigen Bild sehen wir, dass die am häufigsten verwendeten Funktionen immer wieder getestet werden müssen. Angenommen, wir müssen die Gmail-Anwendung überprüfen, wo sich die wesentlichen Funktionen befinden Verfassen Sie E-Mails, gesendete Elemente und den Posteingang . Deshalb werden wir diese Funktionen testen, da die Durchführung manueller Tests mehr Zeit in Anspruch nimmt und auch zu einer eintönigen Aufgabe wird.

Jetzt, Wie entscheiden wir, welche Funktionen nicht getestet werden?

Vermuten die Hilfe Die Funktion der Gmail-Anwendung wird nicht immer wieder getestet, da diese Funktionen nicht regelmäßig verwendet werden und wir sie daher nicht häufig überprüfen müssen.

Aber wenn einige Funktionen instabil sind und viele Fehler aufweisen , was bedeutet, dass wir diese Funktionen nicht testen werden, da sie im Rahmen manueller Tests immer wieder getestet werden müssen.

Wenn Es gibt eine Funktion, die regelmäßig getestet werden muss , aber wir erwarten eine Anforderungsänderung für diese Funktion und prüfen sie daher nicht, da die Änderung der manuellen Testfälle komfortabler ist als eine Änderung im Automatisierungstestskript.

Bemühungsschätzung

Dabei planen wir den Aufwand, den jedes Teammitglied aufbringen muss.

Testergebnis

Hierbei handelt es sich um die vom Testteam erstellten Dokumente, die wir dem Kunden zusammen mit dem Produkt übergeben haben. Es beinhaltet Folgendes:

Versuchsplan Testfälle Testskripte RTM (Requirement Traceability Matrix) Fehlerbericht Testausführungsbericht Grafiken und Metriken Versionshinweise

Grafiken und Metriken

Graph

In diesem werden wir über die Arten von diskutieren Grafiken Wir senden Ihnen ein Beispiel für jedes Diagramm zu und stellen es Ihnen auch zur Verfügung.

Wie wir sehen, haben wir fünf verschiedene Diagramme, die die verschiedenen Aspekte des Testprozesses zeigen.

Grafik1: Darin zeigen wir, wie viele Fehler festgestellt und wie viele Fehler in jedem Modul behoben wurden.

Grafik 2: Abbildung eins zeigt, wie viele kritische, größere und kleinere Fehler für jedes Modul identifiziert und wie viele für die jeweiligen Module behoben wurden.

Grafik3: In dieser speziellen Grafik stellen wir die dar Erstellen Sie ein kluges Diagramm , was bedeutet, wie viele Fehler in jedem Build für jedes Modul identifiziert und behoben wurden. Basierend auf dem Modul haben wir die Fehler ermittelt. Wir werden hinzufügen R um die Anzahl der Defekte in P und Q anzuzeigen, und wir addieren auch S um die Defekte in P, Q und R zu zeigen.

Grafik4: Der Testleiter wird das entwerfen Fehlertrendanalyse Erstellen Sie ein monatlich erstelltes Diagramm und senden Sie es ebenfalls an die Geschäftsführung. Und es ist genau wie eine Vorhersage, die am Ende des Produkts erfolgt. Und hier können wir auch Bewerten Sie die Fehlerbehebungen wie wir das beobachten können Bogen hat eine Aufwärtstendenz im Bild unten.

Grafik5: Der Testmanager hat diese Art von Diagramm entworfen. Dieses Diagramm soll die Lücke in der Bewertung von Fehlern und den tatsächlich aufgetretenen Fehlern verdeutlichen und außerdem dazu beitragen, die Bewertung von Fehlern in Zukunft zu verbessern.

Metriken

Wie oben erstellen wir das Fehlerverteilungsdiagramm, das in Abbildung 1 dargestellt ist, und entwerfen mit Hilfe der oben genannten Daten auch die Metriken.

Zum Beispiel

In der obigen Abbildung speichern wir die Aufzeichnungen aller Testingenieure in einem bestimmten Projekt und wie viele Fehler identifiziert und behoben wurden. Wir können diese Daten auch für zukünftige Analysen verwenden. Wenn eine neue Anforderung auftritt, können wir entscheiden, wem wir die herausfordernde Funktion zum Testen zur Verfügung stellen, basierend auf der Anzahl der Fehler, die zuvor gemäß den oben genannten Metriken gefunden wurden. Und wir wissen besser, wer mit den problematischen Merkmalen am besten umgehen und die größtmögliche Anzahl an Fehlern finden kann.

Veröffentlichungshinweis: Es handelt sich um ein Dokument, das während der Veröffentlichung des Produkts erstellt und vom Testmanager unterzeichnet wird.

Im Bild unten sehen wir, dass das Endprodukt entwickelt und für den Kunden bereitgestellt wird, und der Name der neuesten Version lautet Beta .

Der Veröffentlichungshinweis besteht aus Folgendem:

• Benutzerhandbuch.
• Liste der ausstehenden und offenen Mängel.
• Liste der hinzugefügten, geänderten und gelöschten Funktionen.
• Liste der Plattform (Betriebssystem, Hardware, Browser), auf der das Produkt getestet wird.
• Plattform, auf der das Produkt nicht getestet wird.
• Liste der in der aktuellen Version behobenen Fehler und Liste der in der vorherigen Version behobenen Fehler.
• Installationsprozess
• Versionen der Software

Zum Beispiel

Nehme an, dass Beta ist die zweite Version der Anwendung nach der ersten Version Alpha es ist veröffentlicht worden. Einige der in der ersten Veröffentlichung festgestellten Mängel wurden in der späteren Veröffentlichung behoben. Und hier weisen wir auch auf die Liste der neu hinzugefügten, geänderten und gelöschten Funktionen von der Alpha-Version bis zur Beta-Version hin.

Vorlage

Dieser Teil enthält alle Vorlagen für die Dokumente, die im Produkt verwendet werden. Alle Testingenieure werden im Projekt nur diese Vorlagen verwenden, um die Konsistenz des Produkts aufrechtzuerhalten. Hier haben wir verschiedene Arten von Vorlagen, die während des gesamten Testprozesses verwendet werden, wie zum Beispiel:

• Testfallvorlage
• Vorlage für die Überprüfung von Testfällen
• RTM-Vorlage
• Vorlage für Fehlerberichte
• Testausführungsbericht

Sehen wir uns ein Beispiel eines Testplandokuments an

Seite 1

Seite 3-Seite 18

Seite-20

In-Page 1 füllen wir hauptsächlich nur aus Versionen, Autor, Kommentare und Rezensiert von Felder aus, und nachdem der Manager es genehmigt hat, werden wir die Details in den Feldern erwähnen Genehmigt von und Genehmigungsdatum Felder.

Meistens wird der Testplan vom Testmanager genehmigt und von den Testingenieuren nur überprüft. Und wenn die neuen Funktionen verfügbar sind, werden wir den Testplan ändern und die erforderlichen Änderungen vornehmen Ausführung Anschließend wird es erneut zur weiteren Prüfung, Aktualisierung und Genehmigung an den Manager gesendet. Der Testplan muss bei jeder Änderung aktualisiert werden. Auf Seite 20 die Verweise Geben Sie die Details aller Dokumente an, die wir zum Schreiben des Testplandokuments verwenden werden.

Notiz:

Wer schreibt den Testplan?

• Messleitung → 60 %
• Testmanager→20 %
• Testingenieur→20 %

Wie wir oben sehen können, wird der Testplan daher bei 60 % des Produkts vom Testleiter geschrieben.

Wer überprüft den Testplan?

• Messleitung
• Testmanager
• Testingenieur
• Kunde
• Entwicklungsteam

Der Testingenieur überprüft den Testplan aus seiner Modulperspektive und der Testmanager überprüft den Testplan basierend auf der Kundenmeinung.

Wer genehmigt den Testplan?

• Kunde
• Testmanager

Wer schreibt den Testfall?

• Messleitung
• Testingenieur

Wer überprüft den Testfall?

Java-Sortierliste

• Testingenieur
• Messleitung
• Kunde
• Entwicklungsteam

Wer genehmigt die Testfälle?

• Testmanager
• Messleitung
• Kunde

Richtlinien für Testpläne

• Reduzieren Sie Ihren Testplan.
• Vermeiden Sie Überschneidungen und Redundanz.
• Wenn Sie der Meinung sind, dass Sie einen oben bereits erwähnten Abschnitt nicht benötigen, löschen Sie diesen Abschnitt und fahren Sie fort.
• Sei genau. Wenn Sie beispielsweise ein Softwaresystem als Teil der Testumgebung angeben, geben Sie die Softwareversion und nicht nur den Namen an.
• Vermeiden Sie lange Absätze.
• Verwenden Sie nach Möglichkeit Listen und Tabellen.
• Aktualisieren Sie den Plan bei Bedarf.
• Verwenden Sie kein veraltetes und unbenutztes Dokument.

Bedeutung des Testplans

• Der Testplan gibt unserem Denken eine Richtung vor. Dies ist wie ein Regelbuch, das befolgt werden muss.
• Der Testplan hilft bei der Bestimmung des notwendigen Aufwands zur Validierung der Qualität der getesteten Softwareanwendung.
• Der Testplan hilft Personen, die Testdetails zu verstehen, die mit externen Personen wie Entwicklern, Geschäftsführern, Kunden usw. in Zusammenhang stehen.
• Wichtige Aspekte wie Testplan, Teststrategie, Testumfang usw. werden im Testplan dokumentiert, sodass das Managementteam sie überprüfen und für andere ähnliche Projekte wiederverwenden kann.