Wie in anderen Bereichen der Produkteentwicklung besteht mittlerweile auch in der Welt des Testens eine schier unüberschaubare Anzahl von Tools. Diese übertreffen sich gegenseitig mit Features. Doch – und das liegt auf der Hand – nicht alles bringt tatsächlich einen Mehrwert. Bringen dedizierte Tools für Testing denn überhaupt einen Nutzen?
Einverstanden, Testautomation ohne Tool geht nicht. Beim Rest könnte man sich aber auch einfach nur mit MS Office behelfen oder sich bei spezifischen Problemen einer Freeware bedienen. Und das Handling lernen die Mitarbeiter sowieso «on the fly» – fertig ist Toolstrategie und schon ist viel Geld gespart… oder doch nicht?
Das Werkzeug im Test
Allgemein
Später als in anderen Disziplinen haben sich Testwerkzeuge einen Markt erschlossen. Ein Markt, der für viele Unternehmen als nicht zwingend notwendig investiertes Kapital bedeutete. Warum ist nachvollziehbar, galt Testing selbst doch lange Zeit als das notwendige Übel schlechthin. Infolgedessen wurden Werkzeuge eher nach Budget und von nicht-testversierten Personen mit falschen Vorstellungen eingekauft. Sie wurden dann so implementiert, dass eine effiziente Nutzung auf der Strecke blieb.
Doch die immer komplexeren, schnelleren und vernetzten Funktionen und Datenkonstrukte müssen getestet werden. Dies lässt sich jedoch mit dem bestehenden Toolset kaum bewerkstelligen. Gute Beispiele hierfür sind die künstliche Intelligenz, die Blockchain, das Cloud-Computing – um nur einige zu nennen. Aber so weit müsste man gar nicht gehen. Denn schon heute hat das Testing und ihre Werkzeuge massive Herausforderungen zu lösen, um die Qualität sicherzustellen. Am Ende wird oft mit grossem Restrisiko eingeführt.
Falls es dennoch besser möglich sein sollte: Wie, wenn nicht entsprechend toolunterstützt, soll das in der verfügbaren Zeit professionell, methodisch und automatisiert umgesetzt werden?
Test-Disziplinen
Mit steigender Anzahl der Disziplinen und Technologien steigen auch die Bedürfnisse, eben diese zu testen. Es lassen sich folgende Gruppen bilden: Werkzeuge für ...
- das Management des Testens und für Testmittel
- statische Tests (Review von Code oder Anforderungen)
- (methodisches) Testdesign und -Spezifizierung
- manuelle und automatisierte Testdurchführung und -Protokollierung
- die Performance Messung und dynamischen Analyse (Last, Stress, Volumen)
- für spezielle Testbedürfnisse
- Security-Tests (Leaks, Fraud-Attack)
- Datenqualität (Vollständigkeit, Korrektheit, Konsistenz, Integrität)
- Usability-Testing
- Werkzeuge und Simulatoren für KI-Testing
- und viele mehr…
(Bild: SwissQ, Trends & Benchmarks 2020)
(Bild: SwissQ, Trends & Benchmarks 2020)
Vermeidbare Fehleinschätzungen und Fehlhandlungen
Fehleinschätzungen sind praktisch in allen Firmen und Branchen anzutreffen.
Folgende Kapitel sind nicht abschliessend.
1. Toolstrategie und Kosten
Der Abgleich zwischen
- «Wo stehe ich?»
- «Welche Tools habe ich schon und was können sie?»
- «Wo will ich hin und was brauche ich dazu?»
wird auffällig häufig unvollständig angegangen. Zudem: Der Ansatz: «für jedes Problem ein Tool» ist zwar rückläufig, dennoch immer wieder anzutreffen.
Fakt: Ein Werkzeug, welches disziplinübergreifend eingesetzt werden kann mag zwar mehr kosten, schont aber letztendlich im Betrieb die finanziellen Mittel. Warum ist das so und wo entsteht ein Mehrwert? Hier die wichtigsten Argumente:
- Steigerung der Produktivität wie
- Erhöhung der (Test-)Geschwindigkeit, was wiederum die
- Erhöhung der Tests (Menge und Durchführung) ermöglicht
- Verhinderung von Redundanzen, Inkompatibilität und Missverständnissen, da keine Schnittstellen zwischen mehreren Tools vorhanden sind
- Professionelles und methodisch strukturiertes Arbeiten
- Einheitliches Reporting (kein Mix aus unterschiedlichen Quellen)
- Zentral gebündeltes Know-how (kein Spezialwissen bei einzelnen Personen)
- Vereinfachte Strategie, Tool-Kette und Verwaltung von Werkzeugen und Benutzern
Wichtig: Die Lizenzkosten von Testtools machen heutzutage weniger als 10% der Gesamttestkosten aus, Tendenz sinkend. Bei der Werkzeugwahl wird den Lizenzkosten dennoch meist überproportional viel Gewicht beigemessen – das ist nicht zu Ende gedacht.
2. Die Toolevaluation und Integration
Der Weg zu einem geeigneten Werkzeug hat viele Fallgruben. Ein Fehlentscheid kann grosse Konsequenzen haben, angefangen bei den Kosten bis hin zu Projektverzögerungen. Das allseitig empfohlene Vorgehen, nämlich
- Erstellung von Anforderungen (unter Berücksichtigung der Gesamtstrategie) und deren Priorisierung
- Proof of Concepts (PoCs) mit repräsentativen Kandidaten
- Neutrale Fachliche und technische Bewertung
- Entscheid
- Pilotphase/ Pilotprojekt
- Schrittweises Ausrollen
wird nur allzu oft nicht sauber eingehalten oder durch Befangenheiten (nicht neutrale Betrachtung, falsche Präferenzen, etc.) getrübt.
Methodisch-strukturiertes Vorgehen
Es ist in vielen Testvorhaben kein Gegenstand von Diskussionen, wie Testfälle entstehen. Auch nicht, welche funktionale und risikobasierte Abdeckung (also Wirksamkeit) sie tatsächlich besitzen. Eine Todsünde. Warum ist das also so? Wegen fehlenden Kompetenzen der beteiligten Personen. Meist aber auch wegen der fehlende Möglichkeit, Testfälle strukturiert und methodisch entwerfen zu können, ihre Abdeckung transparent zu machen und sie fachlich korrekt zu priorisieren. Das richtige Werkzeug könnte dies jedoch ändern und ggf. auch ein Umdenken herbeiführen.
Der falsche Selfmade-Ansatz Teil 1: Frameworks
Ein Testautomationsframework ist ein selbstentwickeltes Konstrukt von mehreren Tools in Verbindung mit Programmierlogik. Die Art, ein eigenes Framework in der Testautomation zu verwenden, ist über 20 Jahre alt und noch immer stark verbreitet. Es sollte das unflexible und instabile «Play & Record» von Scripts (Aufnahme und Abspielen einer Benutzersequenz) ablösen. Das wurde schon in den 80er-Jahren in MS Word und Excel als Feature angeboten. Tatsache ist, dass «Play & Record»-Automatisierung noch immer mehr als 25% aller Testautomation ausmachen(!). Wie sinnvoll und effektiv dies ist, ist jedoch unklar.
Im (technischen) Unit Test zur Verifikation von Modulen und Klassen sind Frameworks gut einsetzbar. Sie haben aber trotz Flexibilität und Anpassungsfähigkeit bei Integration-, System- und Abnahmetests nur noch bedingt Vorteile.
- Teuer – Ein Framework ist sozusagen ein «Projekt im Projekt». Es muss also neben dem eigentlichen Produkt ständig mit- und weiterentwickelt werden.
- Zu technisch – Um ein Framework zu bauen und zu betreiben, ist viel technisches Know-how zwingend erforderlich. Dies schafft grosse Abhängigkeiten, den Bau, die Wartung, und nicht zu vergessen, der Betrieb hängt oftmals an nur einer Person. Ist der Experte nicht oder nicht mehr verfügbar, fällt die gesamte Testautomation also aus.
- Limitierend – In der Zeit, in der ein Framework gebaut und vor allem später gewartet werden muss, lassen sich parallel keine weiteren Tests automatisieren, denn die Ressource Testautomatisierer macht beides. Somit drückt das Framework die mögliche Automationsrate (teilweise drastisch!) nach unten.
Schon seit vielen Jahren gibt es Technologien auf dem Markt, welche Scripting, also das Programmieren von automatisierten Tests, fast oder ganz überflüssig machen: Die objekt-basierte Automation. Dass diese Art von Tools die script-basierten Werkzeuge noch nicht komplett abgelöst haben, liegt meines Erachtens an drei Gründen.
Die Gründe:
- Die «Sunk-Cost Fallacy» (auch bekannt als «Concord-Effekt») - Wider besseres Wissen, dass es bessere Lösungen gäbe. Man hat schon so viel in die bestehende Automation investiert. Man will da nicht alles über Bord werfen und von Neuem beginnen.
- Die Kosten – Diese Werkzeuge liegen im Preis bei Anschaffung und bei Lizenz deutlich über den Einzelnen in den Frameworks. Man bleibt also lieber bei der (scheinbar) günstigeren Lösung.
- Der Treiber Technik – Bisher war Automation die Domäne der technik-affinen Mitarbeitern. Warum ein Tool einsetzen, welches das bestehende Framework (die eigene Arbeit) in Frage stellt oder gar ersetzt?
Der falsche Selfmade-Ansatz Teil 2: Fehlende oder falsche Beratung
Die Risiken eines möglichen Fehlgriffs (praktisch einer oder mehrere obig erwähnte Punkte) liessen sich dramatisch senken. Dies, wenn man sich jemanden zurate holen würde, der/die sich damit auskennt. Auch hier wird zu stark kurzfristig finanziell gedacht. Man zahlt dann die viel höhere Zeche. Hier lohnt sich jemand «von Aussen». Jemand, der nicht nur den Blick eines Sponsors hat, sondern mit der Umsicht auf alle aktuellen und kommenden Bedürfnisse. Dies ist für jemanden mit dem Projektfokus unsichtbar. Soll der Mehrwert die Projektphase überdauern oder auch über die Abteilung hinausgehen, bedarf es einer unabhängigen Einschätzung und einer entsprechenden Kompetenz.
Wichtig: das Unternehmen tut gut daran sicherzustellen, dass der Beratungsprozess nicht von Tool-Vendoren beeinflusst wird. Hersteller von Werkzeugen zahlen gerne sogenannte «Kick-backs», welche natürlich einen Einfluss auf die Partnerschaft und die Beratungsfirma haben. Der Kunde profitiert nicht davon und trägt lediglich das Risiko bei einer unpassenden Empfehlung.
Der Faktor der Motivation
Dass einem die Arbeit mit einem guten, zeitgemässen und an die Bedürfnisse angepassten Werkzeug mehr Freude macht, ist wohl unbestreitbar. Die daraus entstehende Motivation und letztendlich Produktivität sollte unbedingt in die Kalkulation – wenn auch schwer zu beziffern – miteinfliessen. Gerade deswegen halte ich dieses Argument für absolut erwähnenswert.
Summary
Fakt 1
«Um das Beste aus einem Testprojekt herauszuholen, müssen Tester und Testtool eingespielt und ideal auf die entsprechenden Herausforderung abgestimmt sein. Die Tool-Kompetenz ist dabei absolut matchentscheidend.»
Fakt 2
Freeware oder viele günstige Tools ersetzen kein umfängliches Werkzeug. Wer dies nicht glaubt oder wer denkt, anders könne Geld gespart werden, dem wird dringend empfohlen, einmal eine Gesamtrechnung der Kosten und den dabei entstehenden Abhängigkeiten, Redundanzen und Schnittstellen zu machen.
Fakt 3
Die Zeiten der einfachen Problemstellungen im Test sind vorbei. Testing wird aber noch viel zu häufig mit rudimentären Hilfsmitteln und Know-how angegangen. Anstelle von Mehrwert werden meist nur Kosten gesehen. Dabei steht eines fest: Die Disziplinen der Zukunft sowie dessen Qualitäts- und Time-to-Market-Anspruch sind ohne adäquate Werkzeuge gar nicht mehr zu leisten.
Quellen
