Teil 2/2

Die Zukunft der Testautomatisierung

Serie

Vom Buzzword zur Challenge: Herausforderungen für A2A.TAF in den kommenden Monaten und Jahren! Dieser zweite Teil über die Zukunft der Testautomatisierung mit A2A beschäftigt sich mit Themen wie Fuzz Testing, Automatisiertes Usability und Accessibility Testing und Machine Learning.

Teil 1 hat sich mit dem aktuellen Stand der Technik und von A2A beschäftigt – mit den gemeisterten Herausforderungen und den entstandenen Lösungen. Es wurden einige zukunftsträchtige Themen (die viele unter dem Schlagwort „Digitalisierung“ zusammenfassen) betrachtet, die auf die Disziplin „Testautomatisierung“ und damit auch auf uns und unser A2A.TAF zukommen:

Anzeige
  • Mehrdimensionale Analysierbarkeit von Testergebnissen zur umfassenden und effizienten Analyse von automatisierten Testläufen
  • Property Based Testing als griffige Alternative zur Ablauf-basierten Testautomatisierung
  • Hochgradig Skalierbare und Enterprise-orientierte Testautomatisierung zur Bewältigung von Herausforderungen in komplexen, kleinteiligen und heterogenen Systemlandschaften

Dieser Teil beschäftigt sich mit drei weiteren Themen, mit denen man sich derzeit auseinandersetzt, und die uns auch in Zukunft beschäftigen werden:

  • Fuzz Testing
  • Automatisiertes Usability und Accessibility Testing
  • Machine Learning

Fuzz Testing

Unter „Fuzz Testing“ oder auch „Fuzzing“ versteht man gemeinhin Tests mit zufälligen Daten, um ein System hinsichtlich Robustheit zu untersuchen, also auf Abstürze, Memory Leaks, oder auch auf ausreichende Plausibilitätsprüfungen. Daher ist Fuzz Testing speziell für Robustheit, Performance und Security Testing relevant und verbreitet.

Aber auch im funktionalen Test sehen wir großes Potential, auch wenn diese Art von Tests traditionellen, rein spezifikationsbasierten Testern zunächst ungewohnt erscheinen mag:

Häufig werden Zufallstests im funktionalen Test belächelt, weil sie in den meisten Fällen nicht zielgerichtet (sprich: zufällig) ablaufen, und sie daher keine Aussage über die Testabdeckung zulassen. Darüber hinaus gibt es oft keine, oder nur eine sehr großzügige Validierung der Ergebnisse, da ja die Input-Parameter im Vorhinein nicht bekannt sind.

Allerdings wäre es hilfreich, zumindest zusätzlich zu klassischen Regressionstests eine gewisse Randomisierung in der Testdurchführung zu haben. Denn: Manuelle Tester sind nicht nur deswegen effektiv, weil sie Testfälle 1:1 abarbeiten, sondern auch deswegen, weil sie vom Standard-Pfad abweichen. Alle möglichen Pfade automatisiert abzudecken ist nicht realistisch. Aber durch gezielte Zufälligkeit die systematische Testabdeckung zu ergänzen ist eine vielversprechende Option. Speziell, wenn dafür kaum Mehraufwand notwendig wäre. Daher wollen wir auf einen stark hybridisierten Ansatz mit klassischen Methoden aus dem Testdesign setzen, der z.B. so aussehen kann:

Inputs:

  • Inputs werden in Äquivalenzklassen unterteilt, also Wertebereiche, auf die das System ähnlich reagieren sollte (sowohl gültige als auch ungültige).
  • Bei der Testdurchführung wird automatisiert und „fuzzy“ also in diesem Fall entsprechend einer statistischen Verteilung zufällig ein Repräsentant aus dieser Klasse gewählt.
  • Dieser Repräsentant kann auch entsprechend einer Gaußschen Verteilung um einen Happy-Value (also einen Standard-Wert, z.B. ein sehr häufiger Wert aus der realen Welt) herum gewählt werden.

Outputs:

  • Auch Output Daten werden einer Äquivalenzklassenanalyse unterzogen.
  • Bestimmte Kombinationen von Inputs werden bestimmten Klassen von Outputs zugeordnet.
  • Bei der Durchführung findet eine Validierung des Ergebnisses hinsichtlich des Soll-Wertebereichs statt.

Damit ist es möglich, konkrete Ergebnis-Werte nicht nur grob, sondern auch – je nach Feinheit der Äquivalenzklassen – sehr scharf und trotzdem „fuzzy“ auswerten zu können.

Dem aufmerksamen Leser werden in dieser Lösungsform Ähnlichkeiten zum Property-Based-Testing aufgefallen sein. Das ist kein Zufall: In unserer Planung wollen wir zunächst unsere Lösung in Richtung Property-Based-Testing weiterentwickeln, um dann unter innerhalb des definierten Property-Modells ein Fuzzing der Input- und Output-Daten zu ermöglichen. Das ermöglicht uns, die gezielten Tests aus dem Property-Based Testing mit geringem Mehraufwand um Fuzz Tests zu ergänzen.

Darüber hinaus gibt es sehr vielversprechende Kombinationsmöglichkeiten mit Machine-Learning, um wirksame Inputs zu finden, aber vor Allem auch die Ergebnisse zu validieren.

Fuzz Testing ist im Kern keine neue Errungenschaft – für A2A.TAF bedeutet es allerdings, zusätzlich zu den von den von uns so sehr gewohnten und gewollten messerscharfen Methoden auch mit einem sinnvollen Grad an Unschärfe umgehen zu können.

Automatisiertes Usability & Accessibility Testing

Neben Funktionalität ist bei manuellen Testern der zweite wesentliche Software-Qualitäts-Aspekt meistens die Benutzbarkeit, also Usability des zu testenden Systems. Leider ist dieser Aspekt im automatisierten Regressionstest bisher nur schwer integrierbar gewesen. Behelfe wie Screenshots oder Videos der Testdurchläufe (mit anschließendem Durchsehen durch einen Tester) erlauben zwar eine Teilautomatisierung dieser Tests, sind aber letztendlich fehleranfällig und vor allem kein effizienter Einsatz von hochqualifizierten Personen.

Auch für Accessibility, also Barrierefreiheit, gibt es kaum befriedigende Lösungen. Konformitätsüberprüfungen können zwar z.B. Überprüfen, ob zu jedem Bild auch eine textuelle Beschreibung als Alternative hinterlegt wurde – sie können aber nicht bewerten, ob diese auch sinnvoll ist (geschweige denn, dass sie den Inhalt des Bildes ausreichend reflektiert).

Darüber, dass beide dieser Faktoren wesentlich für eine Applikation sind, gibt es zahlreiche Studien und viel Literatur. Accessibility ist ausschlaggebend für einen wesentlichen Anteil der Weltbevölkerung, während Usability insgesamt einen großen Anteil an der Nutzerzufriedenheit, und damit auch maßgeblich am wirtschaftlichen Erfolg einer außenwirksamen Lösung, hat.

Daher haben wir (wie viele andere auch) uns die Frage gestellt, welche Möglichkeiten zur Automatisierung es gibt. Und wieder treffen wir auf Technologien und Konzepte, die wir in diesem Artikel bereits beschrieben haben.

Was macht diese Tests so schwer automatisierbar? Die Frage, ob z.B. ein Webshop ansprechend gestaltet und gut benutzbar ist, hängt immer auch mit den persönlichen Vorlieben des Benutzers zusammen.

Hier können Regeln und Heuristiken angewandt werden – die Letzteinschätzung hängt aber immer vom Endbenutzer selbst ab. Widmen wir uns also dem, was wir konkret adressieren können:

  1. Regeln: z.B. „Texte und Komponenten sollen sich nicht überschneiden“, „Schrift soll ausreichend Kontrast zum Hintergrund haben“
  2. Inhalte: z.B. „Bilder sollen eine alternative textuelle Beschreibung haben, die den Inhalt des Bildes reflektiert“
  3. Layout-Stabilität: z.B. „Das Layout der Applikation soll sich nicht grundlegend verändern“, „bestimmte Elemente sollen an entsprechenden Stellen sichtbar sein und einer vorgegebenen Darstellungsform entsprechen“

Für die Validierung der Einhaltung von Regeln gibt es Werkzeuge, die gewisse Gesichtspunkte automatisch untersuchen, z.B. WAI-Konformitäts-Checker. Aber auch mit Property-Based-Testing sind solche Regeln gut abbildbar.

Die Validierung von Inhalten ist schwieriger, und mit klassischen Methoden nicht effektiv umsetzbar. Ein vielversprechender Ansatz hierfür ist die Anwendung von Machine Learning, um z.B. zu überprüfen, ob die textuelle Beschreibung eines Bilds zumindest die darin abgebildeten Elemente enthält (z.B. „Gebäude“). Die Kernaussage und Intention des Bildes zu erfassen, erscheint uns aber derzeit noch als Zukunftsmusik, und überlassen diese Überprüfung daher derzeit manuellen und Reviews durch Experten.

Konzentrieren wir uns daher auf den Aspekt, den wir einerseits noch nicht durch bereits behandelte Konzepte abdecken, und der uns als sinnvolle Erweiterung zu unserem derzeitigen Vorgehen erscheint:

Für den Check von „Layout-Stabilität“ gibt es das Konzept des „Visual Regression Testing“. Dieses Konzept kombiniert Elemente aus dem automatisierten Regressionstest von Benutzeroberflächen (die wir sehr gut kennen und können) mit Elementen aus dem automatisierten Bildervergleich. So werden z.B. während automatisierten Regressionstests Screenshots gemacht, und diese mit vorhergehenden, „abgenommenen“ (also als „korrekt“ bestätigten) Screenshots verglichen. Oft werden hierbei Toleranzen angewandt, um non-deterministische Elemente des Testdurchlaufs auszublenden, also z.B. einer unterschiedlichen Bestellnummer. Über die Toleranzen hinausgehende Abweichungen werden in der Regel als Fehler registriert, und mit beiden Screenshots, sowie einer Differenzdarstellung dokumentiert. Häufig wird dabei auch das User Interface in Bereiche unterteilt (z.B. Header, Footer, Navigation, Inhaltsbereich), die jeweils separat identifiziert und verglichen werden, um dynamische Aspekte des Layouts berücksichtigen zu können.

Dies ist ein Ansatz, der im Zuge von Testdurchführungen A2A.TAF ergänzend umgesetzt werden kann, und den funktionalen Testlauf um Layout-Validierungen ergänzen kann. Vielversprechend ist auch, dass diese Checks nicht synchron und für jeden Testfall (und damit eventuell redundant) durchgeführt werden muss, sondern gewisse Schlüsselpunkte des Testlaufs (z.B. „Bestellbestätigung“) markiert werden können, und dementsprechend Screenshots hinterlegt werden, die zu einem späteren Zeitpunkt mit dem Referenzmaterial verglichen und ausgewertet werden.

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.

Machine Learning

Machine Learning ist in aller Munde. Ob selbstfahrende Autos, medizinische Diagnosen, Spracherkennung, oder auch Börsenkurse: Machine Learning ist mittendrin.
Das Grundprinzip ist simpel: Anstatt komplexe Programme zu schreiben, soll Software selbstständig anhand von Inputs und Outputs ihr Soll-Verhalten erlernen.
Doch was bedeutet es für Softwarequalität, wenn Software ihr Verhalten selbst erlernt? Wie kann eine Grundqualität sichergestellt werden? Und: Wie können wir Machine Learning vielleicht sogar für die Sicherung von Softwarequalität nutzen?
Traditionelle Ansätze wie spezifikationsbasiertes Testen haben damit so ihre Probleme – sie basieren darauf, dass das Soll-Verhalten klar konkret formulierten Anforderungen genügt, und die erwarteten Ergebnisse eindeutig aus diesen Anforderungen ableitbar sind. All das ist bei erlernten Verhaltensmustern per Definition nicht der Fall.

Wie meine Kollegin Andrea Kling in ihrem Blog Artikel über Künstliche Intelligenz und Qualität schreibt, ist bei Supervised Learning ein Qualitätssicherungsschritt im grundlegenden Vorgehen enthalten, um Under- und Overfitting vorzubeugen. Aber was ist mit der Gesamtqualität eines Systems, das KI als eine Teilkomponente einsetzt? Oder mit Systemen, die Unsupervised Learning verwenden? Hier ist eine Gesamtaussage über die Qualität des Verhalten deutlich komplexer. Um dem entgegenzuwirken gibt es einige Konzepte:

  • Die Entwicklung von „Gold Standard“ Verhaltensweisen, die gewisse, eindeutig korrekte Verhaltensweisen als Rahmenbedingung setzen
  • Verwendung von User-Feedback oder Expertenwissen, um korrekte Verhaltensmuster vorzugeben
  • Fuzzing von Tests und Soll-Ergebnissen (siehe auch entsprechender Abschnitt in diesem Artikel)

Doch das ist nicht der einzige Aspekt, der uns bei Machine Learning interessiert: Wir sehen darin nicht nur die Herausforderung der Qualitätssicherung, sondern auch große Chancen, Machine Learning als Werkzeug für Testautomatisierung einzusetzen. Das kann viele der klassischen Testaktivitäten vereinfachen:

  • Testdesign anhand von Anforderungen
  • Automatisierte Testdurchführung inkl. intelligentem Umgang mit für das Testziel „irrelevanten“ Änderungen
  • Ableitung von erwarteten Ergebnissen, als alternatives Testorakel

Ein konkretes Beispiel aus der Welt des UI-Tests, welches wir betrachten wollen: Wir trainieren anhand unserer manuellen oder automatisierten Tests in vielen Projekten eine AI darauf, User Interfaces zu analysieren und abzutesten. Also z.B. zu überprüfen, ob Textfelder anhand ihrer Beschriftung plausible Validierungen vornehmen oder ob Listboxen erwartete Eingaben zulassen. Doch man kann damit noch weitergehen, und „softere“ Aspekte, wie z.B. Usability oder Accessibility betrachten (siehe auch entsprechender Abschnitt in diesem Artikel).

Conclusio

Wir sind in den letzten 15 Jahren weit gekommen. Ob UI-Automatisierung, Schnittstellenautomatisierung, nachhaltiger Aufbau von Testfallportfolios, Integration mit Prozessen und Tools, DevOps oder Last- und Performance-Tests. Es hat sich viel getan. Die Disziplin der Testautomatisierung ist von einem Nebenprodukt zu einem wesentlichen Bestandteil von moderner Software-Entwicklung geworden. Darauf kann man gerne (auch ein bisschen stolz) zurückblicken.

Unter „Digitalisierung“ verstehen vermutlich keine zwei Personen exakt das Gleiche – und dennoch sind sich alle einig, dass die derzeitigen technologischen Veränderungen Parallelen zu den letzten Revolutionen (Stichwort: Internet) aufweisen, und größere Veränderungen auslösen werden.

Jetzt gilt es, das Erarbeitete kritisch zu hinterfragen, und es durch neue Konzepte und Lösungen zu stärken. Nicht alle der in diesem Artikel beschriebenen Dinge wird „The Next Big Thing“ in der Testautomatisierung. Viele Techniken in diesem Artikel sind auch nicht brandneu; aber es geht uns nicht darum, zwanghaft Trends zu folgen, sondern darum, unter A2A.TAF ohne Berührungsängste bewährte und vielversprechende Methoden in einem flexiblen, robusten und nachhaltigen Framework zu vereinen.

Und es werden noch viele andere Dinge hinzukommen. Aber wir meinen, erprobte Konzepte und zukunftsweisende Stoßrichtungen identifiziert zu haben, und werden diese aus der Perspektive der Testautomatisierung untersuchen, umsetzen und mitgestalten.

Thomas SteirerThomas Steirer, Anecon Software Design und Beratung GmbH

Nach Abschluss seines Studiums Informatik/Computational Intelligence an der TU Wien legte Thomas Steirer seine Schwerpunkte vor allem auf Testautomatisierung, Test-Tool-Evaluierung, Testframework-Entwicklung und Testmanagement. Der Test-Experte arbeitet in Wien bei Anecon, die Teil der Nagarro Group ist.
 

Anzeige

Artikel zu diesem Thema

Weitere Artikel

Newsletter
Newsletter Box

Mit Klick auf den Button "Jetzt Anmelden" stimme ich der Datenschutzerklärung zu.