Auswahl von Testautomatisierungswerkzeugen – Kriterien und Methoden

Im ersten Artikel wurden die grundsätzlichen Herausforderungen und Einflussfaktoren bei der Auswahl von Testautomatisierungswerkzeugen, als Ergebnis aus verschiedenen Interviews, vorgestellt. Es wurde aufgezeigt, dass es bereits erste Ansätze von Checklisten, aber noch keine einheitliche Methode zur Auswahl von Testautomatisierungswerkzeugen gibt. Die Aufgabe der Abschlussarbeit war es daher, einen einfachen, zielführenden Ansatz zu finden, der die Suche nach geeigneten Testautomatisierungs-werkzeugen je nach Projekteinsatz anhand eines Kriterienkatalogs unterstützt.

Grundvoraussetzung für die Entwicklung eines Kriterienkataloges ist die Beantwortung der Frage, welche Kriterien bei der Auswahl eines Werkzeugs überhaupt relevant sind. Darauf gehe ich im zweiten Teil der Blogserie ein.

Symbolbild: Junger Mann vor dem Bildschirm, zeigt mit dem Finger auf den Desktop und telefoniert

Relevanz der Auswahlkriterien

Die Frage nach geeigneten Kriterien zur Bestimmung der Qualität von Softwareprodukten und, daraus abgeleitet, von Testautomatisierungswerkzeugen wird in der Literatur ausführlich diskutiert. Die für den Kriterienkatalog ermittelten Kriterien wurden größtenteils auf der Basis von Literaturrecherchen entwickelt. Die verwendeten Literaturquellen stelle ich nachfolgend kurz vor:

Die Auflistung der Softwarequalitätsmerkmale ISO 25010 bietet eine hilfreiche Checkliste, um eine Entscheidung für oder gegen den Test jedes Kriteriums zu treffen. Vergleichbare Auflistungen von Qualitätsmerkmalen finden sich auch an anderer Stelle (Spillner/Linz 2019, S. 27). Die Autoren geben jeweils Hinweise, anhand derer für ein Projekt die Erfüllung der einzelnen Qualitätseigenschaften bestimmt werden kann. Im Bereich der Testautomatisierung finden sich Listen von Kriterien zum Beispiel in Baumgartner et al. 2021, Lemke/Röttger 2021, Knott, 2016. Diese Kriterien beziehen sich unter anderem auf die unterstützten Technologien, die Möglichkeiten der Testfallbeschreibung und Modularisierung, die Zielgruppe, die Integration in die Werkzeuglandschaft und die Kosten. Das Ziel ist hier jedoch lediglich das Identifizieren von relevanten Kriterien, nicht aber deren Bewertung. Zum anderen ergaben sich zusätzliche Kriterien aus den Experteninterviews und der Analyse der Projekte der ZDI.

Die in dieser Arbeit identifizierten Auswahlkriterien kombinieren daher Erkenntnisse und Erfahrungen aus bestehenden Schriften zu den Themen Qualität, Testautomatisierung sowie Erstellung und Prüfung von Anforderungen an Testautomatisierungswerkzeuge zu einem praktisch anwendbaren Ansatz.

Abbildung 1: Quellen des Kriterienkatalogs

Klassifizierung der Kriterien

Bei der Auswahl von Testautomatisierungswerkzeugen wurden Einflussfaktoren wie Erfahrung, Kosten oder Interessengruppen genannt. Die Kosten waren für viele der Schlüsselfaktor. Im Rahmen dieser Arbeit wurde erkannt, dass Kriterien wie Integration oder Compliance zwar je nach Rolle unterschiedlich ausgeprägt sind, aber in der Liste der Kriterien mehr oder weniger Standard sind. Und sie sind unveränderbar, unabhängig davon, welche Anwendung getestet wird. Es gibt jedoch einen kleinen Anteil von Kriterien, der je nach der zu testenden Anwendung variiert. Ein Szenario, um die Problemstellung zu veranschaulichen: In der Medizintechnikbranche wird eine neue, webbasierte Anwendung entwickelt – das Frontend mit Angular 8 und NodeJS und das Backend mit Java Microservices. Das auszuwählende Testautomatisierungswerkzeug muss primär zu den Rahmenbedingungen passen, die durch die zu testende Webanwendung vorgegeben sind. Bevor ein Automatisierungswerkzeug zum Einsatz kommen kann, müssen die Schnittstellentechnologien der Anwendung überprüft werden. In der Praxis verfügen Testautomatisierungswerkzeuge über spezifische Eigenschaften und werden daher für unterschiedliche Technologien verwendet. Einige sind eher auf Web-Tests spezialisiert, während andere mehr im Bereich der Desktop-Tests angesiedelt sind. Ob Webanwendung oder mobile Anwendung – es bestehen immer also auch bestimmte Erwartungen an das Testautomatisierungswerkzeug. Daher ist der kritischste Faktor das Testobjekt bzw. das System under Test (SuT). Es bildet die Basis, auf der die Werkzeugauswahl getroffen wird (Baumgartner et al. 2021, S. 45). Zusammenfassend lassen sich die Kriterien in zwei Arten unterteilen: in den Standard- und in den variablen Anteil.

Abbildung 2: Die zwei Arten von Kriterien

Die Standardkriterien hängen nicht von dem Testobjekt ab. In Anlehnung an die Qualitätskriterien wurden diese Kriterien in vier Kategorien gruppiert: Features, System, Benutzbarkeit und anbieterbezogene Kriterien. Im Unterschied dazu hängen die variablen Kriterien von dem zu testenden System ab. Zu den variablen Kriterien gehören beispielsweise die unterstützten Applikationstypen, Betriebssysteme, Schnittstellentechnologien, Browser und Geräte.

Strategie der Variablenauswahl

Variablenauswahl bedeutet, aus einer Anzahl von Variablen diejenigen auszuwählen, die in die Liste der Kriterien aufgenommen werden sollen. Zur Unterstützung der Auswahl variabler Kriterien wurde im Rahmen meiner Arbeit ein Zielmodell mit eine AND/OR-Zerlegung auf der Grundlage von GORE (Goal Oriented Requirements Engineering) und den Arbeiten von Lapouchnian (2005) und Liaskos et al. (2010) eingeführt. Es hatte sich als wirksam erwiesen, Alternativen oder Variabilitäten genau zu erfassen (Mylopoulos/Yu 1994, S. 159-168), um alternative Designs während des Analyseprozesses zu evaluieren (Mylopoulos et al. 2001, S. 92-96). Die Ziele und Anforderungen werden über AND/OR-Zerlegungen verknüpft. Durch die AND-Zerlegung wird ausgedrückt, dass die Erfüllung der jeweiligen notwendig ist. Bei einer OR-Verknüpfung bedeutet dies, dass ist die Erfüllung eines dieser Ziele oder Anforderungen ausreichend. Dadurch werden die ersten Erwartungen an das Werkzeug explizit formuliert und irrelevante Anforderungen vermieden.

Abbildung 3: Vereinfachtes Zielmodell für ein Beispielprojekt XY 

Vorgehensweise bei der Werkzeugauswahl

Ausgehend von den identifizierten Kriterienarten und Spillner et al. (2011) wird in dieser Arbeit eine strukturierte Vorgehensweise für die Auswahl des passenden Testautomatisierungswerkzeugs entworfen. Die neue Vorgehensweise gliedert sich in fünf Schritte:

  1. Erarbeitung der Projektanforderungen
  2. Identifikation der variablen Kriterien mit Hilfe des AND/OR-Zielmodells
  3. Gewichtung der Kategorien und Kriterien
  4. Evaluierung der verschiedenen Werkzeuglösungen
  5. Bewertung und Auswahl

Der nächste Blogartikel geht darauf ein, wie der Kriterienkatalog nach der beschriebenen Vorgehensweise aufgebaut wurde. Außerdem werden wir zeigen, wie die variablen Kriterien in den Katalog aufgenommen wurden, und die Ergebnisse der Verprobung des Kriterienkatalogs vorstellen.

Dieser Beitrag wurde fachlich unterstützt von:

Kay Grebenstein

Kay Grebenstein arbeitet als Tester und agiler QA-Coach für die ZEISS Digital Innovation, Dresden. Er hat in den letzten Jahren in Projekten unterschiedlicher fachlicher Domänen (Telekommunikation, Industrie, Versandhandel, Energie, …) Qualität gesichert und Software getestet. Seine Erfahrungen teilt er auf Konferenzen, Meetups und in Veröffentlichungen unterschiedlicher Art.

Alle Beiträge des Autors anzeigen

Testautomatisierung in Angular-Webprojekten – Was kommt nach Protractor?

Der König ist tot, es lebe der König! Aber welcher? Nachdem das Team von Angular im April angekündigt hat, die Entwicklung seines e2e-Testing-Frameworks Protractor Ende 2022 einzustellen, stellt sich für viele Entwicklerinnen und Entwickler nun die Frage, wie es weiter geht. Welches Tool zur Testautomatisierung sollte man verwenden? Der Markt hält hierfür zahlreiche Alternativen bereit, von denen einige in diesem Beitrag beleuchtet werden sollen.

Symbolic picture: A woman is sitting at a desk with a laptop, tablet and smartphone. The user interfaces show the same dashboards.

Die Testkandidaten

Cypress

Bei Cypress handelt es sich wohl um den bekanntesten Kandidaten im Testfeld. Laut einer Umfrage in der Angular Community vom Januar 2021 handelt es sich mit über 60% der Stimmen um das am weitesten verbreitete Tool für automatisierte UI-Tests. Das erste Stable-Release erschien bereits 2017, gegenwärtig befindet sich die Anwendung in Version 10. Cypress beschreibt sich selbst als schnell, einfach und verlässlich und setzt dabei auf ein eigenes Ökosystem an Tools, das im Gegensatz zu Protractor unabhängig von Selenium und WebDriver ist. Unterstützt werden derzeit Chrome, Firefox und Edge, jedoch (noch) nicht Safari. Die Möglichkeit, die Tests gegen verschiedene Browser-Versionen auszuführen, kann durch die Anbindung von BrowserStack oder durch das Austauschen der Binaries für die lokale Ausführung erreicht werden.

ProContra
+ schnell
+ stabil
+ große Community
+ umfangreiche, verständliche Dokumentation
–        Noch kein Support für Safari
Tabelle 1: Vor- und Nachteile des Tools Cypress

Playwright

Das seit 2020 von Microsoft entwickelte Playwright stellt den jüngsten Kandidaten im Feld der Automatisierungstools dar. Laut eigener Beschreibung soll die Bibliothek aktuell, schnell, zuverlässig und leistungsfähig sein, um gängige Probleme des UI-Testens wie Flakiness und langsame Ausführungsgeschwindigkeiten zu beseitigen. Mit dieser Zielsetzung im Hintergrund verwundert es nicht, dass Playwright im Gegensatz zu den anderen Testing-Tools nicht auf Selenium Webdriver aufsetzt, sondern über eine eigene Implementierung zur Browser-Steuerung verfügt. Unterstützt werden dabei die aktuellen Browser Engines von Chromium, Firefox und WebKit, jeweils auf Windows, Linux und MacOS. Ältere Versionen können unter Verwendung älterer Playwright-Versionen eingebunden werden, seit Kurzem können auch generische Chromium-Builds (Edge und Chrome) verwendet werden. Support für Mobilgeräte ist aktuell nur per Emulation bestimmter Gerätekonfigurationen wie Auflösung und User-Agent möglich, ein Testen auf echten Geräten ist derzeit nicht möglich.

Das Feature Set umfasst neben Standardoperationen auch Funktionen, die in anderen Frameworks fehlen oder nur per Workaround realisiert werden können. So stehen neben Clicks, Scrolling, Selections usw. auch Drag-and-Drop, Interaktionen im Shadow-Dom und Synchronisierung mit Animationen zur Verfügung.

Im Hinblick auf Performance und Ausführungsgeschwindigkeit verhält sich Playwright wesentlich schneller als Protractor und andere seleniumbasierte Testframeworks. In unseren Tests konnten wir auch bei mehreren Testinstanzen im Parallelbetrieb keine Probleme in Hinblick auf Flakiness oder unerwartete Abbrüche feststellen. Abschließend lässt sich sagen, dass Microsoft mit Playwright ein modernes und auf die Anforderungen modernen UI-Testings ausgerichtetes Framework vorgelegt hat, das trotz seiner kurzen Zeit am Markt bereits viele Fürsprecher gewonnen hat und wohl auch in Zukunft noch an Bedeutung gewinnen wird.

ProContra
+ schnell
+ stabil
+ großes Featureset
–        Aktuell nur eingeschränkter Support für BrowserStack
–        Kein Support für echte Mobilgeräte
Tabelle 2: Vor- und Nachteile des Tools Playwright

Webdriver.io

Webdriver.io ist mit über sieben Jahren am Markt eines der langlebigsten Automatisierungstools im Testfeld. Die Macher beschreiben das Design ihres Testframeworks als erweiterbar, kompatibel und reich an Features, was sich bei genauer Begutachtung auch bewahrheitet:

Bei Webdriver.io handelt es sich um ein Selenium-basiertes Testframework, welches die darauf beruhende WebDriver API des W3C implementiert. Dadurch wird die Kompatibilität mit allen modernen Browsern (und IE) gewährleistet, die eine eigene Treiberimplementierung bereitstellen. Darüber hinaus wird auch das Testen von Webanwendungen auf mobilen Geräten sowie nativen Apps ermöglicht.

Im tagtäglichen Einsatz zeigen sich weitere Stärken des Frameworks: Ein großer Fundus an Hilfsmethoden und syntactic sugar macht das Formulieren von Testschritten und Erwartungen deutlich einfacher und lesbarer, als man es von Protractor gewöhnt war. Hervorzuheben sind dabei u. a. der Zugriff auf ShadowRoot-Komponenten via shadow$, die vielseitigen Einstellungsmöglichkeiten der Konfiguration (u. a. automatische Testwiederholungen im Fehlerfall) und das Warten auf erscheinende bzw. verschwindende DOM-Elemente. Sollte dennoch mal eine Funktion nicht verfügbar sein, lässt sich diese als custom command implementieren und anschließend genauso wie die mitgelieferten Funktionen verwenden.

Bei aller Lobpreisung gibt es dennoch einen Wermutstropfen: Im Vergleich zu anderen Frameworks ist die Testausführung aufgrund der Selenium-basierten Implementierung recht langsam, jedoch kann die Ausführung auch parallelisiert werden.

ProContra
+ Vielseitige Kompatibilität
+ Ausgezeichnete Dokumentation
+ Zahlreiche Hilfsmethoden und syntactic sugar
–        Testausführung langsamer als in andere Frameworks
Tabelle 3: Vor- und Nachteile des Tools Webdriver.io

TestCafé

Bei TestCafé handelt es sich um einen weniger verbreiteten Kandidaten im Testfeld. Die bereits erwähnte Umfrage in der Angular Community ergab einen Nutzungsanteil von unter 1%. Das erste Stable-Release erschien 2018, gegenwärtig befindet sich die Anwendung in Version 1.19. Das Versprechen eines einfachen Setups und die Unabhängigkeit von WebDriver war für uns ein Grund, etwas genauer unter die Haube zu schauen. Stattdessen verwendet TestCafé einen umgeschriebenen URL-Proxy namens Hammerhead, der Befehle mithilfe der DOM-API emuliert und JavaScript in den Browser injiziert.

Unterstützt werden derzeit alle gängigen Browser und die mobilen Versionen von Chrome und Safari. Hervorzuheben ist dabei die Möglichkeit, Tests auf echten Mobilgeräten im gleichen Netzwerk auszuführen zu können. Die Testausführung mit BrowserStack ist ebenfalls möglich. Zu erwähnen ist an dieser Stelle auch, dass zusätzlich eine dezidierte Entwicklungsumgebung (TestCafé Studio) existiert, in der es auch möglich ist, mit wenig Programmierkenntnis Testfälle zu erstellen und aufzunehmen.

ProContra
+ schnell
+ Vielseitige Kompatibilität (auch für mobile Browser und Endgeräte)
+ großes Featureset
–        Geringe Verbreitung
–        Testrecorder-Tool nur kostenpflichtig
Tabelle 4: Vor- und Nachteile des Tools TestCafe

Gegenüberstellung

Bei der Wahl eines Testframeworks ist es zunächst wichtig, die eigenen Projektanforderungen zu kennen. Hierbei können folgende Fragestellungen nützlich sein:

  • Welche Browser sollen unterstützt werden?
  • Sollen verschiedene Browserversionen getestet werden?
  • Ist Unterstützung für mobile Geräte erforderlich?
  • Können die Kernfunktionen der Anwendung mittels des Frameworks getestet werden?

Die folgende Tabelle kann bei der Orientierung der Wahl eines Testframeworks helfen.

KriteriumCypressPlaywrightWebdriver.ioTestCafé
Browser-Support (und Versionen)o++ ++ +
Mobile Support+ ++ + ++ +
Funktionsumfang+ + ++ ++
Testgeschwindigkeit+ + o+
Migration von Protractoroo+ +
Zukunftssicherheit+ ++ + o
Tabelle 5: Vergleich der Test-Tools nach verschiedenen Kriterien

Fazit

Die Landschaft an Testframeworks ist sehr vielseitig und es ist oft nicht einfach, die richtige Entscheidung zu treffen. Für Projekte mit beispielsweise geringen Testanforderungen, das Testen gegen wenige und ausschließlich aktuelle Browser, bei denen eine schnelle Testausführung von Vorteil ist, empfehlen wir die Verwendung von Playwright.

Handelt es sich allerdings um ein Projekt, in dem eine Migration von Protractor durchgeführt werden muss und es wichtig ist, gegen viele Browser, in unterschiedlichen Versionen und auf mobilen Endgeräten zu testen, empfehlen wir Webdriver.io.

Quellen

Dieser Beitrag wurde verfasst von:

Stefan Heinze

Stefan Heinze arbeitet seit 2011 als Software-Entwickler bei der ZEISS Digital Innovation in Dresden. Derzeit beschäftigt er sich mit Angular-Anwendungen und Azure-Backend-Entwicklung im Medizinbereich. Dabei gilt ein erhöhtes Augenmerk auf die Automatisierung von Oberflächentests zur Sicherstellung der Softwarequalität.

Alle Beiträge des Autors anzeigen

Testautomatisierungstool aus dem Katalog – Wie finde ich das perfekte Werkzeug?

Softwaresysteme werden durch die stetig wachsende Anzahl von Anwendungen auf unterschiedlichen Plattformen immer komplexer. Ein entscheidender Faktor für den Erfolg eines Softwareprodukts ist dessen Qualität. Daher führen immer mehr Unternehmen systematische Prüfungen und Tests möglichst auf den verschiedenen Plattformen durch, um einen vorgegebenen Qualitätsstandard sicherstellen zu können. Um trotz des höheren Testaufwands kurze Release-Zyklen einhalten zu können, wird es notwendig, die Tests zu automatisieren. Dies wiederum führt dazu, dass eine Testautomatisierungsstrategie definiert werden muss. Einer der ersten Schritte bei der Einführung einer Testautomatisierungsstrategie ist die Evaluierung von geeigneten Testautomatisierungswerkzeugen. Da jedes Projekt einzigartig ist, variieren sowohl die Anforderungen als auch die Wahl der Werkzeuge. Diese Blogreihe soll eine Hilfestellung bei der Auswahl der passenden Lösung geben.

Symbolbild: Zwei Personen sitzen am Tisch und schauen auf ein Tablet, unter dem Tablet liegen ausgedruckte Statistiken sowie Notizbücher auf dem Tisch.
Abbildung 1: Zur Einführung einer Testautomatisierungsstrategie gehört auch die Evaluierung geeigneter Testautomatisierungswerkzeuge

Einführung

Im Rahmen meiner Abschlussarbeit übernahm ich die Aufgabe, den Scrum-Teams der ZEISS Digital Innovation (ZDI) ein Hilfsmittel an die Hand zu geben, mit dem sie das passende Testautomatisierungswerkzeug schnell und flexibel finden können. Die Herausforderung bestand dabei darin, dass die Projekte spezifische Szenarien besitzen und die Anforderungen gegebenenfalls gesondert gewichtet werden müssen. Den Stand der Arbeit und die Ergebnisse möchte ich euch in diesem und den nächsten Blogartikeln vorstellen.

Die Softwareentwicklung ist schon seit langem ein Bereich, der sich schnell verändert. Doch während diese Entwicklungen in der Vergangenheit vor allem auf technologischer Ebene stattgefunden haben, beobachten wir derzeit größere Veränderungen im Bereich der Prozesse, der Organisation und der Werkzeuge in der Softwareentwicklung. Diese neuen Trends sind jedoch mit Herausforderungen verbunden wie z. B. Änderungen im Anforderungsmanagement, verkürzten Timelines und speziell den gestiegenen Anforderungen an die Qualität. Durch die Entwicklung bedarfsgerechter Lösungen und die Optimierung der Qualität werden heute sowohl die Effizienz als auch die Effektivität innerhalb der Softwareentwicklung gesteigert.

Zudem werden Softwaresysteme durch die stetig wachsende Anzahl von Anwendungen auf unterschiedlichen Plattformen immer komplexer. Da die Qualität ein entscheidender Faktor für den Erfolg eines Softwareprodukts ist, führen immer mehr Unternehmen systematische Prüfungen und Tests möglichst auf den verschiedenen Plattformen durch, um einen vorgegebenen Qualitätsstandard sicherzustellen. Eine Anfang 2021 durchgeführte SmartBear-Umfrage ergab, dass viele Unternehmen, unabhängig von der Branche, bereits verschiedene Arten von Tests durchführen, wobei das Testen von Webanwendungen mit 69 % an erster Stelle und das Testen von API/Webdiensten mit 61 % an zweiter Stelle steht. Das Desktop-Testing wird von 42 % der Befragten durchgeführt. Insgesamt 62 % der Befragten geben an, dass sie mobile Tests durchführen, davon 29 % für native Applikationen (Apps) (SmartBear, 2021, S. 12). Um trotz des höheren Testaufwands kurze Release-Zyklen einhalten zu können, wird es notwendig, die Tests zu automatisieren.

Als ZDI unterstützen wir unsere Kunden innerhalb und außerhalb der ZEISS Gruppe bei ihren Digitalisierungsprojekten. Zusätzlich bieten wir individuelle Testservices an. Darum gibt es bei uns eine Vielzahl von Projekten mit unterschiedlichen Technologien und unterschiedlichen Lösungen. Als kleine Auswahl sind hier Schlagwörter wie Java, .Net, JavaFX, WPF, Qt, Cloud, Angular, Embedded etc. zu nennen. Bei solchen komplexen Projekten steht die Qualitätssicherung immer im Vordergrund und die Projekte sind abhängig vom Einsatz moderner Testwerkzeuge, welche die Projektbeteiligten bei den manuellen, aber besonders bei den automatisierten Tests unterstützen. Dabei wäre ein Werkzeug wünschenswert, das diese Automatisierung effektiv und effizient unterstützt. Testerinnen und Tester stehen jedoch bei der Auswahl eines Testautomatisierungswerkzeugs vor einer Vielzahl von Herausforderungen.

Herausforderungen

Bei der Recherche und den Interviews im Rahmen meiner Arbeit wurden als größte Herausforderungen bei der Testautomatisierung die Vielfalt der verfügbaren Testwerkzeuge und die fortschreitende Fragmentierung des Marktes genannt. Aufgrund dieser Fragmentierung stehen für den gleichen Einsatzzweck eine Vielzahl von Werkzeugen bereit.

Die Auswahl wird noch schwieriger, da sich die Werkzeuge nicht nur in der Technologie unterscheiden, die sie testen können, sondern auch im Arbeitsansatz. Wenn von Automatisierung die Rede ist, wird sie immer mit Skripting in Verbindung gebracht. In den letzten Jahren wurde jedoch ein neuer Ansatz für GUI-Tests entwickelt, der als NoCode/LowCode bezeichnet wird. Dieser Ansatz erfordert grundsätzlich keine Programmierkenntnisse und ist daher auch bei Automatisierungseinsteigern beliebt. Trotzdem bleibt das Skripting die dominierende Methode, obwohl manchmal beide Ansätze verwendet werden, um möglichst viele aus dem Qualitätssicherungsteam einzubeziehen (SmartBear, 2021, S. 33).

Die Art und Weise des Testautomatisierungsansatzes und damit der Einsatz eines Testautomatisierungswerkzeugs sind abhängig von den Anforderungen im Projekt. Dies bedeutet, dass die Anforderungen bei jedem neuen Projekt immer wieder neu geprüft werden müssen.

Bestandsaufnahme

Im Rahmen der Interviews, der Analyse des aktuellen Vorgehens und der Auswertung einer internen Umfrage konnte ich folgende Vorgehensweisen für die Auswahl der Werkzeuge in den Projekten identifizieren, die sich als „Quasi-Standard“ etabliert haben:

  • Das Werkzeug ist Open Source und kostet nichts.
  • Es wurde mit dem Werkzeug schon einmal gearbeitet und es wurde als vertrauenswürdig eingestuft.

Ein Ziel der Umfrage war es, herauszufinden inwieweit die Projektsituation einen Einfluss auf die Toolauswahl hat. Darum wurden im nächsten Schritt die Projekt-Situationen bzw. die verwendeten Vorgehensmodelle der Projekte und deren Einfluss untersucht. Es zeigte sich, dass nicht die Vorgehensmodelle einen direkten Einfluss auf die Toolauswahl haben, sondern die Personen oder Gruppen, die als zukünftige Anwender das Werkzeug nutzen oder die den Einsatz freigeben.

Bei der Überprüfung des Einflusses dieser operativ-eingebundenen Beteiligten zeigte sich, dass es noch weitere Interessengruppen gibt, die direkt oder indirekt einen Einfluss auf die Auswahl eines Werkzeuges haben. Dies sind z. B.:

  • Softwarearchitektinnen und Softwarearchitekten, die die Technologie oder Tool-Ketten innerhalb des Projektes definieren,
  • das Management, das Vorgaben festlegt für den Einkauf oder die Verwendung der Werkzeuge (OpenSource, GreenIT, strategische Partnerschaften etc.) oder
  • die IT des Unternehmens, die durch die verwendete Infrastruktur den Einsatz bestimmter Werkzeuge verhindert (FireWall, Cloud etc.).

Darüber hinaus fanden sich bei den Recherchen bereits erste Ansätze von Checklisten für die Auswahl von Testwerkzeugen. Sie basierten meist auf wenigen funktionalen Kriterien und wurden in Workshops durch die Projektmitglieder bestimmt. Die Auswertung zeigte, dass es keine einheitliche Methode gibt und dass die so ausgewählten Tools sehr oft später durch andere Werkzeuge ersetzt wurden. Dies wurde notwendig, da bei der Auswahl notwendige Anforderungen an das Werkzeug übersehen wurden.

In der Mehrzahl der Fälle waren die vergessenen Anforderungen nicht-funktionaler Natur, wie z. B. Kriterien der Usability oder Anforderungen an die Performance. Darum war ein nächster Schritt bei der Prüfung relevanter Kriterien, die ISO/IEC 25000 Software Engineering (Qualitätskriterien und Bewertung von Softwareprodukten) heranzuziehen.

Nicht immer, aber sehr oft, waren die übersehenen Anforderungen nicht-funktionaler Natur. Darum war ein nächster Schritt bei der Prüfung relevanter Kriterien, die ISO/IEC 25000 Software Engineering (Qualitätskriterien und Bewertung von Softwareprodukten) heranzuziehen.

Schematische Darstellung der Kriterien der ISO/IEC 25000 Software Engineering
Abbildung 2: Kriterien für Software nach ISO/IEC 25010

Im nächsten Blogartikel dieser Reihe wird aufgezeigt, wie der Kriterienkatalog aufgebaut ist und wie sich die finale Liste der Kriterien zusammensetzt.


Literatur

SmartBear (2021): State of Software Quality | Testing.

Dieser Beitrag wurde fachlich unterstützt von:

Kay Grebenstein

Kay Grebenstein arbeitet als Tester und agiler QA-Coach für die ZEISS Digital Innovation, Dresden. Er hat in den letzten Jahren in Projekten unterschiedlicher fachlicher Domänen (Telekommunikation, Industrie, Versandhandel, Energie, …) Qualität gesichert und Software getestet. Seine Erfahrungen teilt er auf Konferenzen, Meetups und in Veröffentlichungen unterschiedlicher Art.

Alle Beiträge des Autors anzeigen