Führung im Test: Testwerkzeuge
Anmerkung der Redaktion: Willkommen zur Reihe „Leadership In Test“ vom Software-Testguru & -Berater Paul Gerrard. Die Serie soll Testern mit einigen Jahren Erfahrung – besonders solchen in agilen Teams – helfen, sich in ihren Rollen als Testleiter und -manager zu profilieren.
Im vorherigen Artikel haben wir uns die Infrastruktur von Systemen und deren Testmöglichkeiten angesehen. In diesem Artikel führe ich Sie durch den Werkzeugkasten für Tester, wie man zwischen proprietärer und Open-Source-Software wählt, und mache eine kurze Übung zur Werkzeugauswahl.
Melden Sie sich für den Newsletter von The QA Lead an, um benachrichtigt zu werden, wenn neue Teile der Serie erscheinen. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir sehr empfehlen, wenn Sie tiefer in dieses sowie andere Themen einsteigen möchten. Falls Sie sich dafür entscheiden, nutzen Sie unseren exklusiven Gutscheincode QALEADOFFER, um $60 Rabatt auf den vollen Kurspreis zu bekommen!
Selbstorganisierte Softwareteams nutzen heute eine größere Bandbreite an Werkzeugen als je zuvor. In einem typischen Softwareteam können zwanzig oder sogar dreißig Tools im Einsatz sein. Um Ihnen hierbei Orientierung zu bieten, behandeln wir in diesem Artikel:
- Werkzeuge für das Testen
- Tool-Architektur
- Testmanagement
- Testentwurf
- Proprietär oder Open Source?
- Eine Übung zur Werkzeugauswahl
Zunächst betrachten wir die Haupttypen von Werkzeugen, die Sie für das Testen verwenden werden.
Werkzeuge für das Testen
Es ist praktisch, die für das Testen relevanten Werkzeuge in drei Typen zu unterteilen:
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Zusammenarbeitswerkzeuge: Sie unterstützen das Festhalten von Ideen und Anforderungen, die Kommunikation im Team mit teils integrierten automatisierten Prozessen, manchmal auch Bots.
- Testwerkzeuge: eine breite Palette von Lösungen, die Testdatenmanagement, Testentwurf, Frameworks für Unit-Tests, Ausführung funktionaler Tests, Leistungs- und Lasttests, statische Tests, Testentwurf, Management des Testprozesses, Testfälle, Protokollierung und Reporting unterstützen.
- DevOps- oder Infrastrukturmanagementwerkzeuge: Sie unterstützen das Management von Umgebungen und Plattformen, Deployment durch Infrastructure as Code und Container-Technologien sowie Logging, Monitoring und Analysen in Produktionssystemen.
The Tools Knowledge Base ist ein Online-Register für Werkzeuge, das sich von den meisten anderen dadurch unterscheidet, dass der Fokus auf Zusammenarbeit, Testen und DevOps liegt. In diesen drei Bereichen sind mehr als 1700 Tools gelistet. Die Webseiten der Tools sind indexiert und suchbar.
Die Website sammelt und indiziert zusätzlich über 300 Blogger, und mehr als 52.000 Blogartikel sind ebenfalls indexiert und suchbar. Wir haben URLs zu den wichtigsten Werkzeugkategorien sowie Kurzlinks für die Suche in den Blogs dieser Kategorien bereitgestellt.
Es gibt über 1700 Werkzeuge, die Zusammenarbeit, Testen und DevOps unterstützen.
Die wichtigsten Herausforderungen, die das Testmanagement beeinflussen und unterstützen, werden wir später in diesem Artikel betrachten.
Tool-Architektur
In der untenstehenden Grafik haben wir die Bandbreite der Werkzeugtypen identifiziert, die die meisten modernen Softwareteams heute verwenden. Wir haben Werkzeuge separat aufgeführt, die typischerweise in Entwicklungs-, Test- und Produktivumgebungen verwendet werden.
Diese Tools werden von Infrastruktur-Werkzeugen gestützt, die Plattformen, virtuelle Maschinen und Container zur Bereitstellung von Umgebungen sowie automatisierte Deployments ermöglichen. Werkzeuge zur Verwaltung von Deployments und Releases werden als Release- und Pipeline-Orchestrierungs-Tools bezeichnet. Die Kommunikation im Team – ebenso wie viele der automatisierten Prozesse – werden über Kollaborations- oder ChatOps-Werkzeuge gesteuert.
Obwohl die Verlagerung zu DevOps die Entwicklung und Einführung von Tools zur Unterstützung der kontinuierlichen Entwicklung vorantreibt, sind fast alle dieser Werkzeuge für jedes Softwareentwicklungs- oder Betriebsteam nützlich.
Sie müssen keine DevOps-Kultur haben, um „DevOps“-Werkzeuge einzusetzen.
Testmanagement
Testmanagement-Tools sind in allen größeren Projekten ein Muss. Agile Projekte nutzen in der Regel ein Tool für das Incident-Management und verlassen sich bei Tests oft auf die Verwendung von Business Stories und Szenarien, um Schlüsselfälle – wenn nicht sogar alle – nachzuvollziehen. Testmanagement-Tools unterscheiden sich im Funktionsumfang von sehr einfachen Lösungen, z. B. Microsoft Excel, bis hin zu umfassenden Application Lifecycle Management (ALM)-Produkten.
Im Allgemeinen erstreckt sich der Funktionsumfang von Testmanagement-Tools über mehrere Bereiche:
Testabdeckungsmodell: Die meisten Testmanagement-Tools ermöglichen die Definition eines Satzes von Anforderungen, denen Testfälle und/oder Kontrollen in Tests zugeordnet werden. Diese Anforderungen können teilweise hierarchisch aufgebaut sein, um den Aufbau eines Inhaltsverzeichnisses widerzuspiegeln. Zunehmend lassen sich auch andere Modelle wie Use Cases oder Geschäftsprozessabläufe abbilden. In der Regel sind Berichte über Testplanung und Abdeckungsquoten verfügbar.
Testfall-Management: Testfälle und deren Inhalte können verwaltet werden, um eine dokumentierte Aufzeichnung der Tests zu gewährleisten. Die Inhalte der Testfälle können im Vorfeld der Tests vorbereitet oder als Nachweis der durchgeführten Tests genutzt werden. Testfälle können in Freitextform oder strukturiert in einzelne Schritte mit erwarteten Ergebnissen vorliegen. Das Importieren von Dokumenten und Bildern zur Ablage bei Tests oder einzelnen Schritten ist üblich.
Testausführungsplanung: Tests können hierarchisch strukturiert oder mit Tags versehen werden, um eine dynamischere Struktur zu ermöglichen. Teammitglieder können einzelne Tests zugewiesen bekommen. Geplante Testlaufzeiten können genutzt werden, um einen synchronisierten Testplan für das gesamte Team zu veröffentlichen. Teilmengen von Tests können ausgewählt werden, um Anforderungen abzudecken, ausgewählte Funktionen zu testen oder Regressionstests erneut auszuführen. Tests, die als "noch nicht ausgeführt", "blockiert", "fehlgeschlagen" oder mit einem anderen Status gekennzeichnet sind, können ebenfalls zur Ausführung ausgewählt werden.
Testausführung und Protokollierung: Während die Tests vom Team durchgeführt werden, wird deren Status dokumentiert. Für alle Testdurchläufe werden der Tester sowie Datum/Uhrzeit und Dauer festgehalten. Erfolgreiche Tests erhalten einen einfachen "bestanden"-Status. Fehlgeschlagene, blockierte oder auffällige Tests können mit Screenshots, Testergebnissen und einem Incident-Report versehen werden. Viele Tools verfügen über Schnittstellen zu Testausführungstools, die Tests verwalten und ausführen, Ergebnisse protokollieren und sogar Entwürfe von Incident-Berichten generieren.
Incident Management: Testfehler werden im Ausführungsprotokoll festgehalten. Diese erfordern meist eine weitergehende Analyse, Debugging und – bei Fehlern – Fehlerbehebung. Fehler, die untersucht werden müssen, werden üblicherweise mithilfe von Incident- oder Beobachtungs- oder Fehlerberichten dokumentiert. Incident-Reports enthalten oft umfangreiche Zusatzinformationen. Meist werden Vorfälle nach Typ, getestetem Objekt, Priorität und Schweregrad klassifiziert. Manche Unternehmen erfassen besonders viele Details und kombinieren dies mit einem ausgereiften Incident-Management-Prozess.
Reporting: Berichte und Analysen der Daten aller oben genannten Bereiche – je nach Bedarf. Die Bandbreite der Berichte reicht von geplanten vs. tatsächlichen Testabdeckungen, Status von Incident-Berichten zur Nachverfolgung ausstehender Untersuchungen, Fehlerbehebung und erneuter Tests bis hin zu Analysen der Fehlerbehebungszeiten für verschiedene Fehlerarten – nach Funktion, Schweregrad, Dringlichkeit etc.
Das weltweit beliebteste Testmanagement-Tool ist nach wie vor Microsoft Excel.
Testdesign
Testdesign basiert auf Modellen. Bei System- und Abnahmetests sind typische Modelle Anforderungsdokumente, Use Cases, Flussdiagramme oder Swimlane-Diagramme. Technischere Modelle wie Zustandsmodelle, Kollaborations- oder Sequenzdiagramme bieten ebenso eine fundierte Grundlage für den Testentwurf.
In vielen Projekten werden Modelle genutzt, um Anforderungen oder Grobkonzepte festzuhalten. Stehen diese Modellen den Testern zur Verfügung, können sie verwendet werden, um Abdeckungspunkte direkt aus den Modellen abzuleiten. Falls solche Modelle nicht vorliegen, empfiehlt es sich oft, dass das Testteam beispielsweise Prozessflussdiagramme oder Swimlane-Diagramme erstellt. Diese ermöglichen aussagekräftigere Diskussionen mit Stakeholdern – insbesondere hinsichtlich der Abdeckungsstrategie.
Im proprietären Bereich gibt es zunehmend Tools, mit denen sich Modelle wie Flussdiagramme erstellen lassen und mit denen sich Testfälle durch das Nachverfolgen von Pfaden nach bestimmten Abdeckungszielen (z. B. alle Verbindungen, alle Prozesse, alle Entscheidungsresultate, All-Pairs und alle Pfade) generieren lassen. Diese Tools können mit Lösungen für Testdatenmanagement und -generierung verknüpft werden, um Testdatensätze für manuelle oder automatisierte Tests zu erzeugen.
Es gibt auch Tools, bei denen die Modellierung direkt in Testausführungstools erfolgt. Beispielsweise kann der Testentwickler damit alle Felder einer Webseite festhalten, Verknüpfungen zwischen Feldern erstellen und ein Navigationsmodell für die Seite anlegen – alles in grafischer Form.
Das Modell dient dann dazu, Navigationspfade zu erzeugen, um eine Testsuite zu erstellen, die bestimmte Abdeckungsanforderungen erfüllt – wie bei den genannten Modellierungstools. Diese Ausführungstools können automatisierte Testpfade anhand ausgewählter Kriterien erstellen oder sie zufällig generieren und zudem die Abdeckung bezogen auf diese Modelle auswerten.
Dies ist aktuell ein sehr dynamisches Feld – behalten Sie Modellierungswerkzeuge im Blick, die Testdesign und Testgenerierung unterstützen, sowie Ausführungstools, die System-unter-Test-Modellierung und automatisierte Testpfadauswahl und -auswertung ermöglichen.
Proprietär oder Open Source?
In den letzten zwanzig Jahren hat sich die Verwendung von kostenfreier und quelloffener Software (FOSS) – vor allem für den Betrieb von Infrastruktur – stark verbreitet. Die Kosten für Betriebssystemlizenzen und zugehörige Webserver-Software von Microsoft und die allgemeine Ansicht, dass Linux/Unix zuverlässiger und sicherer als Windows ist, führen dazu, dass in vielen Umgebungen Linux/Unix das bevorzugte Betriebssystem für Server ist.
Während sich der Artikel mit den Vor- und Nachteilen von Open-Source- und proprietären Tools befasst, kann Ihnen unser ausführlicher Ratgeber zu Jira-spezifischen Testmanagement-Tools bei der Entscheidungsfindung helfen, wenn Sie speziell nach Lösungen suchen, die sich gut in Jira integrieren lassen.
Die beiden folgenden Tabellen (täglich aktualisiert auf w3techs.com) zeigen die relative Beliebtheit von Betriebssystemen und Webserver-Produkten. Etwa 85 % der Websites laufen auf den bekanntesten quelloffenen Webservern Apache und Nginx.
Die Beliebtheit dieser FOSS-Infrastrukturprodukte belegt, dass Open Source genauso zuverlässig oder sogar zuverlässiger als proprietäre Produkte sein kann.
Für ein Softwareteam, das die zwanzig oder dreißig Softwaretools zur Unterstützung seiner Aktivitäten benötigt, gibt es sowohl zuverlässige und funktionale FOSS- als auch proprietäre Tools für jede Aufgabe. Wie wählt man zwischen einem proprietären und einem FOSS-Produkt?
Die folgende Tabelle fasst einige Aspekte zusammen, die Sie bei der Auswahl eines Tool-Typs berücksichtigen könnten.
| Proprietär | FOSS | |
| Verfügbarkeit | Für jeden Bereich sind Tools verfügbar. | In manchen Bereichen, besonders bei Entwicklungs- und Infrastruktur-Tools, ist die Unterstützung besser als in anderen. |
| Anschaffungskosten | Oft teuer, insbesondere „Enterprise“-Produkte. | Kostenlos oder mit Community-Lizenz ohne Kosten. Kommerzielle Lizenzen können für Enterprise- oder gehostete Versionen existieren. |
| Dokumentation | In der Regel sehr gut. | Unterschiedlich. Mitunter exzellent, manchmal nicht existent – und alles dazwischen. Oft von Programmierern für Programmierer geschrieben, daher weniger benutzerfreundlich als kommerzielle Dokumentation. |
| Technischer Support | Sehr gut, aber kostenpflichtig. | Unterschiedlich. Manche Tool-Autoren bieten exzellenten Support und fügen auf Anfrage sogar Funktionen hinzu. Viele Tools haben Online-Foren – diese können jedoch sehr technisch sein. Andere Tools sind schlecht unterstützt. |
| Zuverlässigkeit/Qualität | In der Regel sehr gut. | Schwankend. Produkte mit vielen Nutzern, Sprachversionen, großen Support-Teams sind meist ausgezeichnet. Manche Tools, die von Einzelpersonen mit wenigen Mitwirkenden und wenigen Nutzern entwickelt wurden, können instabil sein. |
| Funktionsumfang | Der Funktionsumfang folgt meist veröffentlichten Roadmaps und ist in der Regel umfassend. | Produkte entwickeln sich oft nach Nutzerbedarf und der Größe des Entwicklerteams. Die Mitwirkenden fügen meist diejenigen Funktionen hinzu, die sie selbst benötigen, statt etwa nach Kundenumfragen vorzugehen. |
| Release-/Patch-Frequenz | Große Releases erscheinen meist im Abstand von Monaten, manchmal Jahren. Regelmäßige Patch-Releases. Hinweise und Release Notes sind in der Regel sehr gut. | Unterschiedlich. Große Infrastrukturprodukte haben – wie proprietäre Produkte – seltene Major Releases. Kleinere, weniger verbreitete Produkte erscheinen häufiger. Kaum Vorwarnung, schlechte Release Notes und gelegentlicher Verlust der Rückwärtskompatibilität. |
FOSS-Produkte sind in der Anschaffung oft günstiger, aber es können erhebliche andere Kosten und Verantwortlichkeiten entstehen. Ausschlaggebend für die Wahl ist meist eine Mischung aus Unternehmenskultur, Risikobereitschaft und technischer Kompetenz.
Wer proprietäre Produkte und Supportverträge kauft, für den sind Risiken wie Inkompatibilität (mit anderen Produkten), Zuverlässigkeit, Benutzerfreundlichkeit und aufmerksamem technischen Support in der Regel gering – wenn auch manchmal teuer.
Bei FOSS-Produkten muss man in der Regel deutlich umfassendere Recherchen anstellen, bevor man sich für ein Produkt entscheidet. Schließlich gibt es hier keinen Vertriebsmitarbeiter, mit dem man sprechen kann, und die Dokumentation ist oft zweckmäßig, aber nicht erklärend. Natürlich lässt sich eine Testinstallation einfach einrichten und man kann beliebig viele Tools ausprobieren, aber es ist nötig, die Fähigkeiten eines Tools selbst gründlich zu untersuchen.
Schlechtere Benutzerfreundlichkeit und Inkompatibilität mit Ihren vorhandenen Tools können zu Problemen führen, sodass Sie unter Umständen Schnittstellen-Software, Plugins oder Hilfsprogramme für Berichte oder Datenimport/-export selbst schreiben müssen.
Zudem müssen Sie sich und Ihr Team meist selbst schulen und typischerweise auch den Softwaresupport selbst übernehmen. Ihr Team verfügt dafür aber über ein tieferes Wissen über die Funktionsweise des Tools und bleibt in hohem Maße eigenständig.
Ein FOSS-Tool kann Ihnen helfen, für wenig Geld Erfahrungen mit einer neuen Tool-Kategorie zu sammeln. Mit dieser Erfahrung sind Sie besser in der Lage, längerfristig ein proprietäres Tool auszuwählen.
Eine Übung zur Tool-Auswahl
Wenn Sie ein Testmanagement-Tool suchen, um Ihr aktuelles oder ein Ihnen bekanntes, jüngstes Projekt und dessen Anwendung zu unterstützen: Erstellen Sie auf Grundlage der oben diskutierten Testmanagement-Funktionsbereiche eine Liste mit 15-20 Merkmalen, die entweder:
- Verpflichtend
- Wünschenswert
Dies kann funktionale Fähigkeiten, Integrationen, einen Fokus auf Benutzerfreundlichkeit, Support, eine große Nutzerbasis oder Online-Foren/FAQs beinhalten. Wenn Sie bereits ein Tool im Einsatz haben, wählen Sie dieses nicht aus.
Verwenden Sie den Text Ihrer Anforderungen, um in der Tools Knowledge Base nach drei Tools (einschließlich eines proprietären und eines FOSS-Produkts) zu suchen, die scheinbar zu Ihren Anforderungen passen. Erstellen Sie anhand der Funktionsbeschreibungen der Tools eine Funktionsvergleichstabelle der drei Produkte. Fügen Sie eine vierte Spalte für das Tool hinzu, das Sie tatsächlich verwenden – zum Vergleich.
- Wie sieht der Funktionsumfang der Tools im Vergleich aus?
- Auf welche Funktionen müssen Sie bei FOSS-Tool(s) im Vergleich zu proprietären Tools verzichten?
- Wie viele Tools gibt es grundsätzlich, die Ihre Anforderungen erfüllen?
- Wie lange schätzen Sie, müssten Sie für die Recherche einplanen, um eine Auswahlliste von z. B. drei Tools zusammenzustellen?
Abonnieren Sie den The QA Lead-Newsletter, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test-Kurs—sehr zu empfehlen für alle, die einen tiefgehenderen Einblick in dieses und andere Themen suchen. Verwenden Sie exklusiv unseren Gutscheincode QALEADOFFER, um $60 auf den vollen Kurspreis zu sparen!
Lernen Sie von anderen Testern, indem Sie unseren Podcasts zuhören oder unsere Blogs lesen. Hier ist einer, der besonders empfehlenswert ist: WIE TESTSKILLS MICH ZU EINEM BESSEREN AUTOMATION-ENTWICKLER GEMACHT HABEN
