how review srs document
Dies ist das zweite Tutorial in unserem 'Kostenloses Online-Training zum Testen von Software in einem Live-Projekt' Serie. Wenn Sie neu hier sind, lesen Sie bitte das erste Einführungs-Tutorial: End-to-End-Schulung zum Testen von Software in einem Live-Projekt.
Lassen Sie uns nun eine detaillierte Analyse darüber durchführen, wie eine SRS-exemplarische Vorgehensweise abläuft, was wir anhand dieses Schritts identifizieren müssen, welche Vorschritte wir unternehmen müssen, bevor wir beginnen, welchen Herausforderungen wir uns stellen müssen usw. eine detaillierte Art und Weise.
SDLCs Entwurfsphase:
Die nächste Phase des SDLC ist „Design“ - hier werden die funktionalen Anforderungen in die technischen Details übersetzt. Die Entwickler-, Design-, Umgebungs- und Datenteams sind an diesem Schritt beteiligt. Das Ergebnis dieses Schritts ist in der Regel ein TDD (Technical Design Document).
Die Eingabe ist das SRS-Dokument sowohl für die Erstellung des TDD als auch für das QA-Team, um mit der Arbeit am QS-Aspekt des Projekts zu beginnen, nämlich der Überprüfung des SRS und der Identifizierung des Testziels.
Was du lernen wirst:
- Was ist eine SRS-Überprüfung?
- Vorschritte zur Überprüfung der Softwareanforderungen
- Ist für Testszenarien eine Vorlage erforderlich?
- Einige wichtige Bemerkungen zur SRS-Überprüfung
- Literatur-Empfehlungen
Was ist eine SRS-Überprüfung?
SRS ist ein Dokument, das vom Entwicklungsteam in Zusammenarbeit mit Business Analysten und Umwelt- / Datenteams erstellt wird. In der Regel wird dieses Dokument nach Fertigstellung mit dem QS-Team über eine Besprechung geteilt, in der eine detaillierte exemplarische Vorgehensweise vereinbart wird.
Manchmal benötigen wir für eine bereits vorhandene Bewerbung keine formelle Besprechung und jemanden, der uns durch dieses Dokument führt. Wir haben möglicherweise die notwendigen Informationen, um dies selbst zu tun.
Die SRS-Überprüfung ist nichts anderes als das Dokument mit den funktionalen Anforderungsspezifikationen durchzugehen und zu verstehen, wie die Zielanwendung aussehen wird.
Das formale Format und ein Beispiel wurden Ihnen im vorherigen Artikel mitgeteilt. Dies bedeutet nicht unbedingt, dass alle SRS genau so dokumentiert werden. Immer die Form ist dem Inhalt untergeordnet .
Einige Teams schreiben nur eine Liste mit Aufzählungszeichen, einige Teams enthalten Anwendungsfälle, einige Teams enthalten Beispiel-Screenshots (wie das Dokument, das wir hatten) und einige beschreiben nur die Details in Absätzen.
Vorschritte zur Überprüfung der Softwareanforderungen
Schritt 1) Dokumente werden mehrfach überarbeitet. Stellen Sie daher sicher, dass wir die richtige Version des Dokuments haben, auf das verwiesen wird, das SRS.
Schritt 2) Legen Sie Richtlinien fest, was am Ende der Überprüfung von jedem Teammitglied erwartet wird. Mit anderen Worten, entscheiden Sie, welche Ergebnisse von diesem Schritt erwartet werden. In der Regel besteht die Ausgabe dieses Schritts darin, die Testszenarien zu identifizieren. Testszenarien sind nichts anderes als einzeilige Zeiger darauf, was für bestimmte Funktionen getestet werden soll.
Schritt 3) Legen Sie auch Richtlinien fest, wie dieses Ergebnis präsentiert werden soll - ich meine die Vorlage.
Schritt 4) Entscheiden Sie, ob jedes Mitglied des Teams an dem gesamten Dokument arbeiten oder es unter sich aufteilen möchte. Es wird dringend empfohlen, dass jeder alles liest, da dies die Wissenskonzentration mit bestimmten Teammitgliedern verhindert.
Bei einem großen Projekt mit fast 1000 Seiten umfassenden SRS-Dokumenten ist es jedoch am praktischsten, das Dokumentmodul aufzuteilen und einzelnen Teammitgliedern zuzuweisen.
Schritt 5) Die SRS-Überprüfung hilft auch dabei, besser zu verstehen, ob für das Testen der Software bestimmte Voraussetzungen erforderlich sind.
Schritt 6) Als Nebenprodukt wird eine Liste von Abfragen identifiziert, bei denen einige Funktionen schwer zu verstehen sind oder bei denen mehr Informationen in die funktionalen Anforderungen aufgenommen werden müssen oder bei denen Fehler in SRS gemacht werden.
Was brauchen wir, um loszulegen?
- Die richtige Version des SRS-Dokuments
- Klare Anweisungen, wer an was arbeiten wird und wie viel Zeit sie haben.
- Eine Vorlage zum Erstellen von Testszenarien.
- Weitere Informationen darüber, an wen Sie sich bei Fragen wenden oder wen Sie bei Inkonsistenzen bei der Dokumentation melden können
Wer würde diese Informationen bereitstellen?
Teamleiter sind im Allgemeinen dafür verantwortlich, alle im obigen Abschnitt aufgeführten Elemente bereitzustellen. Die Beiträge der Teammitglieder sind jedoch immer wichtig für den Erfolg dieses gesamten Unternehmens.
Teamleiter fragen oft: Welche Art von Eingaben? Wäre es nicht besser, ein bestimmtes Modul jemandem zuzuweisen, der daran interessiert ist, als einem Teammitglied, das es nicht ist? Wäre es nicht schön, anhand der Meinung des Teams über das Zieldatum zu entscheiden, als eine Entscheidung zu treffen? Für den Erfolg eines Projekts sind Vorlagen wichtig.
Baumdatenstruktur c ++
Vorlagen weisen in der Regel eine höhere Effizienz auf, wenn sie auf die Bequemlichkeit und den Komfort des jeweiligen Teams zugeschnitten sind. Es sollte daher beachtet werden, dass Teamleiter mehr als alles andere Teammitglieder sind. Die Einbindung Ihres Teams in die täglichen Entscheidungen ist entscheidend für den reibungslosen Ablauf des Projekts.
Ist für Testszenarien eine Vorlage erforderlich?
Warum eine Vorlage für Testszenarien - reicht es nicht aus, wenn wir nur eine Liste erstellen?
Es ist sicher. Softwareprojekte sind jedoch keine Ein-Mann-Shows. Sie beinhalten Zusammenarbeit .
Stellen Sie sich ein 4-köpfiges Team vor, wenn jeder von ihnen beschließt, jeweils ein Modul der Softwareanforderungsspezifikation zu überprüfen. Teammitglied A hat eine Liste auf einem Blatt Papier erstellt. Teammitglied 2 verwendete ein Excel-Blatt. Teammitglied 3 benutzte einen Notizblock. Teammitglied 4 verwendete ein Word-Dokument. Wie konsolidieren wir am Ende des Tages alle für das Projekt geleisteten Arbeiten?
Wie können wir auch entscheiden, welcher der Standard ist und wie können wir sagen, was richtig ist und was nicht, wenn wir die Regeln zunächst nicht erstellt haben?
Das ist die Vorlage: Eine Reihe von Richtlinien und ein vereinbartes Format für Einheitlichkeit und Übereinstimmung für das gesamte Team.
Wie erstelle ich eine Vorlage für QS-Testszenarien?
Vorlagen müssen nicht kompliziert oder unflexibel sein.
Alles, was sie sein müssen, ist ein effizienter Mechanismus, um ein nützliches Testartefakt zu erstellen. Etwas Einfaches wie das, was wir unten sehen:
Die Kopfzeile dieser Vorlage enthält den Speicherplatz, der zum Erfassen grundlegender Informationen zum Projekt, zum aktuellen Dokument und zum referenzierten Dokument erforderlich ist.
In der folgenden Tabelle können wir Testszenarien erstellen. Die enthaltenen Spalten sind:
Spalte 1) ID des Testszenarios
Jede Entität in unserem Testprozess muss eindeutig identifizierbar sein. Daher muss jedem Testszenario eine ID zugewiesen werden. Die Regeln, die beim Zuweisen dieser ID zu beachten sind, müssen definiert werden.
Für diesen Artikel folgen wir der Namenskonvention als TS (Präfix, das für Testszenario steht) gefolgt von '_', Modulname MICH (Mein Info-Modul des Orange HRM-Projekts), gefolgt von '_' und dem Unterabschnitt ( Zum Beispiel, MICH für mein Infomodul, P. für Foto usw.) gefolgt von einer Seriennummer. Ein Beispiel wäre: 'TS_MI_MIM_01'.
Spalte 2) Anforderung
Es ist hilfreich, dass wir beim Erstellen eines Testszenarios in der Lage sein sollten, es dem Abschnitt des SRS-Dokuments zuzuordnen, aus dem wir es ausgewählt haben. Wenn die Anforderungen IDs haben, können wir diese verwenden. Wenn nicht, reichen Abschnittsnummern oder sogar Seitenzahlen des SRS-Dokuments, von dem aus wir eine testbare Anforderung identifiziert haben, aus.
Spalte 3) Beschreibung des Testszenarios
Ein Einzeiler, der angibt, was getestet werden soll. Wir würden es auch als Testziel bezeichnen.
Spalte 4) Bedeutung
Dies soll eine Vorstellung davon geben, wie wichtig bestimmte Funktionen für das AUT sind. Diesem Feld können Werte wie hoch, mittel und niedrig zugewiesen werden. Sie können auch ein Punktesystem wählen, z. B. 1-5, wobei 5 am wichtigsten und 1 weniger wichtig ist. Welchen Wert dieses Feld auch haben kann, es muss im Voraus entschieden werden.
Spalte 5) Anzahl der Testfälle
Eine grobe Schätzung, wie viele einzelne Testfälle wir möglicherweise für dieses eine Testszenario schreiben. Zum Beispiel, Um die Anmeldung zu testen, schließen wir folgende Situationen ein: Korrigieren Sie Benutzername und Passwort. Richtiger Benutzername und falsches Passwort. Richtiges Passwort und falscher Benutzername. Die Überprüfung der Anmeldefunktion führt zu 3 Testfällen.
Hinweis: Sie können diese Vorlage erweitern oder die Felder nach Belieben entfernen.
Zum Beispiel Sie können in der Kopfzeile 'Überprüft von' hinzufügen oder das Erstellungsdatum usw. entfernen. Außerdem können Sie in die Tabelle ein Feld 'Erstellt von' einfügen, um den für ein bestimmtes Testszenario verantwortlichen Tester zu bestimmen, oder die 'Nr.' entfernen. Spalte Testfälle “. Es ist deine Entscheidung. Entscheiden Sie sich für das, was für das gesamte Team am besten funktioniert.
Lassen Sie uns nun unser Orange HRM SRS-Dokument überprüfen und die Testszenarien erstellen
Pro-Tipp: Schauen Sie sich das Inhaltsverzeichnis des SRS-Beispiels an, das wir in den ersten Tutorials bereitgestellt haben, um eine gute Vorstellung davon zu erhalten, wie ein Dokument fließen wird und wie viel Arbeit es bedeuten könnte.Abschnitt 1 ist der Zweck des Dokuments. Keine überprüfbaren Anforderungen dort.
Abschnitt 2.1 : Projektübersicht - Zielgruppe - auch dort keine überprüfbaren Anforderungen.
Abschnitt 2.2 : Hardware und Hosting - In diesem Abschnitt wird erläutert, wie die Orange HRM-Site gehostet wird. Sind diese Informationen für uns Tester wichtig? Die Antwort lautet Ja und Nein. Ja, denn wenn wir testen, müssen wir eine Umgebung haben, die der Echtzeitumgebung ähnlich ist.
Dies gibt uns eine Vorstellung davon, wie es sein muss. Nein, denn es ist keine überprüfbare Anforderung - eine Art Voraussetzung für das Testen.
Sektion 3: Hier gibt es einen Anmeldebildschirm und die Details des Kontotyps, den wir benötigen, um die Site zu betreten. Dies ist eine überprüfbare Anforderung. Es muss also Teil unserer Testszenarien sein.
Weitere Informationen finden Sie im Dokument zu Testszenarien, in dem Testszenarien für einige Abschnitte des SRS hinzugefügt wurden. Fügen Sie zum Üben den Rest der Szenarien auf ähnliche Weise hinzu. Ich gehe jedoch direkt zu Abschnitt 4 des Dokuments.
Sektion 4: Ästhetische / HTML-Anforderungen und Richtlinien - In diesem Abschnitt wird am besten erläutert, wie einige Anforderungen für das Testteam zum Zeitpunkt der SRS-Überprüfung möglicherweise nicht sinnvoll sind. Das Team sollte sie jedoch trotzdem als testbare Anforderungen notieren.
Wie man sie testet und ob wir bestimmte Einstellungen / die Hilfe eines Teams benötigen, um sie zu validieren, sind Details, die wir zu diesem Zeitpunkt möglicherweise nicht kennen. Sie zu einem Teil unseres Testumfangs zu machen, ist der erste Schritt, um sicherzustellen, dass wir sie nicht verpassen.
Beispieltestszenarien für die OrangeHRM-Anwendung:: (Klicken, um das Bild zu vergrößern)
=> Bitte beziehen Sie sich und Laden Sie das Dokument Testszenarien herunter für mehr Informationen.
Einige wichtige Bemerkungen zur SRS-Überprüfung
# 1) Es dürfen keine Informationen offen gelassen werden.
#zwei) Führen Sie eine Machbarkeitsanalyse durch, um festzustellen, ob eine bestimmte Anforderung korrekt ist oder nicht und ob sie getestet werden kann oder nicht.
#3) Sofern keine separate Leistung / Sicherheit oder eine andere Form von Testteams vorhanden ist, ist es unsere Aufgabe, sicherzustellen, dass alle nicht funktionierenden Anforderungen berücksichtigt werden müssen.
# 4) Nicht alle Informationen richten sich an die Tester, daher ist es wichtig zu verstehen, was zu beachten ist und was nicht.
# 5) Die Wichtigkeit und nein. Die Anzahl der Testfälle für ein Testszenario muss nicht genau sein und kann mit einem ungefähren Wert ausgefüllt oder leer gelassen werden.
Zusammenfassend ergibt die SRS-Überprüfung folgende Ergebnisse:
- Liste der Testszenarien
- Überprüfungsergebnisse - Dokumentations- / Anforderungsfehler, die durch statisches Durchlaufen / Überprüfen des SRS-Dokuments festgestellt wurden
- Eine Liste mit Fragen zum besseren Verständnis - falls vorhanden
- Die vorläufige Vorstellung davon, wie die Testumgebung aussehen soll
- Identifizierung des Testumfangs und eine ungefähre Vorstellung davon, wie viele Testfälle wir möglicherweise haben - also wie viel Zeit wir für die Dokumentation und eventuelle Ausführung benötigen.
Wichtige Punkte zu beachten:
# 1) Testszenarien sind keine externen Ergebnisse (nicht für Business Analysten oder Entwicklerteams freigegeben), sondern wichtig für den internen QS-Verbrauch. Sie sind unser erster Schritt in Richtung eines 100% igen Ziels für die Testabdeckung. Sobald die Testszenarien abgeschlossen sind, werden sie einer Peer Review unterzogen. Anschließend werden alle konsolidiert.
Weitere Informationen zur Überprüfung von QS-Dokumenten finden Sie im Artikel: Durchführen von Überprüfungen der Testdokumentation in 6 einfachen Schritten.
#zwei) Wir könnten ein Testmanagement-Tool wie verwenden HP ALM oder qTest um die Testszenarien zu erstellen. Die Erstellung von Testszenarien in Echtzeit ist jedoch eine manuelle Aktivität. Meiner Meinung nach ist es manuell bequemer. Da es Schritt 1 ist, müssen wir die großen Waffen noch nicht herausbringen. Einfache Excel-Tabellen sind der beste Weg, dies zu tun.
Der nächste Schritt zu dieser Serie ist das - Wir werden an der Erstellung von Testfällen arbeiten und weiter in die Testdesignphase einsteigen. Vorher werden wir uns auch mit - Was ist Testplanung?Wo passt es in das gesamte QS-Projekt? Arbeiten Sie wie immer mit uns zusammen, um die besten Ergebnisse zu erzielen.
Was bedeutet Netzwerksicherheitsschlüssel?
QA Training Tag 3: So schreiben Sie ein SRS-Dokument von Grund auf neu.
Bitte halten Sie Ihre Fragen und Kommentare kommen. Wir schätzen Ihre Leserschaft sehr!
Literatur-Empfehlungen
- Lehrplan für Softwaretests - Detaillierter Schulungsplan für Online-Kurse
- Softwaretestkurs: An welchem Softwaretestinstitut soll ich teilnehmen?
- Softwaretest-Training: End-to-End-Training in einem Live-Projekt - Kostenloses Online-QS-Training Teil 1
- Beste Software-Test-Tools 2021 [QA Test Automation Tools]
- Feedback und Bewertungen zum Softwaretestkurs
- Häufig gestellte Fragen zum QA-Schulungskurs für Softwaretests
- Ressourcen und Downloads zum Testen von QS-Software
- QA-Outsourcing-Leitfaden: Software-Test-Outsourcing-Unternehmen