Rückverfolgbarkeitsmatrix

Wenn sich die Anforderungen an ein Projekt „on the fly“ ändern und Sie nicht über die Mittel verfügen, um die Implementierung jeder einzelnen Anforderung nach Feature oder Modul zu überwachen, stellt sich die Frage: Wie kann die Abdeckung analysiert werden? Eines der Tools, die unser QS-Team für solche Projekte verwendet, ist die Rückverfolgbarkeitsmatrix.

Im Moment verwenden wir Matrizen seit mehr als 2,5 Jahren. In dieser Zeit konnten wir die Vorteile dieses Tools bewerten und an unser Projekt anpassen.

Was ist eine Rückverfolgbarkeitsmatrix?

Per Definition ist die Rückverfolgbarkeitsmatrix eine zweidimensionale Tabelle, die die Übereinstimmung der funktionalen Anforderungen des Produkts (funktionale Anforderungen) und der vorbereiteten Testfälle (Testfälle) enthält.

Am Schnittpunkt der entsprechenden Zeile und Spalte wird eine Markierung angebracht, die angibt, dass diese Anforderung von diesem Testfall abgedeckt wird.

Somit bietet die Tabelle eine visuelle Anzeige von zwei Parametern:

• das Vorhandensein von Anforderungen im System, die noch nicht abgedeckt sind (wenn die Anforderung keinen einzigen Schnittpunkt mit Testfällen aufweist (ausreichende Bedingung);
• Gibt es übermäßige Tests im System - wenn die Anforderungen mehrere Schnittpunkte haben (eine notwendige Bedingung).

In unserem Projekt verwenden wir Rückverfolgbarkeitsmatrizen nicht nur zur Bewertung der Abdeckung, sondern auch zur Bestimmung der Beziehung zwischen Entwicklungsaufgaben, Anforderungen und Testartefakten.

Daher hat die Matrix die Form einer Tabelle, von der jede Zeile Folgendes enthält:

• Nummer und Beschreibung der Entwicklungsaufgabe aus der Tracker-Aufgabe;
• logischer Block, zu dem die Aufgabe gehört (optional);
• atomare Anforderung oder Akzeptanzkriterien;
• Priorität;
• Nummer und Beschreibung des entsprechenden Testartefakts.

Da wir den Jira-Task-Tracker Zephyr von Jira für die Testdokumentation und das Confluence-Anforderungsmanagementsystem verwenden, werden alle Entitäten synchronisiert, und diese Rückverfolgbarkeit ermöglicht Folgendes:

• den aktuellen Stand der Umsetzung visualisieren;
• Anforderungen in atomarere aufteilen und strukturieren;
• zu überwachen, ob es Anforderungen gibt, für die noch keine Entwicklung geplant ist (Implementierungsdurchlauf);
• überwachen, ob die Anforderung derzeit umgesetzt wird;
• überwachen, ob die Anforderung durch einen Testfall abgedeckt ist (Überspringen von Tests);
• Visualisieren Sie die Priorisierung von Anforderungen.

Beziehungsoptionen in der Rückverfolgbarkeitsmatrix

Bindungsanforderungen und Testfälle können sein:

• 1 zu 1 (atomare Anforderung, die von einem Testfall abgedeckt wird, dieser Testfall deckt nur diese Anforderung ab);
• 1 bis n (eine Anforderung, die von mehreren Testfällen abgedeckt wird, diese Testfälle decken nur diese Anforderung ab);
• n bis n (eine Anforderung, die von mehreren Testfällen abgedeckt wird, diese Testfälle decken diese und andere Anforderungen ab).

In Bezug auf den letzten Punkt möchte ich darauf hinweisen

• Wenn eine Anforderung in der Rückverfolgbarkeitsmatrix durch mehrere Tests abgedeckt ist, kann dies auf eine Redundanz der Tests hinweisen. In diesem Fall muss analysiert werden, wie atomar die Anforderung ist.
• Wenn wir durch die Durchführung aller Testfälle die Vollständigkeit der Abdeckung sicherstellen und die Testfälle selbst sich nicht duplizieren, ist dies kein übermäßiger Test.

Wir haben Fälle im Projekt, in denen eine Anforderung durch mehrere Tests abgedeckt wird und ein Test mehrere Anforderungen abdecken kann („1 zu n“ und „n zu n“ Verbindungen).

Spezifität der Abdeckungsschätzung unter Verwendung von Rückverfolgbarkeitsmatrizen

Wenn wir die Metrik „Verhältnis der Anzahl der Anforderungen zur Anzahl der Testartefakte“ verwenden, um die Abdeckung zu bewerten, sollten die Beziehungen in der Matrix „1 zu 1“ sein und die Anforderungen sollten maximal zerlegt werden.

Ein Beispiel. Wir haben eine nichtatomare Anforderung: "Der Benutzer muss in der Lage sein, den Buchstaben in einem Texteditor zu ändern und zu formatieren." Ein Testfall wird offensichtlich nicht ausreichen, aber wenn nur ein Artefakt in der Matrix verknüpft ist, besteht visuell die Idee, dass die Anforderung abgedeckt ist.

Deshalb ist es besser:

• Teilen Sie diese Anforderung in der Matrix in separate atomare Funktionen eines Texteditors auf.
• Schreiben Sie ein Akzeptanzkriterium für jede Funktion.
• Erstellen Sie für jedes Kriterium ein Testartefakt.
• Wenn mehrere atomare Anforderungen durch eine Checkliste abgedeckt werden können, können Sie keine übermäßige Fragmentierung durchführen und Ressourcen sparen.

Da es an Ressourcen für eine maximale Zerlegung mangelt, können Sie nichtatomare Anforderungen verwenden. Um diese jedoch abzudecken, müssen Sie mehrere Testartefakte erstellen.

In diesem Fall werden Testfälle und Checklisten für jede nichtatomare Anforderung gleichzeitig erstellt, dh jede Anforderung in der Matrix wird entweder vollständig durch Artefakte abgedeckt oder überhaupt nicht abgedeckt.

Bei der Zusammenstellung der Matrizen ist es ratsam, die Empfehlung einzuhalten, dass die Zerlegung jeder Anforderung in einer einzelnen Matrix ungefähr gleich sein sollte, dh eine Tabelle sollte keine Anforderungen enthalten, von denen einige 5 Testfälle erfordern, und Teil-1-Testfall.

Der Coverage Score wird in diesem Fall für jede Matrix separat berechnet.
Da unsere Projektdokumentation für jedes Feature möglicherweise anders aussieht und sogar eine Beschreibung eines Features UML, Diagramme, Diagramme von Benutzerfällen und Übergängen enthalten kann und das Projekt mehr als 40 umfangreiche Funktionen enthält, haben wir beschlossen, für jedes Modul oder Feature eine separate Matrix zu entwickeln Verlieren Sie keinen der Vorteile dieses Tools.

Der Abdeckungswert wird auch für jedes Modul oder Merkmal separat berechnet.

Mit diesem Ansatz können wir die oben beschriebene Metrik verwenden: "Die Anzahl der Anforderungen für die Anzahl der Testartefakte". Selbst wenn wir 1 zu n, n zu n Verbindungen haben, haben wir mehrere Komponenten, von denen jede in mehreren Modulen verwendet werden kann. Die Anforderungen und Akzeptanzkriterien sind in jeder Matrix beschrieben, und ein Testartefakt wird verwendet.

Unsere Matrizen werden auch im Confluence-Anforderungsmanagementsystem gespeichert. Jede Matrix befindet sich mit der Struktur als untergeordnete Seite des Features, für das sie entwickelt wurde. Außerdem werden alle Matrizen auf einer Seite gesammelt, um die Abdeckung der gesamten Anwendung zu beurteilen.

Erstellen und Verwalten einer Matrix

Das Erstellen einer Matrix ist in unserem Workflow für Analyseaufgaben enthalten.



Wenn wir Informationen über eine neue Funktion erhalten, erstellt der Analyst unseres Teams eine Aufgabe im Task-Tracker und arbeitet zusammen mit dem Product Owner als Teil dieser Aufgabe seitens des Kunden. Bei der Erfassung und Strukturierung von Anforderungen führt das gesamte Team eine Überprüfung durch und stellt zusätzliche Fragen. Wenn die Anforderungen vom Kunden formuliert, dokumentiert und bestätigt werden, erstellt der Leiter des Entwicklungsteams Aufgaben für die Entwicklung dieser Funktion, und das Testteam kann mit der Erstellung einer Ablaufverfolgungsmatrix beginnen.

Und hier können wir die folgenden Phasen der Erstellung der Rückverfolgbarkeitsmatrix unterscheiden:

1. Zu Beginn werden die Anforderungen durch den Befehl QS und / oder Product-Owner zerlegt und priorisiert. Das Ergebnis dieses Schritts ist eine strukturierte und priorisierte Liste aller Anforderungen für diese Funktionalität.
2. Die zweite Phase besteht in der Kommunikation mit dem Entwicklungsteam und der Zuordnung von Aufgaben aus den Aufgaben des Trackers zur Entwicklung in der Matrix zu den relevanten Anforderungen. Auf diese Weise können wir die Rückverfolgbarkeit von Entwicklungsanforderungen und -aufgaben verfolgen.
3. Die dritte Stufe ist die Entwicklung von Testfällen und Checklisten.
   Diese Phase wird entweder vor dem Testen oder während des Testens einer bestimmten Aufgabe durchgeführt.
   Wenn die Funktionalität neu ist und sich die Benutzeroberfläche ändert, kann es Fälle geben, in denen die Schritte am besten unmittelbar vor dem Testen der Aufgabe beschrieben werden.
   Wenn die Implementierungsfunktionalität einer der vorhandenen Funktionen ähnelt, können wir beginnen, Testfälle mit Schritten unmittelbar nach der Überprüfung und Zerlegung der Anforderungen zu beschreiben.
4. Stufe 4 - Füllen der Matrix mit Testfällen.
   Basierend auf den Ergebnissen des gesamten Prozesses erhalten wir Entwicklungsaufgaben, Testfälle zum Testen und eine Rückverfolgbarkeitsmatrix, die diese und Anforderungen kombiniert.
   Die Aufgabe, Anforderungen zu entwickeln, wird geschlossen.
5. Stufe 5 - Halten der Matrix im aktuellen Zustand. Änderungen an den Anforderungen müssen vorgenommen werden. Sie sollten auch die Integrationsbeziehungen zwischen zwei Matrizen berücksichtigen, die unterschiedliche Funktionen oder Module beschreiben, und beim Ändern einer überprüfen, ob die zweite bearbeitet werden muss.

Schwierigkeiten beim Arbeiten mit der Rückverfolgbarkeitsmatrix

1. Aktualisierung
   Die Matrix ist nur unter der Bedingung nützlich, dass sie immer auf dem neuesten Stand gehalten wird. Bei unserem Projekt mit häufig wechselnden Anforderungen hat die Aktualisierung viel Zeit in Anspruch genommen. Wenn die Matrix jedoch nicht aktualisiert wird, wird sie nicht nur nutzlos, sondern auch verwirrend.
   
   So entscheiden Sie :
   
   Teilweise löste das Problem mit einer häufigen Änderung der Anforderungen und übertrug die Phase der Erstellung der Matrix auf den Moment, in dem die Anforderungen bereits vom Team überprüft und vom Kunden bestätigt wurden.
   Das Team entschied, dass der Analyst die Anforderungen nicht nur auf der Seite mit der Beschreibung der Funktionen aktualisiert, sondern sie auch in der Matrix findet und aktualisiert und in einer anderen Farbe hervorhebt. Dies half dem gesamten Team, die Änderungen und insbesondere dem QS-Team nicht zu verlieren, um festzustellen, welche Testfälle aktualisiert werden müssen.
2. Temporäre Ressourcen
   Das Projekt hat möglicherweise eine dringende Freigabe und arbeitet gleichzeitig mit neuen Anforderungen. Alle QS-Ressourcen werden zum Testen gesendet und funktionieren nicht mit Anforderungen. Somit steigt die Verschuldung laut Testdokumentation.
   
   So entscheiden Sie :
   
   Wenn alle QS-Spezialisten damit beschäftigt sind, vorrangige Aufgaben zu testen, übertragen wir die Erstellung einer Matrix für ein bestimmtes Feature. Es wird so weit wie möglich auf den Moment des Testens der ersten Aufgabe für dieses Feature übertragen. In diesem Fall wird die Matrix mit Testfällen gefüllt, während Sie die Aufgaben testen, in denen das Feature implementiert ist.
   
   Der QS-Spezialist legt in der Bewertungszeit nicht nur Zeit, um die Testfälle selbst zu schreiben, sondern auch Zeit, um die Matrix zu entwickeln.
3. Effizienz
   
   Wenn das Projekt klein ist und alle Anforderungen in Form eines strukturierten ToR festgelegt sind und für jede Anforderung gleichzeitig Testfälle erstellt werden, dupliziert die Rückverfolgbarkeitsmatrix in unserem Formular nur Informationen und ist eine Verschwendung von Ressourcen.
   
   Daher müssen Sie die in der Definition beschriebene Standardmatrix verwenden, um die Abdeckung zu bewerten.

Ausstattung

• Mit der Matrix können Sie die Implementierung von Anforderungen überwachen, verfolgen, dass alle Anforderungen entwickelt und getestet wurden und nichts fehlt.
• Mithilfe der Matrix kann das QS-Team nachverfolgen, ob die Testdokumentation verschuldet ist und welche spezifischen Anforderungen noch nicht durch Testfälle abgedeckt sind.
• Das Tool wird vom Analysten und dem QS-Team verwendet, um die geänderten Anforderungen zu überwachen.
• Im Rahmen des Projekts wurden Rückverfolgbarkeitsmatrizen nicht nur von uns, sondern auch vom Produktbesitzer seitens des Kunden verwendet. Sie haben also sichergestellt, dass alle Anforderungen vorhanden und korrekt sind, und mithilfe der bereits implementierten Matrix nachverfolgt. Durch Matrizen konnten wir den Entwicklungs- und Testprozess etwas transparenter gestalten.