Interview mit Wolfgang Platz 

Welche Herausforderungen werden sich aus deiner Sicht zukünftig dem Software-Test stellen?

Der Hunger nach Software

Aus meiner Sicht ist es wie folgt. Dominant ist der Hunger für Software und der ist massiv. Es gibt Prognosen von IDC, die besagen, dass allein im nächsten Jahr 40 Prozent des gesamten Codes geschrieben wird. Daran sieht man, wie extrem dieser Hunger für Software ist. Im Vergleich dazu liegt der Increase an zusätzlichen Ressourcen im Bereich Software Development von den weltweiten Universitäten bei rund 20 Prozent. Per Ano sind wir bei 35 oder 40 Prozent mehr Software, die wir haben wollen, es gibt jedoch nur 25 Prozent mehr an Developern. Da stellt sich die Frage, wie das funktionieren wird. Von Microsoft gibt es die Prognose, dass die Zukunft des Software Development weniger ein echtes Development sein wird, sondern immer mehr zu einer Parametrisation und Configuration auf einer abstrakten Ebene werden und das Phänomen des Citizen-Developers auftreten wird. Wenn man sich heute Google anschaut, sieht man auch No-Code- und Low-Code-Development und massiven Growth, was zu immensem zusätzlichem Momentum führt. Interessant ist, was in diesem Low-No-Code gemacht wird. Heute sind die dort entwickelten Applikationen sehr simpel. In dem Moment, wo man ein richtiges System haben will, kommt man um Entwicklung nicht drumherum. Bei den richtigen Systemen sehen wir, dass die Enterprise Applications alle versuchen, diesem enormen Bedarf an Individualisierung Rechnung zu tragen, indem sie massive Konfigurationslayers bauen, die erlauben, ein No- und Low-Code-Development auf ihren Kernel draufzusetzen. Da sind viele Unternehmen ganz stark unterwegs und versuchen ganz massiv zu vereinfachen. Sie haben dafür ein eigenes Programm, das das Low-No-Code-Development auf ihrer Basisplattform unterstützen soll. Nicht zuletzt, weil das der Schlüssel ist, SaaS anzubieten, was bei dem starken Individuellen Development ein Muss ist. Wir haben auf der einen Seite die Enterprise-Systeme, die immer stärker versuchen, die Coding-Threshold nach oben zu schieben. So kann man immer mehr mit No- und Low-Code machen. Darüber hinaus haben wir die jetzt existenten Low-No-Code-Plattformen, die sich in den Capabilities dazu eignen, einfache Dinge auch ohne Codierung zu lösen.

Low- und No-Code

Aus meiner Sicht werden zwei Dinge passieren, die sich hauptsächlich auf das Back-Office-Geschehen beziehen. Früher wurde dies mit Excel gemacht, jetzt wird das mit Low- und No-Code zusammengesetzt und all das sind sehr simple Prozesse. Heute liegt die Komplexitätsbarriere dieser Eigenentwicklungen unterhalb des Test-Needs. Ein Tester sagt natürlich, dass alles getestet werden muss. Wir wissen aber, dass simple Dinge nicht getestet werden. Wir werden aber zwei Dinge sehen. Einerseits wird die Komplexität ansteigen und andererseits werden sich die individuellen Lösungsfortsätze verbinden. Plötzlich ist eine Komplexität vorhanden, die eines Tests bedarf. In diesem Augenblick gibt es die Citizen-Developers und die Citizen-Testers. In diesem Augenblick haben wir es mit einem großen Need an No-Code-Ornamation zu tun, der dem No-Code-Development folgen wird. Ein No-Code-Developer wird nicht einfach eine Kodierung für sein Auto Mission machen. Mit einer bestimmten Zeitverzögerung wird somit dieses große Momentum an Citizen-Development, das wir in den nächsten Jahren sehen werden, auf die Testdisziplin überschwappen. Daher wird es aus Tooling-Perspektive zwei Welten geben. Es wird nach wie vor die heute existente Codierungswelt mit den verschiedenen Frameworks geben und die Leute versuchen sich beispielsweise im Selenium und Appium. Darüber hinaus wird es eine größer werdende stärker abstrahierte Business-Definition-Welt geben, in der die Leute das Software-Testing vollführen werden, ohne dass sie den Code hineingehen müssen. Das ist meine Sicht bezüglich der Entwicklung der Skills.

Pendelbewegungen im Software-Testing

Bezüglich der Organisation werden wir eine Pendelbewegung sehen. In unserem Customer Base sehen wir eine Pendelbewegung. Vor zehn Jahren wollte jeder ein TCoE (Test Center of Excellence) haben. Seit spätestens fünf Jahren ist das vorbei. Mit Zeitverzögerung haben die Leute festgestellt, dass TCoE nichts wird und dieser große Pool an manuellen Testern, der auftragsbezogen agiert, irrelevant ist. Es gab vielerlei Probleme und die Antwort vieler Kunden war, man müsse die TCoE auflösen. Dann gab es die Idee, alles in das Development reinzunehmen und ein dezidierter Software-Test wäre unnötig. Dann stellte sich allerdings die Frage, was hier das eigentliche Prinzip sei. In einer großen Organisation funktioniert das nur für die ersten drei oder fünf Teams. Übernommen wurde es dann vom Agile Development, die großartige Ergebnisse erzielten. Es wurde skaliert und plötzlich kam das böse Erwachen, da die Produktivitätserwartungen bei weitem nicht mit den Produktivitätssteigerungen einhergingen. Wie war das möglich? Wenn man skaliert, passieren zwei Dinge. Man findet heraus, dass es doch höherliegende Teststufen braucht. Das ist wie Integration, Systemintegration und vielleicht sogar User-Acceptance, was schließlich doch benötigt wird. Es geht nicht nur über eine isolierte Applikation, sondern über einen gesamten Systemverbund. Die Frage ist, wer das macht. Die agilen Teams denken alle nur bis an die Grenze ihres agilen Spektrums und das ist jetzt in keinster Weise ein Vorwurf, da sie so aufgesetzt sind. So kommen wir zur hegelschen These-Antithese-Synthese-Bewegung, die in der Mitte sieht, dass es etwas gibt, das wir als Digital- oder Linked-TCoE kennen. Man setzt immer noch einen sehr schlanken Body auf, welcher Standards im Testansatz, der Testmethodik sowie der Automation teilweise vorgibt oder empfiehlt. Bei der Ergebnisdarstellung hat es aber eine echte Governance. Es ist aber immer noch ein zentraler Body, der hier ganz eng mit den Teams zusammenarbeitet. Das ist eine von uns ausgesprochene Empfehlung, die bei den Kunden gut funktioniert. Sogar für die Higher Levels of Tests in eigenen agil geführten Test-Teams führt er die Artefakte der niedrigeren Ebenen zusammen und aggregiert sie, sodass wir einen höherliegenden Test haben. Das wäre die organisatorische Form, die ich sehe. Falsch wäre der Ansatz, alles in die Agile-Teams zu geben, in der Hoffnung es wird dort gelöst. Fakt ist, dass das nicht funktioniert. Developer sind Progressive Animals und keine Regressiven Animals, weshalb sie ungern Unit-Tests machen. Push forward. Make things new. All das drückt sich interessant in Zahlen aus. Wir haben eine Survey bei den Schweizer Banken gemacht, bei der man sieht, dass sie bei der Release Eins, sprich bei neuen Tests, eine Code Coverage schaffen, die sukzessive abnimmt. Der Grund dafür ist, weil keiner die Maintenance macht. Die Coverage, die man über Unit Tests erhält, verpufft also über die Zeit. Das bedeutet, man muss de facto etwas tun, das ineffizient anmutet, da man die Tests auf einer höheren Integrationsebene abfängt. Man hat aber den riesen Vorteil, dass dies nicht mehr Developer machen müssen. Jetzt kann man Leute einbetten, die das Software-Testing als Aufgabe und nicht als Übel sehen. Die können diese Tests warten und aufrechterhalten. Die Microservice-Architecture hilft hier sehr viel, weil man hier immer ein API-Wrapping um den Service hat. Das erlaubt, auf einer API-Ebene einen Business-Logik-Test aufzusetzen, der in der Maintenance wesentlich besser funktioniert. Diese Contract-Tests machen die Leute unserer Erfahrung nach. Auf der Ebene sind sie bereit, das zu schreiben und zu pflegen.

One-Test-Definition

Ich habe noch ein drittes Thema, worüber ich mit dir sprechen wollte und das mich persönlich interessiert. Das Thema nennt sich One-Test-Definition. Was meine ich damit? Wir alle unterscheiden zwischen funktionalen und nonfunktionalen Tests. Bei den Nonfunktionalen möchte ich die zwei herausgreifen, die am meisten Effort über die Zeit mit sich bringen, nämlich Performance und Security. Es gibt folgende These. Eine Anwendung existiert oder hat das Recht auf Existenz, weil sie eine bestimmte Funktionalität bietet, die sonst keine Anwendung hat. Das ist so, weil sie irgendein Problem in einer Art löst, wie es keine andere Anwendung tut. Wozu brauche ich es überhaupt, wenn es eine andere gibt, die exakt das macht? Ich postuliere, dass jemand, der ein Business schreibt, keine redundante Funktionalität baut. Warum sollte man das tun? Wenn man es tut, dann nur da man nicht weiß, dass es das woanders schon gibt. Wenn ich allerdings eine neue Funktionalität baue, bedeutet das, dass ich immer wieder neue Testfälle bauen werde, die es so noch nicht gegeben hat, da die Funktionalität auch neu ist. Das bedeutet, dass das funktionale Testfall-Portfolio immer bis zu einem gewissen Grad individuell ist. Wenn du zwei vollkommen gleiche Testfall-Portfolios verwenden könntest, dann waren die Applikationen gleich. Wozu macht man das also? Finding Nummer eins ist, dass funktionale Test-Portfolios immer applikationsspezifisch sind. Ich reite so drauf rum, da nonfunktionale nicht unbedingt applikationsspezifisch sind. Wenn du dir heute Security-Tests ansiehst, dann willst du nicht, dass jemand Security Intrusions oder Angriffe machen kann. Diese Angriffe sind dabei alle hochgradig generisch und du möchtest sie bei keiner Applikation sehen. Es ist egal, ob es ein Web-Check-In oder eine Banking App ist. Du möchtest, dass diese Applikation sicher ist. Das Gro an Sicherheit kann generisch beschrieben werden. Ganz ähnlich verhält es sich mit Performance. Bei Performance wissen wir, dass 1,3 Sekunden die Länge ist. Länger wollen wir nicht auf eine Website warten. Wir wissen, es gibt jetzt eine applikationsspezifische Parametrierung, in welcher Concurrency die Use Cases durchlaufen werden müssen. 10.000 Leute sitzen gleichzeitig auf dem einen und 5.000 gleichzeitig auf dem anderen Use Case. Das ist aber nicht spezifisch für die Funktionalität der Anwendung. Das ist ein Parameter, das nur von der Environment festgesetzt wird, wenn ich 10.000 Mitarbeiter habe. Davon wird aber der Use Case nicht beeinflusst. Was bedeutet das? Wir stellen uns bei diesen Gedanken die Frage, warum wir die funktionale Navigation durch die Anwendung nicht als Basis nehmen können und mit diesen generischen Requirements anreichern können, um daraus einen Security- oder Performance-Test zu entwickeln. Die Schwierigkeit für einen Security-Test ist nicht die Definition der Requirements, sondern durch die Anwendung hindurch zu navigieren und in diesem Zusammenhang zu versuchen, die bösen Intrusions zu machen. Das ist eine Aufgabenstellung, die der funktionale Test schon gelöst hat. Bei der Performance ist die Anforderung auch nicht, den Use Case zu haben, wie ihn der User erlebt hat. Ich möchte nur sicherstellen, dass er 10.000-mal gleichzeitig funktioniert. Ich muss also andere Daten hineingeben und Environment-Daten entsprechend positionieren. Die funktionale Navigation durch die Anwendung ermöglicht aber, dass im Hintergrund die Last erzeugt wird, die wir schon gemacht haben. Warum kann ich also nicht eine funktionale Definition für den nonfunktionalen Bereich wiederverwenden und sie dort anreichern um den generisch Code? Und das nenne ich One-Test-Definition Wir haben das bei Tricentis jetzt verwendet und für den ersten Schritt Performance umgesetzt. Du nimmst das funktionale Test-Portfolio, im Hintergrund den Communication-Track dazu, dann reicherst du das mit verschiedensten Datenkonstellationen an, sodass du 10.000 User gleichzeitig drauf bringst. Der Flow ist aber der von der funktionalen Anwendung. Das Update und die Maintenance funktionieren von der funktionalen Anwendung per Knopfdruck. Initial musst du den funktionalen Fluss noch um die Spezifika dieser Testart, die generisch sind, anreichern. Wenn du das gemacht hast, kann das Update und die Maintenance immer auf Knopfdruck erfolgen. Damit bekommst du etwas Neues und in dem Augenblick, wo dein funktionaler Test auf grün geht, hast du zwei Dinge erreicht. Die Anwendung ist erstens halbwegs stabil, sonst würde sie den Smoke-Test nicht überleben. Zweitens ist das Funktionalitätsskript gewartet. Auf dieser gewarteten Situation kann ich jetzt aufsetzen und schieße das Update hinauf auf den Performance- und Security-Test. Das lasse ich sofort laufen und habe zumindest einen Smoke-Performance- und einen Smoke-Security-Test. Der kann jetzt auch von Leuten gemacht werden, die keine Experten sein brauchen, solange alles grün ist. Wenn es auf rot geht, brauchst du jemanden, der reinschaut. Das geht sowohl auf der Security-, wie auf der Performance-Ebene. Du kannst aber das Gro der Arbeit auf eine andere Ebene heben und eine Kontinuität in der Qualitätssicherung auch aus der nonfunktionalen Perspektive erreichen. Das ist die Idee von One-Test-Definition.

Was müssen deiner Meinung nach Tester und Testmanager im Jahr 2022 lernen und machen, um für kommende Veränderungen fit zu sein?

In der Zukunft muss man viel stärker als heute verstehen, wie DevOps funktioniert. Man muss auch als Testmanager unbedingt verstehen, wie Docker und Kubernetes grundsätzlich funktionieren. Wie werden diese grundsätzlich eingesetzt? Das war früher nicht notwendig. Da waren die Tests eher singuläre Ereignisse, was heute nicht mehr so ist.

Sonst sehe ich immer noch erschreckende Unkenntnisse bei allen Testmanagern, was Methodik betrifft. Immer noch werden die Fehler von vor 20 Jahren gemacht. Hauptsache, wir automatisieren komplett. Keiner fragt sich dabei, was an zusätzlicher Coverage durch so einen Test generiert wird. Immer noch ist den Leuten der Übergang eines intuitiven Testansatzes hin zu einem methodischen Testansatz in seiner Bedeutung nicht geläufig. Wichtig zu wissen ist, wann wir was machen. Wann müssen wir ein Testdatendesign, ein Testcasedesign machen? Diese grundlegende Testmethodik empfehle ich jedem.