how create requirements traceability matrix
Was ist die Anforderungsrückverfolgbarkeitsmatrix (RTM) beim Testen von Software: Schrittweise Anleitung zum Erstellen der Rückverfolgbarkeitsmatrix mit Beispielen und Beispielvorlage
Das heutige Tutorial befasst sich mit einem wichtigen QC-Tool, das entweder zu stark vereinfacht (übersehen) oder zu stark betont wird - d. H. Rückverfolgbarkeitsmatrix (TM).
In den meisten Fällen gehört das Erstellen, Überprüfen oder Teilen einer Rückverfolgbarkeitsmatrix nicht zu den primären Ergebnissen des QS-Prozesses. Daher wird das Hauptaugenmerk nicht auf das Ergebnis gelegt, sodass die Unterbetonung nicht wesentlich ist. Im Gegenteil, einige Kunden erwarten, dass ein TM erderschütternde Facetten ihres Produkts (im Test) enthüllt, und sind enttäuscht.
„Bei richtiger Anwendung kann eine Rückverfolgbarkeitsmatrix Ihr GPS für Ihre QS-Reise sein.“
Da ist eine allgemeine Praxis bei STH In diesem Artikel werden die Aspekte „Was“ und „Wie“ eines TM beschrieben.
Was du lernen wirst:
- Was ist die Anforderungsrückverfolgbarkeitsmatrix?
- Testabdeckung und Rückverfolgbarkeit der Anforderungen
- So erstellen Sie eine Anforderungsrückverfolgbarkeitsmatrix
Was ist die Anforderungsrückverfolgbarkeitsmatrix?
In der Requirement Traceability Matrix oder RTM haben wir einen Prozess zum Dokumentieren der Verknüpfungen zwischen den vom Client vorgeschlagenen Benutzeranforderungen und dem zu erstellenden System eingerichtet. Kurz gesagt, es handelt sich um ein Dokument auf hoher Ebene, mit dem Benutzeranforderungen anhand von Testfällen zugeordnet und nachverfolgt werden können, um sicherzustellen, dass für jede Anforderung ein angemessenes Testniveau erreicht wird.
Der Prozess zum Überprüfen aller Testfälle, die für eine Anforderung definiert sind, wird als Rückverfolgbarkeit bezeichnet. Durch die Rückverfolgbarkeit können wir feststellen, welche Anforderungen während des Testprozesses die meisten Fehler verursacht haben.
Der Fokus jedes Testauftrags liegt und sollte auf maximaler Testabdeckung liegen. Unter Abdeckung versteht man einfach, dass wir alles testen müssen, was getestet werden soll. Das Ziel eines Testprojekts sollte eine 100% ige Testabdeckung sein.
Die Anforderungsrückverfolgbarkeitsmatrix bietet eine Möglichkeit, um sicherzustellen, dass der Deckungsaspekt überprüft wird. Es hilft beim Erstellen eines Schnappschusses, um Abdeckungslücken zu identifizieren. Kurz gesagt, es kann auch als Metrik bezeichnet werden, die die Anzahl der Testfälle Run, Passed, Failed oder Blocked usw. für jede Anforderung bestimmt.
Warum ist eine Rückverfolgbarkeit der Anforderungen erforderlich?
Die Matrix zur Rückverfolgbarkeit von Anforderungen hilft bei der Verknüpfung der Anforderungen. Testfälle und Mängel genau. Die gesamte Anwendung wird durch Anforderungsverfolgbarkeit getestet ( End-to-End-Tests einer Anwendung erreicht wird).
wie man einen Penetrationstest macht
Die Rückverfolgbarkeit der Anforderungen gewährleistet eine gute „Qualität“ der Anwendung, da alle Funktionen getestet werden. Qualitätskontrolle kann erreicht werden, wenn Software auf unvorhergesehene Szenarien mit minimalen Fehlern getestet wird und alle funktionalen und nicht funktionalen Anforderungen erfüllt werden.
Die Anforderungsrückverfolgbarkeitsmatrix hilft bei der Prüfung von Softwareanwendungen in der festgelegten Zeitdauer, der Umfang des Projekts ist genau festgelegt und die Implementierung erfolgt gemäß den Kundenanforderungen und -bedürfnissen, und die Kosten des Projekts werden gut kontrolliert.
Fehlerlecks werden verhindert, da die gesamte Anwendung auf ihre Anforderungen geprüft wird.
Arten der Rückverfolgbarkeitsmatrix
Rückverfolgbarkeit vorwärts
In 'Vorwärtsrückverfolgbarkeit' Anforderungen an die Testfälle. Es stellt sicher, dass das Projekt gemäß der gewünschten Richtung fortschreitet und dass jede Anforderung gründlich getestet wird.
Rückverfolgbarkeit
Die Testfälle sind den Anforderungen in „Rückverfolgbarkeit“ zugeordnet. Hauptzweck ist es sicherzustellen, dass das aktuell entwickelte Produkt auf dem richtigen Weg ist. Es hilft auch festzustellen, dass keine zusätzlichen nicht spezifizierten Funktionen hinzugefügt werden und somit der Umfang des Projekts beeinflusst wird.
Bidirektionale Rückverfolgbarkeit
(Vorwärts + Rückwärts): Eine Matrix für gute Rückverfolgbarkeit enthält Verweise von Testfällen auf Anforderungen und umgekehrt (Anforderungen an Testfälle). Dies wird als 'bidirektionale' Rückverfolgbarkeit bezeichnet. Es stellt sicher, dass alle Testfälle auf Anforderungen zurückgeführt werden können und jede angegebene Anforderung genaue und gültige Testfälle enthält.
Beispiele für RTM
# 1) Geschäftsanforderung
BR1 : Die Option zum Schreiben von E-Mails sollte verfügbar sein.
Testszenario (technische Spezifikation) für BR1
TS1 : Die Option zum Verfassen von E-Mails ist verfügbar.
Testfälle:
Testfall 1 (TS1.TC1) : Die Option zum Verfassen von E-Mails ist aktiviert und funktioniert erfolgreich.
Testfall 2 (TS1.TC2) : Die Option zum Verfassen von E-Mails ist deaktiviert.
# 2) Mängel
Wenn nach der Ausführung der Testfälle Fehler festgestellt werden, die ebenfalls aufgelistet und den Geschäftsanforderungen, Testszenarien und Testfällen zugeordnet werden können.
Zum Beispiel, Wenn TS1.TC1 fehlschlägt, d. H. Die Option 'E-Mail verfassen', obwohl aktiviert, funktioniert nicht ordnungsgemäß, kann ein Fehler protokolliert werden. Angenommen, die automatisch generierte oder manuell zugewiesene Fehler-ID lautet D01, dann kann dies den Nummern BR1, TS1 und TS1.TC1 zugeordnet werden.
Somit können alle Anforderungen in einem Tabellenformat dargestellt werden.
| Geschäftsanforderung # | Testszenario # | Testfall # | Mängel # |
|---|---|---|---|
| BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
| BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
| BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | NULL |
Testabdeckung und Rückverfolgbarkeit der Anforderungen
Was ist Testabdeckung?
Die Testabdeckung gibt an, welche Anforderungen der Kunden zu Beginn der Testphase überprüft werden sollen. Testabdeckung ist ein Begriff, der bestimmt, ob die Testfälle geschrieben und ausgeführt werden, um sicherzustellen, dass die Softwareanwendung vollständig getestet wird, sodass minimale oder NIL-Fehler gemeldet werden.
Wie erreicht man eine Testabdeckung?
Die maximale Testabdeckung kann erreicht werden, indem eine gute „Rückverfolgbarkeit der Anforderungen“ festgelegt wird.
- Abbildung aller internen Fehler auf die entworfenen Testfälle
- Zuordnung aller vom Kunden gemeldeten Fehler (Customer Reported Defects, CRD) zu einzelnen Testfällen für die zukünftige Regressionstestsuite
Arten von Anforderungsspezifikationen
# 1) Geschäftsanforderungen
Die tatsächlichen Kundenanforderungen sind in einem Dokument aufgeführt, das als bekannt ist Geschäftsanforderungsdokument (BRS) . Diese BRS ist nach einer kurzen Interaktion mit dem Kunden eine minutiös abgeleitete übergeordnete Anforderungsliste.
Es wird normalerweise von „Business Analysts“ oder dem Projekt „Architect“ erstellt (je nach Organisation oder Projektstruktur). Das Dokument „Software Requirement Specifications“ (SRS) stammt von BRS.
# 2) Software Requirements Specification Document (SRS)
Es ist ein detailliertes Dokument, das alle genauen Details aller funktionalen und nicht funktionalen Anforderungen enthält. Dieser SRS ist die Basis für das Entwerfen und Entwickeln von Softwareanwendungen.
# 3) Projektanforderungsdokumente (PRD)
Die PRD ist ein Referenzdokument für alle Teammitglieder in einem Projekt, um ihnen genau zu sagen, was ein Produkt tun soll. Es kann in Abschnitte wie Zweck des Produkts, Produktmerkmale, Freigabekriterien und Budgetierung und Zeitplan des Projekts unterteilt werden.
# 4) Anwendungsfalldokument
Es ist das Dokument, das beim Entwerfen und Implementieren der Software gemäß den Geschäftsanforderungen hilft. Es bildet die Interaktionen zwischen einem Akteur und einem Ereignis mit einer Rolle ab, die ausgeführt werden muss, um ein Ziel zu erreichen. Es ist eine detaillierte schrittweise Beschreibung, wie eine Aufgabe ausgeführt werden muss.
Zum Beispiel,
Darsteller: Kunde
Rolle: Spiel herunterladen
Der Download des Spiels ist erfolgreich.
Anwendungsfälle können gemäß dem Arbeitsprozess der Organisation auch Teil des SRS-Dokuments sein.
# 5) Fehlerüberprüfungsdokument
Es ist dokumentiert und enthält alle Einzelheiten zu Mängeln. Das Team kann ein Dokument zur Fehlerüberprüfung führen, um die Fehler zu beheben und erneut zu testen. Die Tester können auf das Dokument 'Fehlerüberprüfung' verweisen, wenn sie überprüfen möchten, ob die Fehler behoben sind oder nicht, Fehler auf verschiedenen Betriebssystemen, Geräten, verschiedenen Systemkonfigurationen usw. erneut testen möchten.
Das Dokument „Fehlerüberprüfung“ ist praktisch und wichtig, wenn eine spezielle Phase zur Fehlerbehebung und -überprüfung vorhanden ist.
# 6) User Stories
Die User Story wird hauptsächlich in der „Agile“ -Entwicklung verwendet, um eine Softwarefunktion aus der Sicht des Endbenutzers zu beschreiben. User Stories definieren die Benutzertypen und auf welche Weise und warum sie eine bestimmte Funktion wünschen. Die Anforderung wird durch das Erstellen von User Stories vereinfacht.
Derzeit setzen alle Softwareindustrien auf User Stories und Agile Development sowie entsprechende Softwaretools zur Erfassung der Anforderungen.
Herausforderungen für die Anforderungserfassung
# 1) Die gesammelten Anforderungen müssen detailliert, eindeutig, genau und genau spezifiziert sein. Aber da ist UNTERLASSEN SIE geeignete Maßnahme zur Berechnung dieser Details, Eindeutigkeit, Genauigkeit und genau definierte Spezifikationen, die für die Anforderungserfassung erforderlich sind.
#zwei) Die Interpretation des „Business Analyst“ oder „Product Owner“, der die Anforderungsinformationen bereitstellt, ist von entscheidender Bedeutung. Ebenso muss das Team, das die Informationen erhält, entsprechende Klarstellungen vornehmen, um die Erwartungen der Stakeholder zu verstehen.
Das Verständnis muss sowohl mit den Geschäftsanforderungen als auch mit den tatsächlichen Anstrengungen für die Anwendungsimplementierung übereinstimmen.
#3) Die Informationen sollten auch aus Sicht des Endbenutzers abgeleitet werden.
# 4) Der Zustand der Interessengruppen widerspricht oder widerspricht den Anforderungen zu unterschiedlichen Zeiten.
# 5) Die Sichtweise des Endbenutzers wird aus mehreren Gründen nicht berücksichtigt, und weitere Interessengruppen sind der Ansicht, dass sie „vollständig“ verstehen, was für ein Produkt erforderlich ist, was im Allgemeinen nicht der Fall ist.
# 6) Ressourcen mangelnde Fähigkeiten für die Anwendung entwickelt.
# 7) Häufige Änderungen des Anwendungsbereichs oder der Priorität für Module.
# 8) Fehlende, implizite oder nicht dokumentierte Anforderungen.
# 9) Von den Kunden festgelegte inkonsistente oder vage Anforderungen.
# 10) Die Schlussfolgerung aller oben genannten Faktoren lautet, dass der „Erfolg“ oder „Misserfolg“ eines Projekts erheblich von einer Anforderung abhängt.
Wie die Rückverfolgbarkeit von Anforderungen helfen kann
# 1) Wo wird eine Anforderung implementiert?
Zum Beispiel,
c ++ Zeichen zu Zeichenfolge
Anforderung: Implementieren Sie die Funktion 'E-Mail verfassen' in einer E-Mail-Anwendung.
Implementierung: Wo auf der Hauptseite die Schaltfläche 'E-Mail verfassen' platziert und aufgerufen werden soll.
# 2) Ist eine Anforderung notwendig?
Zum Beispiel,
Anforderung: Implementieren Sie die Funktion 'E-Mail verfassen' in einer E-Mail-Anwendung nur für bestimmte Benutzer.
Implementierung: Laut Benutzerzugriffsrechten ist in diesem Fall die Schaltfläche 'E-Mail verfassen' nicht erforderlich, wenn der E-Mail-Posteingang schreibgeschützt ist.
# 3) Wie interpretiere ich eine Anforderung?
Zum Beispiel,
Anforderung: Funktion 'E-Mail verfassen' in einer E-Mail-Anwendung mit Schriftarten und Anhängen.
Implementierung: Wenn Sie auf 'E-Mail verfassen' klicken, welche Funktionen sollten bereitgestellt werden?
- Textkörper zum Schreiben und Bearbeiten von E-Mails in verschiedenen Schriftarten sowie fett und kursiv unterstrichen
- Arten von Anhängen (Bilder, Dokumente, andere E-Mails usw.)
- Größe der Anhänge (maximal zulässige Größe)
Somit werden die Anforderungen in Unteranforderungen unterteilt.
# 4) Welche Entwurfsentscheidungen wirken sich auf die Umsetzung einer Anforderung aus?
Zum Beispiel,
Anforderung: Alle Elemente 'Posteingang', 'E-Mail gesendet', 'Entwürfe', 'Spam', 'Papierkorb' usw. sollten deutlich sichtbar sein.
Implementierung: Die Elemente, die sichtbar sein sollen, sollten im Format 'Baum' oder 'Tab' angezeigt werden.
# 5) Sind alle Anforderungen zugeordnet?
Zum Beispiel,
Anforderung: Die E-Mail-Option 'Papierkorb' wird bereitgestellt.
Implementierung: Wenn die E-Mail-Option 'Papierkorb' bereitgestellt wurde, muss die Option 'E-Mails löschen' (Anforderung) zunächst implementiert werden und sollte korrekt funktionieren. Wenn die E-Mail-Option 'Löschen' ordnungsgemäß funktioniert, werden nur die gelöschten E-Mails in 'Papierkorb' gesammelt, und die Implementierung der E-Mail-Option 'Papierkorb' (Anforderung) ist sinnvoll (nützlich).
Vorteile von RTM und Testabdeckung
# 1) Der entwickelte und getestete Build verfügt über die erforderliche Funktionalität, die den Anforderungen und Erwartungen der Kunden / Benutzer entspricht. Der Kunde muss bekommen, was er will. Den Kunden mit einer Anwendung zu überraschen, die nicht das tut, was erwartet wird, ist für niemanden eine zufriedenstellende Erfahrung.
#zwei) Das Endprodukt (Softwareanwendung), das entwickelt und an den Kunden geliefert wird, darf nur die Funktionen umfassen, die benötigt und erwartet werden. Zusätzliche Funktionen, die in der Softwareanwendung bereitgestellt werden, können zunächst attraktiv erscheinen, bis Zeit, Geld und Aufwand für die Entwicklung anfallen.
Die zusätzliche Funktion kann auch zu einer Fehlerquelle werden, die nach der Installation zu Problemen für einen Kunden führen kann.
#3) Die anfängliche Aufgabe des Entwicklers wird klar definiert, da er zuerst an der Implementierung der Anforderungen arbeitet, die gemäß den Kundenanforderungen von hoher Priorität sind. Wenn die Anforderungen des Kunden mit hoher Priorität klar festgelegt sind, können diese Codekomponenten mit erster Priorität entwickelt und implementiert werden.
Somit ist sichergestellt, dass die Chancen, dass das Endprodukt an den Kunden versendet wird, den höchsten Anforderungen entsprechen und im Zeitplan liegen.
# 4) Tester überprüfen zunächst die wichtigsten von Entwicklern implementierten Funktionen. Da zuerst die Überprüfung (Testen) der Prioritätssoftwarekomponente durchgeführt wird, können Sie feststellen, wann und ob die ersten Versionen des Systems zur Veröffentlichung bereit sind.
# 5) Genaue Testpläne, Testfälle werden geschrieben und ausgeführt, die überprüfen, ob alle Anwendungsanforderungen korrekt implementiert sind. Durch die Zuordnung von Testfällen zu den Anforderungen wird sichergestellt, dass keine größeren Fehler übersehen werden. Es hilft außerdem bei der Implementierung eines Qualitätsprodukts gemäß den Kundenerwartungen.
# 6) Falls vom Client eine Änderungsanforderung vorliegt, werden alle Anwendungskomponenten, die von der Änderungsanforderung betroffen sind, geändert und nichts wird übersehen. Dies verbessert die Bewertung der Auswirkungen einer Änderungsanforderung auf die Softwareanwendung weiter.
# 7) Eine scheinbar einfache Änderungsanforderung kann Änderungen beinhalten, die an mehreren Teilen der Anwendung vorgenommen werden müssen. Es ist besser, eine Schlussfolgerung darüber abzuleiten, wie viel Aufwand erforderlich sein wird, bevor Sie der Änderung zustimmen.
Herausforderungen bei der Testabdeckung
# 1) Guter Kommunikationskanal
Wenn es irgendwelche Änderungen gibt, die von der vorgeschlagen werden Interessengruppen Dies muss den Entwicklungs- und Testteams in den früheren Entwicklungsphasen mitgeteilt werden. Ohne das pünktlich Die Entwicklung, Prüfung der Anwendung und Erfassung / Behebung von Mängeln kann nicht gewährleistet werden.
# 2) Die Priorisierung der Testszenarien ist wichtig
Es ist eine schwierige Aufgabe, herauszufinden, welche Testszenarien mit hoher Priorität, komplex und wichtig sind. Ich versuche alle zu testen Testszenarien ist fast eine unerreichbare Aufgabe. Das Ziel, die Szenarien zu testen, muss aus geschäftlicher und Endbenutzersicht sehr klar sein.
# 3) Prozessimplementierung
Der Testprozess muss klar definiert sein und Faktoren wie technische Infrastruktur und Implementierungen, Teamfähigkeiten, Erfahrungen aus der Vergangenheit, Organisationsstrukturen und -prozesse, Projektschätzungen in Bezug auf Kosten, Zeit und Ressourcen sowie den Standort des Teams gemäß den Zeitzonen berücksichtigen.
Eine einheitliche Prozessimplementierung unter Berücksichtigung der genannten Faktoren stellt sicher, dass sich alle mit dem Projekt befassten Personen auf derselben Seite befinden. Dies trägt zu einem reibungslosen Ablauf aller Prozesse im Zusammenhang mit der Anwendungsentwicklung bei.
# 4) Verfügbarkeit von Ressourcen
Es gibt zwei Arten von Ressourcen: fachspezifische Tester und die von den Testern verwendeten Testwerkzeuge. Wenn die Tester über ausreichende Kenntnisse der Domäne verfügen, können sie effektive Testszenarien und Skripte schreiben und implementieren. Um diese Szenarien und Skripte zu implementieren, sollten die Tester mit geeigneten „Test-Tools“ ausgestattet sein.
Eine gute Implementierung und pünktliche Lieferung der Anwendung an den Kunden kann durch den einzigen qualifizierten Tester und geeignete Testwerkzeuge sichergestellt werden.
# 5) Effektive Implementierung der Teststrategie
' Teststrategie “an sich ist ein großes und eigenständiges Diskussionsthema. Aber hier für 'Test Coverage' stellt eine effektive Implementierung der Teststrategie sicher, dass die ' Qualität' der Anwendung ist gut und es ist gepflegt im Laufe der Zeit überall.
Eine effektive „Teststrategie“ spielt eine wichtige Rolle bei der Vorausplanung aller Arten kritischer Herausforderungen, was bei der Entwicklung einer besseren Anwendung weiter hilft.
So erstellen Sie eine Anforderungsrückverfolgbarkeitsmatrix
Um mit uns zusammen zu sein, müssen wir genau wissen, was verfolgt oder verfolgt werden muss.
Tester beginnen mit dem Schreiben ihrer Testszenarien / -ziele und schließlich der Testfälle auf der Grundlage einiger Eingabedokumente - Dokument mit Geschäftsanforderungen, Dokument mit den Funktionsspezifikationen und technisches Designdokument (optional).
Nehmen wir an, das Folgende ist unser Business Requirements Document (BRD): ( Laden Sie dieses BRD-Beispiel im Excel-Format herunter )
(Klicken Sie auf ein Bild, um es zu vergrößern)
Sortierbefehl unter Unix mit Beispiel
Nachfolgend finden Sie unser Dokument mit funktionalen Spezifikationen (FSD), das auf der Interpretation des Business Requirements Document (BRD) und dessen Anpassung an Computeranwendungen basiert. Im Idealfall müssen alle Aspekte der FSD in der BRD behandelt werden. Der Einfachheit halber habe ich nur die Punkte 1 und 2 verwendet.
Beispiel FSD von oben BRD: ( Laden Sie dieses Beispiel-FSD im Excel-Format herunter )
Hinweis : BRD und FSD werden von QS-Teams nicht dokumentiert. Wir sind nur die Verbraucher der Dokumente zusammen mit den anderen Projektteams.
Basierend auf den beiden oben genannten Eingabedokumenten haben wir als QS-Team die folgende Liste von Szenarien auf hoher Ebene erstellt, die wir testen können.
Beispieltestszenarien aus der obigen BRD und FSD: ( Laden Sie diese Beispieldatei für Testszenarien herunter )
Sobald wir hier angekommen sind, ist jetzt ein guter Zeitpunkt, um mit der Erstellung der Anforderungsrückverfolgbarkeitsmatrix zu beginnen.
Ich persönlich bevorzuge ein sehr einfaches Excel-Blatt mit Spalten für jedes Dokument, das wir verfolgen möchten. Da die Geschäftsanforderungen und funktionalen Anforderungen nicht eindeutig nummeriert sind, werden wir die Abschnittsnummern im Dokument zur Verfolgung verwenden.
(Sie können wählen, ob Sie anhand von Zeilennummern oder Aufzählungszeichen usw. verfolgen möchten, je nachdem, was für Ihren Fall besonders sinnvoll ist.)
So würde eine einfache Rückverfolgbarkeitsmatrix für unser Beispiel aussehen:
Das obige Dokument erstellt eine Ablaufverfolgung zwischen BRD und FSD und schließlich zwischen den Testszenarien. Durch die Erstellung eines solchen Dokuments können wir sicherstellen, dass alle Aspekte der ursprünglichen Anforderungen vom Testteam bei der Erstellung ihrer Testsuiten berücksichtigt wurden.
Sie können es so lassen. Um die Lesbarkeit zu verbessern, ziehe ich es jedoch vor, die Abschnittsnamen einzuschließen. Dies verbessert das Verständnis, wenn dieses Dokument für den Kunden oder ein anderes Team freigegeben wird.
Das Ergebnis ist wie folgt:
Auch hier liegt die Wahl zwischen dem früheren oder dem späteren Format.
Dies ist die vorläufige Version Ihres TM, erfüllt jedoch im Allgemeinen nicht ihren Zweck, wenn Sie hier anhalten. Der maximale Nutzen kann daraus gezogen werden, wenn Sie ihn bis hin zu Fehlern extrapolieren.
Mal sehen, wie.
Für jedes Testszenario, das Sie erstellt haben, stehen mindestens ein oder mehrere Testfälle zur Verfügung. Fügen Sie also eine weitere Spalte hinzu, wenn Sie dort ankommen, und schreiben Sie die Testfall-IDs wie unten gezeigt:
In dieser Phase kann die Rückverfolgbarkeitsmatrix verwendet werden, um Lücken zu finden. Zum Beispiel, In der obigen Rückverfolgbarkeitsmatrix sehen Sie, dass für FSD Abschnitt 1.2 keine Testfälle geschrieben wurden.
In der Regel sind leere Stellen in der Rückverfolgbarkeitsmatrix potenzielle Untersuchungsbereiche. Eine solche Lücke kann also eines der beiden Dinge bedeuten:
- Das Testteam hat es irgendwie versäumt, die Funktionalität 'Bestehender Benutzer' zu berücksichtigen.
- Die Funktionalität 'Bestehender Benutzer' wurde auf einen späteren Zeitpunkt verschoben oder aus den Funktionsanforderungen der Anwendung entfernt. In diesem Fall weist das TM eine Inkonsistenz in der FSD oder BRD auf. Dies bedeutet, dass eine Aktualisierung der FSD- und / oder BRD-Dokumente durchgeführt werden sollte.
Wenn es sich um Szenario 1 handelt, werden die Stellen angegeben, an denen das Testteam noch etwas arbeiten muss, um eine 100% ige Abdeckung sicherzustellen.
In Szenario 2 zeigt TM nicht nur Lücken, sondern weist auch auf eine falsche Dokumentation hin, die sofort korrigiert werden muss.
Erweitern wir nun das TM um den Status und die Fehler der Testfallausführung.
Die folgende Version der Rückverfolgbarkeitsmatrix wird im Allgemeinen während oder nach der Testausführung erstellt:
Vorlage für die Rückverfolgbarkeitsmatrix für Anforderungen herunterladen:
=> Rückverfolgbarkeitsmatrixvorlage im Excel-Format
Wichtige Punkte zu beachten
Die folgenden wichtigen Punkte sind bei dieser Version der Rückverfolgbarkeitsmatrix zu beachten:
# 1) Der Ausführungsstatus wird ebenfalls angezeigt. Während der Ausführung wird eine konsolidierte Momentaufnahme des Arbeitsfortschritts erstellt.
# 2) Mängel: Wenn diese Spalte zum Festlegen der Rückverfolgbarkeit verwendet wird, können wir feststellen, dass die Funktion 'Neuer Benutzer' am fehlerhaftesten ist. Anstatt zu melden, dass so und so Testfälle fehlgeschlagen sind, bietet TM Transparenz zurück zu den Geschäftsanforderungen, die die meisten Mängel aufweisen, und zeigt so die Qualität in Bezug auf die Wünsche des Kunden.
#3) Als weiteren Schritt können Sie die Fehler-ID farblich kennzeichnen, um ihre Zustände darzustellen. Zum Beispiel, Fehler-ID in Rot kann bedeuten, dass es noch offen ist, in Grün kann bedeuten, dass es geschlossen ist. In diesem Fall fungiert das TM als Integritätsprüfungsbericht, in dem der Status der Fehler angezeigt wird, die einer bestimmten BRD- oder FSD-Funktionalität entsprechen, die geöffnet oder geschlossen wird.
# 4) Wenn es ein technisches Designdokument oder Anwendungsfälle oder andere Artefakte gibt, die Sie verfolgen möchten, können Sie das oben erstellte Dokument jederzeit erweitern, indem Sie zusätzliche Spalten hinzufügen.
Zusammenfassend hilft RTM bei:
- Sicherstellung einer 100% igen Testabdeckung
- Anzeigen von Anforderungs- / Dokumentinkonsistenzen
- Anzeige des gesamten Fehler- / Ausführungsstatus mit Schwerpunkt auf Geschäftsanforderungen.
- Wenn sich eine bestimmte geschäftliche und / oder funktionale Anforderung ändern sollte, hilft ein TM dabei, die Auswirkungen auf die Arbeit des QA-Teams im Hinblick auf die Überprüfung / Überarbeitung der Testfälle abzuschätzen oder zu analysieren.
Zusätzlich,
- Eine Rückverfolgbarkeitsmatrix ist kein spezifisches Tool für manuelle Tests, sondern kann auch für Automatisierungsprojekte verwendet werden. Bei einem Automatisierungsprojekt kann die Testfall-ID den Namen des Automatisierungstestskripts angeben.
- Es ist auch kein Tool, das nur von den QAs verwendet werden kann. Das Entwicklungsteam kann auf dieselbe Weise BRD / FSD-Anforderungen auf Blöcke / Einheiten / Bedingungen des erstellten Codes abbilden, um sicherzustellen, dass alle Anforderungen entwickelt werden.
- Test Management Tools wie HP ALM kommen mit der eingebauten Rückverfolgbarkeitsfunktion.
Ein wichtiger Punkt ist, dassDie Art und Weise, wie Sie Ihre Rückverfolgbarkeitsmatrix pflegen und aktualisieren, bestimmt die Effektivität ihrer Verwendung. Wenn das Tool nicht häufig oder falsch aktualisiert wird, ist es eine Belastung, anstatt eine Hilfe zu sein, und es entsteht der Eindruck, dass das Tool selbst nicht die Verwendung wert ist.
Fazit
Anforderungsrückverfolgbarkeitsmatrix ist das Mittel dazu Karte und Spur alle Anforderungen des Kunden mit den Testfällen und entdeckten Mängeln. Es ist ein einzelnes Dokument Dies dient dem Hauptzweck, dass keine Testfälle übersehen werden und somit jede Funktionalität der Anwendung abgedeckt und getestet wird.
Eine im Voraus geplante gute „Testabdeckung“ verhindert sich wiederholende Aufgaben in Testphasen und Fehlerlecks. Eine hohe Fehlerzahl zeigt an, dass die Tests gut durchgeführt wurden und daher die „Qualität“ der Anwendung steigt. In ähnlicher Weise weist eine sehr niedrige Fehlerzahl darauf hin, dass die Prüfung nicht bis zur Marke durchgeführt wird, was die „Qualität“ der Anwendung negativ beeinflusst.
Wenn die Testabdeckung gründlich durchgeführt wird, kann eine niedrige Fehleranzahl gerechtfertigt werden, und diese Fehleranzahl kann als unterstützende Statistik und nicht als primäre angesehen werden. Die Qualität einer Anwendung wird als 'gut' oder 'zufriedenstellend' bezeichnet, wenn die Testabdeckung maximiert und die Anzahl der Fehler minimiert wird.
Über den Autor: STH-Teammitglied Urmila P. ist eine erfahrene QS-Fachkraft mit hohe Qualität Test- und Issue-Tracking-Fähigkeiten.
Haben Sie in Ihren Projekten eine Anforderungsrückverfolgbarkeitsmatrix erstellt? Wie ähnlich oder verschieden ist es von dem, was wir in diesem Artikel erstellt haben? Bitte teilen Sie Ihre Erfahrungen, Kommentare, Gedanken und Rückmeldungen zu diesem Artikel durch Ihre Kommentare.
Literatur-Empfehlungen
- Beispiel für eine Software-Testplanvorlage mit Format und Inhalt
- So schreiben Sie einen effektiven Testzusammenfassungsbericht (Beispielbericht herunterladen)
- Beispiel für eine Testfallvorlage mit Testfallbeispielen (Download)
- Beispielvorlage für einen Abnahmetestbericht mit Beispielen
- So schreiben Sie ein Teststrategiedokument (mit Beispielvorlage für eine Teststrategie)
- Wie teste ich die Software Requirements Specification (SRS)?
- Top 20+ Best Requirements Management Tools (Die vollständige Liste)
- Die Checklisten für QA-Softwaretests (Beispiel-Checklisten enthalten)