Zum Inhalt springen

Dokumentieren von Azure DevOps-Testplänen

Dokumentation des Azure-Testplans Ausgewähltes Bild

Als Business Analyst oder Test Lead kann es eine gewaltige Aufgabe sein, Dokumente für Ihre Azure DevOps-Testpläne zu erstellen.

Das Gleiche gilt für Anforderungen, die in Ihrem Azure DevOps-Projekt enthalten sind, aber Azure Test Plans stellt eine besondere Herausforderung dar.

In diesem Artikel erhalten Sie einen kurzen Überblick über das Modul „Azure DevOps Test Plans“, seine Funktionsweise und wie Sie Ihre Testergebnisse einfach dokumentieren können. Außerdem erfahren Sie mehr über die Architektur von Azure DevOps selbst.

Für einen schnellen Überblick können Siezum Video springen.

Was sind Azure DevOps-Testpläne?

Azure Test Plans ist ein Testmanagementmodul innerhalb von Azure DevOps, mit dem Benutzer Testpläne, Testsuiten und Testfälle für alle am Softwareentwicklungsprozess Beteiligten verwalten können. Mithilfe von Testplänen können Sie Azure Test Plans bietet auch eine Browsererweiterung für exploratives Testen und das Sammeln von Feedback von Stakeholdern.

Azure DevOps (ADO) ist ein hervorragender Ort für Ihr Qualitätssicherungsteam, um Testpläne für ein bestimmtes Projekt zu erstellen. Indem Sie Ihr Testteam auf die Azure DevOps-Plattform bringen, können Sie Ihr ADO-Projekt effektiv als Ihre einzige Quelle der Wahrheit nutzen.

Sie können Ihre Entwickler die Repositorys nutzen und die Entwicklungsarbeit an die Anforderungen knüpfen lassen, Sie können Ihre Business-Analyse-Teams Anforderungen erstellen und Testfälle hinzufügen lassen, und Sie können Ihr QA-Team diese Testfälle und die vom BA-Team erstellten Anforderungen nutzen lassen, um alle Ihre Tests durchzuführen.

Azure DevOps-Testpläne können nun sowohl für automatisierte als auch für manuelle Tests verwendet werden. Dieser Artikel konzentriert sich jedoch ausschließlich auf manuelle Tests mit ADO-Testplänen.

Test Plans ist aus vielen Gründen ein hervorragender Ort für Ihr Team, um manuelle Tests durchzuführen:

Feedback von Interessengruppen

Der größte Vorteil von Testplänen besteht darin, dass Ihr Testteam mit Ihren Teams für Geschäftsanalyse und Entwicklung in derselben Umgebung zusammenarbeiten kann. Auf diese Weise schaffen Sie eine einzige Informationsquelle für alle, die an einem Projekt arbeiten.

Wenn Sie Ihre manuellen Testvorgänge von hier aus durchführen, können Sie direkt mit den Testfällen interagieren, die bereits in Ihrem Azure DevOps-Projekt erstellt wurden. So lassen sich die Beiträge Ihres Business-Analysis-Teams bei der Erstellung von Testfällen ganz einfach in Ihren Test-Workflow integrieren. Diese Funktion bietet einen großen Vorteil für Teams, deren Business-Analysten in der Lage sind, Testfälle für das QA-Team zu erstellen. Wenn Sie als Business-Analyst diese Aufgabe übernehmen, erfahren Sie weiter unten in diesem Artikel, wie dies funktioniert.

Robuste manuelle Testfunktionen

Test Plans bietet außerdem einige unglaublich hilfreiche manuelle Testfunktionen, mit denen Ihre Tester aussagekräftige Rückmeldungen zu den Ergebnissen ihrer Tests geben können, die über die einfache Markierung eines bestimmten Testschritts als bestanden oder nicht bestanden hinausgehen. Es bietet außerdem ein interaktives Fenster, in dem Sie die Ergebnisse einzelner Testschritte markieren, Live-Screenshots/Aufzeichnungen erstellen und Kommentare abgeben können, die direkt mit der Ausführung dieses Testfalls verknüpft sind. 

Wenn Sie also Ihre abgeschlossenen Testläufe überprüfen, können Sie nachvollziehen, was Ihr Tester erlebt hat, als er einen einzelnen Testschritt als blockiert oder fehlgeschlagen markiert hat. Dank dieser Einblicke kann sogar ein externes manuelles Testteam einen wertvollen Beitrag leisten und Teams können fehlgeschlagene Ergebnisse leicht identifizieren und interpretieren.

Einfache Erweiterbarkeit

Mit den richtigenTestfallmanagement-Tools können Sie intelligente Berichte und horizontale Rückverfolgbarkeitsmatrizen zu den Details von Testplänen, Testsuiten, Testfällen, Testläufen, Testfallausführungen und Testfallschritt-Ausführungen erstellen.

Tools wie dieses können die Funktionalität von Testplänen verändern, um widerzuspiegeln, wie Unternehmen Testfälle durch virtuelle Verknüpfungen verwalten.

Wie funktionieren Testpläne?

Jeden Monat erhält Google Tausende von Suchanfragen, in denen gefragt wird, wie ADO-Tests funktionieren. Ein Grund dafür könnte sein, dass die meisten Teams proprietäre, interne Lösungen verwenden, die für Tests entwickelt wurden und unabhängig von ADO-Testplänen sind.

Bevor Sie sich mit der Funktionsweise von ADO-Testplänen vertraut machen, sollten Sie sich mit den relevanten Begriffen vertraut machen. Azure-Testpläne bieten Ihnen drei Haupttypen von Testmanagement-Artefakten:

  • Testplan: Ein Testplan ist ein Container aus Konfigurationen, Testsuiten und Testfällen, den Sie in gemeinsame Testschritte unterteilen und Parameter verwenden können. Sie können Testsuiten und einzelne Testfälle gruppieren. Testpläne umfassen statische Testsuiten, anforderungsbasierte Suiten und abfragebasierte Suiten.
  • Testsuite: Eine Gruppe von Testfällen, die bestimmte Szenarien im Rahmen eines übergreifenden Testplans untersuchen. Durch die Gruppierung der Fälle lässt sich leichter erkennen, welche Szenarien abgeschlossen sind.
  • Testfall: Hierbeihandelt essich um einen Schritt oder eine Reihe von Schritten zur Validierung einzelner Teile Ihres Codes oder Ihrer App-Bereitstellung. Mithilfe eines Testfalls können Sie überprüfen, ob Ihr Code korrekt funktioniert und den geschäftlichen und kundenbezogenen Anforderungen entspricht. Sie können Testfälle im Rahmen eines Testplans erstellen, ohne eine Testsuite erstellen zu müssen.

Manchmal kann die Terminologie verwirrend sein, da viele Teams „Testplan“ sagen, wenn sie eigentlich „Testsuite“ meinen.

Wenn Ihr Team eine Testsuite erstellt, muss es zwischen drei verschiedenen Arten von Testsuiten wählen, wie unten dargestellt:

Testplan 1:

Testpläne enthalten Testsuiten.
Es gibt drei Arten von Testsuiten. Lesen Sie die Beschreibungen der folgenden Suiten, um die drei verschiedenen Arten kennenzulernen.

  • Testsuite 1
  • Testsuite 2
  • Testsuite 3

Testsuite 1 – Anforderungsbasiert
Anforderungsbasierte Testsuiten sind die einfachsten und am besten nachvollziehbaren. Sie beziehen alle Testfälle für eine bestimmte Anforderung ein. 

  • Testfall 1
  • Testfall 2

Testsuite 2 – Abfragebasiert
Abfragebasierte Testsuiten ziehen eine Gruppe von Tests aus Ihrem Projekt heran, unabhängig davon, mit welchen Anforderungen die Testfälle verknüpft sind. 

  • Testfall 3
  • Testfall 4

Testsuite 3 – Statisch
Statisch basierte Testsuiten werden entweder als Container zum Gruppieren anderer Testsuiten oder zum Gruppieren einer bestimmten Menge von Testfällen verwendet. 

  • Testfall 5
  • Testfall 6
  • Testsuite 1
  • Testsuite 2
Je nachdem, welche Testsuite Sie erstellen, können Sie beim Erstellen einer Testsuite alle Testfälle einbinden, die Sie testen möchten.

Sobald Sie Ihre Testsuite mit den entsprechenden Testfällen erstellt haben, können Sie die gesamte Suite ausführen, was als Testlauf bezeichnet wird.

Bevor Sie Ihren Testlauf starten, müssen Sie zwischen drei verschiedenen Arten von Testsuiten wählen, die ausgeführt werden sollen: anforderungsbasiert, abfragebasiert und statisch.

Wie wähle ich einen Testsuite-Typ aus?

Bevor Sie Ihren Testlauf starten, müssen Sie zwischen drei verschiedenen Arten von Testsuiten wählen, die ausgeführt werden sollen: anforderungsbasiert, abfragebasiert und statisch. Beachten Sie: Testsuiten (jeglicher Art) können nur Testfälle enthalten.

1) Anforderungsbasierte Testsuite
Eine anforderungsbasierte Testsuite ist eine Testsuite, in der Sie Ihre Testfälle einer Anforderung zuordnen, um deren Akzeptanzkriterien zu definieren.

Durch das Erstellen einer anforderungsbasierten Testsuite werden alle Testfälle für diese Anforderung abgerufen. Beim Erstellen einer Suite importieren Sie automatisch alle zugehörigen Testfälle. Stattdessen wählen Sie einfach die Anforderung aus.

Anschließend können Sie alle Tests für diese bestimmte Anforderung ausführen, die Ergebnisse der einzelnen Testläufe einsehen und daraus schließen, ob das von Ihnen entwickelte Produkt diese Anforderung vollständig erfüllt.

Da beim Erstellen einer Suite automatisch alle zugehörigen Tests übernommen werden, muss Ihr QA-Team nicht erneut alle Anforderungen eingeben. Wenn Ihre BAs und Entwickler bei der Erstellung einer Anforderung die Testfälle hinzugefügt haben, können die QAs diese verwenden. Dies ist der Vorteil eines Modells mit einer einzigen Quelle der Wahrheit. Ihre Teams können von der Arbeit der anderen profitieren.

Selbst wenn Ihr Testleiter beschließt, weitere Testfälle für diese anforderungsbasierte Suite zu erstellen, werden die von ihm erstellten Testfälle automatisch mit der Anforderung selbst verknüpft. Unabhängig davon, ob BAs, Entwickler oder Testleiter Testfälle hinzufügen, kann jedes Team zur gleichen Gruppe von Arbeitselementen beitragen.

Wenn Sie anforderungsbasierte Testsuiten verwenden, kann Ihr TeamRückverfolgbarkeitsmatrizen erstellen, die Ihnen zeigen, wie Ihre Testfälle mit Ihren Anforderungen übereinstimmen und ob ein Testfall für eine bestimmte Anforderung bestanden oder nicht bestanden hat.

Mit fortgeschritteneren Lösungen können Sie sogarerläuternde Berichtezu Ihren Tests exportieren und teilen.

2) Abfragebasierte Testsuite
Wenn Sie eine Workitem-Abfrage erstellen und auswählen, welche Testfälle in Ihre Suite aufgenommen werden sollen, erstellen Sie eine abfragebasierte Suite. Azure DevOps fügt automatisch alle Testfälle, die diese Kriterien erfüllen, zur Suite hinzu.

Wann verwendet man eine abfragebasierte Testsuite?

In einigen Fällen führen Teams Tests für alle Testfälle durch, die sich derzeit in jeder Iteration befinden, oder sie führen Tests für alle Elemente mit einem bestimmten Tag oder anderen Kriterien durch. Diese Bedingungen sind nicht unbedingt direkt mit einer bestimmten Anforderung verbunden, und Sie können sie nur durch eine bestimmte Abfrage erfüllen.

Im Gegensatz zu anforderungsbasierten Testsuiten, die alle mit einer Anforderung verbundenen Tests einbeziehen, bieten abfragebasierte Testsuiten Teams die Möglichkeit, eine Testsuite anhand beliebiger verfügbarer Kriterien zu erstellen.

Wenn Sie diese Art von Testsuite erstellen, werden Sie gefragt, wie Sie Testfälle einlesen möchten, und können dazu eine Ad-hoc-Abfrage erstellen. Auf diese Weise können Sie Testfälle einlesen, die bestimmten Kriterien entsprechen. Beachten Sie, dass hierfür nicht die Abfragen verwendet werden, die IhrBusiness-Analyse-Teamin Azure DevOps erstellt. Die Oberfläche zum Erstellen dieser Ad-hoc-Abfrage ist jedoch nahezu identisch.

3) Statische Testsuite

Statische Suiten sind logische Container, in denen Sie beliebige Tests hinzufügen können. Sie sind nicht mit Anforderungen oder Abfragen verbunden.

Sie sind nützlich, wenn Sie möglicherweise mehrere Ebenen verschachtelter Testsuiten erstellen müssen. Oder Sie benötigen einen Ort, an dem Sie Ad-hoc-Tests erstellen und ausprobieren können.

Wie man einen Testplan erstellt

Testpläne helfen Ihrem Team dabei, die Durchführung von Tests so zu strukturieren, dass Ihr Projekt die Qualitätsstandards erfüllt. Sie erstellen sowohl Testpläne als auch Testsuiten für alle Anforderungen für jede der folgenden Iterationen.

Die Schritte sind wie folgt:

Schritt 1:

Um einen Testplan mit dem Namen „Given Iteration Test Plan“ zu erstellen, gehen Sie zur Registerkarte „Testplan“ im linken Bereich Ihrer Azure DevOps-Oberfläche. Wählen Sie „+ Neuer Testplan“.

Benennen Sie diesen Testplan „Testplan für Iteration 1“.

Wählen Sie aus, ob dieser spezifische Testplan für einen bestimmten Bereichspfad oder eine bestimmte Iteration gelten soll. Andernfalls können Sie dieses Feld leer lassen (in diesen Beispielbildern sind diese beiden Felder standardmäßig leer gelassen).

Nachdem die Testpläne erstellt wurden, ist es nun an der Zeit, eine Suite zu erstellen.

Schritt 2: Testsuiten hinzufügen

Da das Ziel darin besteht, alle Anforderungen einer bestimmten Iteration eines Produkts zu testen, fügen Sie anforderungsbasierte Suiten hinzu.

Wenn Sie eine anforderungsbasierte Suite erstellen, werden Sie Testfälle einbinden, die für die gegebenen Anforderungen bereits vorhanden sind. Andernfalls müssen Sie einer Anforderung neue Testfälle hinzufügen, bevor Sie sie zu einer anforderungsbasierten Testsuite hinzufügen können.

Wir möchten keine Anforderungen einführen, sondern die mit den Anforderungen verbundenen Testfälle. Dieser Punkt soll nur daran erinnern, dass Sie selbst beim Erstellen einer anforderungsbasierten Suite eine Gruppe von Testfällen erstellen und keine Anforderungen.

Erstellen wir also Testsuiten (Gruppen von Testfällen) für jede der Anforderungen in Iteration 1.

Schritt 3: Abfrage ausführen

Oben sehen Sie die Abfrage, die Sie erstellen müssen, um die Anforderungen der Iteration 1 abzurufen. Anschließend können Sie einfach auf „Abfrage ausführen“ klicken, wie oben gezeigt.

Wenn Sie die Abfrage ausführen und Ihre Arbeitselemente aus Iteration 1 sehen, wählen Sie einige davon aus.

Da jedes der oben genannten Work Items eine funktionale Anforderung darstellt und Sie sich für die Erstellung von anforderungsbasierten Suiten entschieden haben, erstellen Sie vier Testsuiten, eine für jede Anforderung.

Sehen wir uns das Ergebnis an, wenn wir oben auf die blaue Schaltfläche „Suiten erstellen“ klicken.

In der Abbildung oben sehen Sie, dass die Testsuiten für die Workitems 306 und 307 neben sich Zahlen in Klammern haben. Diese stehen für die Anzahl der darin enthaltenen Testfälle, nämlich eins bzw. drei.

Ausführen Ihres ersten Testplans

Nachdem Sie nun eine Testsuite für alle erforderlichen Anforderungen haben, können Sie entweder die Tests ausführen oder Testfälle hinzufügen, um die Testsuiten für diese Anforderungen zu vervollständigen.

Das Ausführen von Testfällen in einer Testsuite, um festzustellen, ob sie bestanden werden oder nicht, wird als Testlauf bezeichnet. Ein Testlauf ist das Ergebnis der Ausführung eines oder mehrerer Testfälle.

Lassen Sie uns einen Testlauf einer unserer Testsuiten durchführen.

Klicken Sie mit der rechten Maustaste auf die Testfälle in Work Item 307 und klicken Sie auf „Für Webanwendung ausführen“. Mit derChrome-Browsererweiterung können Sie diese Tests direkt in Chrome ausführen.

Azure öffnet ein neues Fenster für Ihren Testlauf (siehe unten).

Wenn Sie dieses Fenster neben das Fenster ziehen, das die Webanwendung enthält, die Sie gerade testen, können Sie die einzelnen Testschritte sehen und sie beim Testen als bestanden oder nicht bestanden markieren. Wenn die Anwendung oder Funktion einen der Testschritte nicht besteht, können Sie Kommentare hinzufügen, warum dies der Fall ist.

Sie können sogar den Bildschirm aufzeichnen oder Screenshots machen, um den Fehler besser zu veranschaulichen. Diese Informationen werden nun dem Testlauf beigefügt.

Indem Sie die Funktionsweise der Anwendung oder des Produkts, das Sie testen, prüfen und kommentieren, ermöglichen Sie Ihrem Team, sinnvolle Beiträge zur Behebung der von Ihnen entdeckten Probleme zu leisten.

Sobald Sie einen Testfall abgeschlossen haben (unabhängig davon, ob er bestanden oder nicht bestanden wurde), können Sie mit dem nächsten Testfall in diesem Testlauf fortfahren. Klicken Sie dazu wie unten gezeigt auf „Weiter“.

Wenn Sie Ihre Testsuite fertiggestellt haben, können Sie Ihren Testlauf speichern und schließen. Die Ergebnisse können Sie auf der Registerkarte „Läufe“ in Azure DevOps Test Plans einsehen.

Verständnis der Testplanergebnisse

Angenommen, Sie haben den folgenden Testplan (anforderungsbasierte Testsuite 307) aus unserem obigen Beispiel mit den folgenden Ergebnissen ausgeführt:

Sie können denselben Bildschirm verwenden, um festzustellen, was bestanden und was fehlgeschlagen ist. Wenn Sie jedoch die Beiträge Ihrer Tester sehen möchten, können Sie die Ansicht „Läufe“ unter „Testpläne“ verwenden (siehe linke Seite der Abbildung oben).

Hier sehen Sie den Testlauf, der „überprüft werden muss“.

Wenn Sie auf den Testlauf klicken, gelangen Sie zu „Letzte Testläufe“ und sehen die folgende Testlauf-Seite mit drei Registerkarten. Diese Registerkarten heißen „Zusammenfassung“, „Testergebnisse“ und „Filter“ und sind unten zu sehen.

Unter „Testläufe“ finden Sie die angehängten Screenshots, Aufzeichnungen, Videos und/oder Kommentare, die von Ihren Testern hinzugefügt wurden. Diese sind nicht in der Registerkarte „Zusammenfassung des Laufs“ verfügbar.

Um die Beiträge Ihrer Tester zu sehen, navigieren Sie zur Registerkarte „Testergebnisse“, wie unten gezeigt.

Wählen Sie Ihren fehlgeschlagenen Testfall aus, um auf die Informationen zuzugreifen, die von einem bestimmten Tester während seines Testlaufs für diesen Testfall gesammelt wurden.

Um das Feedback Ihrer Tester zu nutzen, können Sie Fehler erstellen, indem Sie zum vorherigen Bildschirm zurückkehren, auf dem ein fehlgeschlagener Testfall angezeigt wird und Sie „Einen Fehler erstellen“ können. Auf diese Weise können Sie einen Fehler erstellen, der eine Beziehung namens „Testergebnis“ (siehe unten) aufweist, die direkt mit dem fehlgeschlagenen Testfall des Testlaufs verknüpft ist.

Dokumentieren Sie Ihren Testplan

Die meisten großen Unternehmen, die technisch anspruchsvolle Arbeit leisten, müssen auch die Arbeit ihrer Mitarbeiter dokumentieren.

 Sie finden viele detaillierte Informationen zu einem bestimmten Fehler einer einzelnen Testsuite oder zum Testplan im Azure DevOps-Projekt selbst. Azure DevOps hilft Ihnen dabei, ein Dokument für Ihren Testplan zu erstellen, das alle Links zu den erforderlichen Stellen (z. B. zum Testlauf mit den Details eines Fehlers) innerhalb Ihres Projekts enthält.

Im Folgenden wird gezeigt, wie Sie die Ergebnisse einer bestimmten Testsuite im Dokumentformatexportieren können.

Wenn Sie dieses Dokument exportieren, können Sie „Drucken“ auswählen, um eine PDF-Datei zu erstellen, die wie im folgenden Screenshot aussieht:

Über die oben angezeigten Links gelangen Sie zu den vollständigen Details eines bestimmten Ergebnisses.

Beispielsweise hat Testfall 1578 (zu finden am unteren Rand des obigen Screenshots) den Wert „Latest Test Outcome“ (Aktuelles Testergebnis) „Failed“ (Fehlgeschlagen) mit einem Link. Über diesen Link gelangen Sie zur Seite „Test Runs“ (Testläufe), auf der Sie die Beiträge Ihrer Tester einsehen können.

Diese Dokumentation reicht jedoch nicht aus. Viele Benutzer erstellen gerne eine gemeinsame Version eines Testplandokuments, das alle Informationen zu einem bestimmten Testplan enthält. Wenn Sie ein Dokument erstellen müssen, das den Umfang, die Risiken, den Zweck, die Strategie usw. beschreibt, sollten Sie Microsoft Word verwenden.

Die Dokumentation ist nicht gerade als eine der größten Stärken von Azure DevOps bekannt. Mit einer Lösung wieSmartDocs können Sie jedoch Arbeitselemente, Testfälle, Testsuiten, Testpläne und viele damit verbundene Informationen in lesbare und gemeinsam nutzbare Dokumentationen umwandeln.

Das folgende Video zeigt Ihnen, wie das geht.

Erstellen von Testdokumenten aus Azure DevOps

In diesem Video zeigen wir Ihnen, wie Sie mit dem Modul „Modern Requirements4DevOps Smart Docs” die Dokumentation zu Ihren Testplänen aus Ihrem Azure DevOps-Projekt heraus erstellen können. 

Inhaltsverzeichnis

Beginnen Sie noch heute mit der Nutzung von Modern Requirements.

✅ Definieren, verwalten und verfolgen Sie Anforderungen innerhalb von Azure DevOps
✅ Arbeiten Sie nahtlos mit regulierten Teams zusammen
✅ Starten Sie KOSTENLOS – keine Kreditkarte erforderlich

Aktuelle Artikel