Führung im Test: Testwerkzeuge
Redaktioneller Hinweis: Willkommen zur Leadership In Test-Reihe vom Softwaretest-Experten & Berater Paul Gerrard. Die Serie soll Testern mit ein paar Jahren Erfahrung – insbesondere jenen in agilen Teams – dabei helfen, in ihren Rollen als Testleiter und Manager herausragende Leistungen zu erzielen.
Im vorherigen Artikel haben wir uns die seitenspezifische Infrastruktur und deren Test betrachtet. In diesem Beitrag führe ich dich durch den Werkzeugkasten der Tester, erkläre die Wahl zwischen proprietären und Open-Source-Tools und stelle eine kurze Übung zur Tool-Auswahl vor.
Abonniere den QA Lead Newsletter, um benachrichtigt zu werden, sobald neue Teile der Serie erscheinen. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir sehr empfehlen, wenn du tiefer in dieses und andere Themen eintauchen möchtest. Wenn du dich anmeldest, nutze unseren exklusiven Gutscheincode QALEADOFFER um $60 Rabatt auf den Gesamtpreis des Kurses zu erhalten!
Softwareteams, die sich selbst organisieren, nutzen heute vielfältigere Werkzeuge als je zuvor. In einem typischen Softwareteam können zwanzig oder sogar dreißig Tools im Einsatz sein. Um dir die Navigation zu erleichtern, behandeln wir in diesem Beitrag folgende Themen:
- Werkzeuge für das Testen
- Tool-Architektur
- Testmanagement
- Testentwurf
- Proprietär oder Open Source?
- Eine Tool-Auswahl-Übung
Schauen wir uns zunächst die wichtigsten Arten von Werkzeugen an, die du für das Testen verwenden wirst.
Werkzeuge für das Testen
Es ist sinnvoll, die für das Testen relevanten Tools in drei Typen zu unterteilen:
Möchten Sie mehr vom The CTO Club?
Erstellen Sie ein kostenloses Konto, um diesen Beitrag fertigzulesen und einer Community von CTOs und Technikleitern beizutreten, die praxisnahe Frameworks, Tools und Einblicke für die Entwicklung, Einführung und Skalierung KI-gesteuerter Technologien teilen.
Have an account? Log In
- Kollaborationswerkzeuge: Sie unterstützen die Erfassung von Ideen und Anforderungen, die Kommunikation im Team mit Integration zu automatisierten Prozessen und manchmal Bots.
- Testwerkzeuge: Ein breites Spektrum von Tools, die Testdatenmanagement, Testentwurf, Unit-Test-Frameworks, funktionale Testausführung, Leistungs- und Lasttests, statische Tests, Testentwurf, Management des Testprozesses, Testfälle, Testprotokollierung und Berichterstattung unterstützen.
- DevOps- oder Infrastrukturmanagement-Tools: Diese Werkzeuge unterstützen die Verwaltung von Umgebungen und Plattformen, Deployment mittels Infrastructure as Code und Containertechnologien sowie Protokollierung, Überwachung und Analyse in der Produktion.
The Tools Knowledge Base ist ein Online-Verzeichnis für Tools, das sich insofern von anderen Online-Verzeichnissen unterscheidet, als es Kollaboration, Testen und DevOps abdeckt. Es gibt über 1700 Tools in diesen drei Kategorien. Die Tool-Webseiten sind indexiert und durchsuchbar.
Die Website aggregiert und indexiert zudem über 300 Blogger, und mehr als 52.000 Blogbeiträge sind ebenfalls indexiert und durchsuchbar. Wir haben für die wichtigsten Tool-Kategorien URLs sowie Direktzugriffe für die Suche dieser Kategorien in den Blogs bereitgestellt.
Es gibt über 1700 Werkzeuge, die Kollaboration, Testen und DevOps unterstützen.
Die wichtigsten Aspekte, die das Testmanagement beeinflussen und unterstützen, besprechen wir später in diesem Beitrag.
Tool-Architektur
Im nachfolgenden Schaubild haben wir die Bandbreite an Tool-Typen dargestellt, die die meisten modernen Softwareteams nutzen. Wir haben Werkzeuge unterschieden, die typischerweise in Entwicklungs-, Test- und Produktionsumgebungen verwendet werden.
Diese Werkzeuge werden von Infrastruktur-Tools unterstützt, die Plattformen, virtuelle Maschinen und Container für Umgebungen bereitstellen sowie Werkzeuge, die automatisierte Deployments durchführen. Die zur Verwaltung von Deployments und Releases genutzten Tools werden als Release- und Pipeline-Orchestrierungstools bezeichnet. Die Kommunikation im Team sowie mit vielen der automatisierten Prozesse erfolgt durch Kollaborations- oder ChatOps-Tools.
Auch wenn der Trend zu DevOps die Entwicklung und Einführung von Tools für kontinuierliche Entwicklung fördert, sind fast alle dieser Tools für jedes Entwicklungs- oder Betriebsteam nützlich.
Du musst keine DevOps-Kultur haben, um „DevOps“-Tools zu nutzen.
Testmanagement
Testmanagement-Tools sind bei allen größeren Projekten unverzichtbar. Agile Projekte setzen in der Regel ein Tool für das Incident Management ein und verlassen sich bei Tests zudem auf die Nutzung von User Stories und Szenarien, um zentrale Beispiele für (wenn auch nicht alle) Tests nachzuvollziehen. Testmanagement-Tools reichen vom sehr einfachen Beispiel, wie etwa Microsoft Excel, bis hin zu umfassenden Application Lifecycle Management (ALM) Produkten.
Im Allgemeinen umfasst der Anwendungsbereich von Testmanagement-Tools verschiedene Bereiche:
Testabdeckungsmodell: Die meisten Testmanagement-Tools ermöglichen es, eine Reihe von Anforderungen zu definieren, denen Testfälle und/oder Prüfungen in Tests zugeordnet werden können. Diese Anforderungen können manchmal hierarchisch organisiert werden, um ein Inhaltsverzeichnis eines Dokuments abzubilden. Zunehmend lassen sich auch andere Modelle wie Anwendungsfälle oder Geschäftsprozessabläufe erfassen. Berichte über Testplan- und Ausführungsabdeckung sind in der Regel verfügbar.
Testfallmanagement: Testfälle und deren Inhalte können so verwaltet werden, dass eine dokumentierte Übersicht über durchgeführte Tests entsteht. Die Inhalte der Testfälle können entweder im Voraus aufbereitet oder als Protokoll bereits ausgeführter Tests festgehalten werden. Testfälle können im freien Textformat oder strukturiert in einzelne Schritte mit erwarteten Ergebnissen dokumentiert sein. Das Importieren von Dokumenten und Bildern zum Speichern bei Tests oder einzelnen Schritten ist üblich.
Testausführungsplanung: Tests können in eine Hierarchie eingeordnet oder mit Tags versehen werden, um eine dynamischere Struktur zu schaffen. Testteam-Mitglieder bekommen gegebenenfalls Tests zugewiesen. Die geplante Testdauer kann zur Veröffentlichung eines synchronisierten Testzeitplans im gesamten Team verwendet werden. Teilmengen der Tests können ausgewählt werden, um Abdeckungsanforderungen zu erfüllen, bestimmte Funktionen zu testen oder Regressions-Testmengen erneut auszuführen. Tests, die als noch nicht ausgeführt, blockiert, fehlgeschlagen oder in einem anderen Status markiert wurden, können ebenfalls zur Ausführung ausgewählt werden.
Testausführung und Protokollierung: Während die Tests im Team durchlaufen werden, wird der Status jedes Tests festgehalten. Allen durchgeführten Tests werden die/der Tester(in) sowie Datum/Uhrzeit und Dauer zugeordnet. Bestandenene Tests erhalten gewöhnlich den einfachen Status "bestanden". Fehlgeschlagene, blockierte oder auffällige Testergebnisse werden oft mit Screenshots, den erfassten Testergebnissen und einem zugehörigen Incident-Report versehen. Viele Tools bieten Schnittstellen zu Testausführungs-Tools, die Tests steuern, Resultate protokollieren und sogar Entwürfe von Incident-Reports erstellen können.
Incident Management: Testfehler werden im Ausführungsprotokoll erfasst. Meistens erfordern diese weitere Untersuchungen, inklusive Debugging und Fehlerbehebung, falls ein Bug vorliegt. Fehler, die einer Untersuchung bedürfen, werden in der Regel mittels Incident-Report, Beobachtungen oder Bug Reports dokumentiert. Incident Reports enthalten oft zahlreiche unterstützende Informationen. Normalerweise wird ein Typ, ein zu testendes Objekt, eine Priorität und eine Schwere vergeben. Einige Unternehmen dokumentieren entsprechend große Mengen an Informationen und führen eine sehr ausgefeilte Prozesskette im Incident Management.
Berichtswesen: Berichte und Analysen aus allen oben genannten Bereichen, soweit erforderlich. Die Vielfalt reicht von geplanten vs. tatsächlich erreichten Testabdeckungen, dem Status von Incident Reports zum Nachverfolgen offener Untersuchungs-, Fehlerbehebungs- und erneut zu testender Arbeitsschritte, Analysen zur Behebungsdauer je Art des Fehlers, unterteilt nach Funktion, Schweregrad, Dringlichkeit und so weiter.
Das meistgenutzte Testmanagement-Tool der Welt ist noch immer 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, Kollaborationsdiagramme, Sequenzdiagramme usw. bieten ebenfalls eine solide Basis für das Testdesign.
In vielen Projekten werden Modelle genutzt, um Anforderungen oder Grob-Designs zu erfassen. Sobald diese den Testern zur Verfügung stehen, können sie genutzt werden, um Wege nachzuverfolgen und so Abdeckungspunkte direkt aus dem Modell zu übernehmen. Sind solche Modelle nicht vorhanden, ist es für das Testteam häufig sinnvoll, beispielsweise Prozessflussdiagramme oder Swimlane-Diagramme selbst zu erstellen. Diese helfen Testern dabei, mit den Stakeholdern bedeutungsvolle Diskussionen – insbesondere zum Thema Abdeckungsstrategie – zu führen.
Im proprietären Bereich entstehen derzeit Tools, mit denen sich beispielsweise Flussdiagramme erfassen und nutzen lassen, um Testfälle automatisch durch Nachverfolgung von Pfaden nach bestimmten Abdeckungszielen – z.B. alle Verbindungen, alle Prozesse, alle Entscheidungsergebnisse, alle Paare und alle Wege – zu erstellen. Diese Tools können mit Systemen zur Testdatenverwaltung und -generierung verbunden werden, um Testdatenkombinationen für manuelle oder automatisierte Tests zu erzeugen.
Es gibt auch Tools, die das Modellieren direkt in den Testausführungs-Tools ermöglichen. Beispielsweise kann der Testentwickler mit solchen Tools alle Felder einer Webseite erfassen, Verknüpfungen zum Zusammenführen der Felder herstellen und ein Navigationsmodell für die Seite in grafischer Form erstellen.
Im Anschluss wird das Modell zur Erstellung von Navigationspfaden genutzt, um eine Testsuite aufzubauen, die bestimmte Abdeckungskriterien erfüllt – genau wie die zuvor beschriebenen Modellierungs-Tools. Diese Ausführungs-Tools können automatisierte Testpfade auf Basis ausgewählter Kriterien generieren, sie zufällig erzeugen lassen und berichten außerdem über die Testabdeckung gegenüber diesen Modellen.
Dies ist momentan ein dynamisches Feld – behalten Sie Modellierungs-Tools im Auge, die Testdesign und -generierung unterstützen, ebenso wie Ausführungs-Tools mit Systemuntertest-Modellierung, automatisierter Pfadselektion und Berichterstattung.
Proprietär oder Open Source?
In den letzten zwanzig Jahren hat sich die Nutzung von freien und Open-Source-Software (FOSS)-Produkten, insbesondere zum Betrieb von Infrastruktur, weit verbreitet. Die Kosten für Betriebssystemlizenzen und zugehörige Webserver-Software von Microsoft sowie 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 der Artikel die Vor- und Nachteile von Open-Source- und proprietären Tools behandelt, kann Ihnen unser umfassender Leitfaden zu Jira-spezifischen Testmanagement-Tools helfen, eine fundierte Entscheidung zu treffen, wenn Sie gezielt nach Lösungen suchen, die sich gut in Jira integrieren lassen.
Die beiden unten stehenden Tabellen (täglich aktualisiert auf w3techs.com) zeigen die relative Beliebtheit von Betriebssystemen und Webserver-Produkten. Etwa 85 % der Websites laufen auf den bekanntesten Open-Source-Webservern Apache und Nginx.
Die Beliebtheit dieser FOSS-Infrastrukturprodukte beweist, dass Open Source genauso zuverlässig – wenn nicht sogar zuverlässiger – als proprietäre Produkte sein kann.
Für ein Softwareteam, das zwanzig oder dreißig Softwaretools zur Unterstützung seiner Arbeit benötigt, gibt es sowohl zuverlässige und funktionale FOSS- als auch proprietäre Tools für jede Aufgabe. Wie entscheidet man zwischen einem proprietären und einem FOSS-Produkt?
Die folgende Tabelle fasst einige Überlegungen zusammen, die Sie bei der Wahl eines Tool-Typs anstellen könnten.
| Proprietär | FOSS | |
| Verfügbarkeit | Für alle Bereiche sind Tools verfügbar. | In manchen Bereichen, insbesondere bei Entwicklungs- und Infrastruktursoftware, gibt es bessere Unterstützung als in anderen. |
| Kaufpreis | Oft teuer, insbesondere bei „Enterprise“-Produkten. | Kostenlos, oder Community-Lizenz ohne Kosten. Kommerzielle Lizenzen können für Enterprise- oder gehostete Versionen existieren. |
| Dokumentation | In der Regel sehr gut. | Unterschiedlich. Manchmal exzellent, manchmal gar nicht vorhanden – und alles dazwischen. Oft von Entwicklern für Entwickler geschrieben, also weniger benutzerfreundlich als kommerzielle Dokumentation. |
| Technischer Support | Sehr gut, aber kostenpflichtig. | Unterschiedlich. Manche Tool-Autoren bieten exzellenten Support und fügen sogar auf Anfrage Funktionen hinzu. Viele Tools haben Online-Foren – können aber sehr technisch sein. Andere Tools sind schlecht unterstützt. |
| Zuverlässigkeit/Qualität | In der Regel sehr gut. | Variabel. Produkte mit vielen Nutzern, Sprachen, großen Support-Teams sind meist exzellent. Tools, die von Einzelpersonen mit wenigen Mitwirkenden und Nutzern entwickelt wurden, können unzuverlässig sein. |
| Funktionsvielfalt | Funktionsumfänge folgen meist veröffentlichten Produkt-Roadmaps und sind in der Regel umfassend. | Produkte entwickeln sich oft basierend auf Nutzeranforderungen und der Größe des Entwicklerteams. Die Mitwirkenden fügen meist Funktionen hinzu, die sie selbst benötigen, z. B. nicht basierend auf Kundenumfragen. |
| Veröffentlichungs-/Patch-Frequenz | Hauptversionen erscheinen meist im Abstand von Monaten, manchmal Jahren. Regelmäßige Patch-Releases. Warnungen und Release Notes sind in der Regel sehr gut. | Unterschiedlich. Große Infrastrukturprodukte: Hauptversionen wie bei proprietären Produkten. Kleinere, weniger verbreitete Tools werden häufiger aktualisiert. Wenig oder keine Warnung, schlechte Release Notes und gelegentlich Verlust der Abwärtskompatibilität. |
FOSS-Produkte sind vielleicht günstiger zu beschaffen, aber andere Kosten und Verantwortlichkeiten können erheblich sein. Der entscheidende Faktor zwischen beiden ist meist eine Mischung aus Unternehmenskultur, Risikobereitschaft und technischer Kompetenz.
Wenn Sie proprietäre Produkte und Supportverträge kaufen, sind die Risiken im Hinblick auf Inkompatibilität (mit anderen Produkten), Zuverlässigkeit, Benutzerfreundlichkeit und engagierten technischen Support insgesamt gering – wenn auch manchmal teuer.
Bei FOSS-Produkten muss man in der Regel viel gründlichere Recherchen anstellen, bevor man sich entscheidet. Schließlich gibt es keinen Vertriebsmitarbeiter, den man fragen könnte, und die Dokumentation ist eher funktional als erklärend. Natürlich lässt sich eine Testphase leicht einrichten und Sie können beliebig viele Tools ausprobieren, aber Sie müssen die Fähigkeiten des Tools gründlich untersuchen.
Schlechtere Benutzerfreundlichkeit und mangelnde Kompatibilität mit Ihren vorhandenen Tools können Probleme verursachen. Möglicherweise müssen Sie Schnittstellensoftware oder Plug-ins sowie Reporting- oder Datenimport/-export-Utilities selbst entwickeln.
Außerdem müssen Sie sich selbst und Ihr Team schulen, damit alle auf dem neuesten Stand sind, und in der Regel selbst den Softwaresupport übernehmen. Ihr Team wird dafür jedoch eine sehr genaue Kenntnis der Funktionsweise des Tools erlangen und weitgehend eigenständig agieren können.
Ein FOSS-Tool kann dir dabei helfen, Erfahrungen mit einem neuen Tool-Typ zu sammeln – und das zu geringen Kosten. Mit dieser Erfahrung bist du besser aufgestellt, um langfristig ein proprietäres Tool auszuwählen.
Eine Übung zur Tool-Auswahl
Wenn du ein Testmanagement-Tool suchst, das dein aktuelles oder ein dir bekanntes, kürzlich verwendetes Projekt und eine Anwendung unterstützt: Erstelle auf Basis der oben diskutierten Feature-Bereiche von Testmanagement-Tools eine Liste von 15–20 Merkmalen, die entweder:
- Verpflichtend
- Wünschenswert
Dies kann funktionale Fähigkeiten, Integrationen, einen Schwerpunkt auf Benutzerfreundlichkeit, Support oder auch eine große Nutzerbasis bzw. Online-Foren/FAQs beinhalten. Wenn du bereits ein Tool im Einsatz hast, wähle es nicht erneut aus.
Nutze den Text deiner Anforderungen, um in der Tools Knowledge Base nach drei Tools zu suchen (darunter sowohl ein proprietäres als auch ein FOSS-Produkt), die deinen Anforderungen zu entsprechen scheinen. Erstelle mithilfe der Feature-Beschreibungen eine Vergleichstabelle der Funktionen dieser drei Produkte. Füge eine vierte Spalte für das Tool hinzu, das du aktuell verwendest – zum Vergleich.
- Wie schneiden die Tools bezüglich ihrer Funktionen ab?
- Welche Funktionen fehlen dem/den FOSS-Tool(s) im Vergleich zu den proprietären Tools?
- Wie viele Tools gibt es, die grundsätzlich deinen Anforderungen entsprechen?
- Wie viel Zeit würdest du schätzen, um eine Shortlist von beispielsweise drei Tools zusammenzustellen?
Melde dich für den QA Lead-Newsletter an, um benachrichtigt zu werden, sobald neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test-Kurs – sehr zu empfehlen, wenn du tiefer in dieses und andere Themen eintauchen möchtest. Falls ja, nutze unseren exklusiven Gutscheincode QALEADOFFER und sichere dir $60 Rabatt auf den vollen Kurspreis!
Lerne von anderen Testern, indem du unsere Podcasts anhörst oder unsere Blogs besuchst. Hier ist einer, von dem wir glauben, dass du viel lernen wirst: WIE TESTING-FÄHIGKEITEN MICH ZU EINEM BESSEREN AUTOMATION-ENTWICKLER GEMACHT HABEN
