Low/No-Code – Braucht noch wer ‘nen Tester?

“No-Code verlagert nur das Thema Testen. Qualitätssicherung bleibt notwendig!” - Richard Seidl

Low- und No-Code-Plattformen werden seit einigen Jahren immer populärer. Zumindest in den Medien. Die Meinungen darüber sind breit gefächert: Von “Alter Wein in neuen Schläuchen” bis “Die Software-Revolution” ist alles dabei. Die Lösungsversprechen sind irgendwie die gleichen wie auch schon bei allen anderen Software-Revolutionen: Kosteneffizienz, schnelle Markteinführung, Flexibilität und einfache Umsetzung.

Die Frage nach der Sinnhaftigkeit für den Einsatz von Low/No-Code lässt sich mit dem meist-verwendeten Berater-Zitat klären: “Kommt drauf an.” Es hängt von vielen Faktoren ab. Das müssen wir genau prüfen! Denn wo Licht ist, ist auch Schatten. Und natürlich wünschen wir uns für unsere mittlerweile fachlich und technisch hochkomplexe Software-Welt einfache Lösungen und Abstraktionen. Wir wollen Komplexität beherrschbar machen.

Wie siehts mit der Qualitätssicherung aus?

Aber wie sieht es denn mit Testing und Qualität aus? Ich hörte schon mal, dass man bei No-Code nicht testen muss. Nun, das sehe ich anders. Für die unteren Teststufen können wir uns ja auf die Hersteller der Plattform verlassen (räusper, hüstel). Aber die Qualitätssicherung auf den höheren Teststufen bleibt. Und hier vor allem Fragen wie:

• Ist eine passende Architektur für die Prozesse/Oberflächen gewählt?
• Erfüllen die Abläufe die fachlichen Anforderungen?
• Sind die Module sinnvoll genutzt?

Hä? Das sind doch die gleichen Fragen wie immer. Ja. Denn wir verlagern hier ja die “Entwicklung” nur auf eine höhere Abstraktion. Statt Code basteln wir Module, Oberflächen, Prozesse zusammen. Und auch hier gibt es eine Architektur, eine Entwicklung und einen Test. Meiner Meinung nach spricht sogar vieles hier für einen sehr ordentlichen Test. Denn der “Citizen developer” kann ja jeder sein. Und dadurch ändern sich oft auch die Rollen. Ein Beispiel: ein Business Analyst, der jetzt, statt die Eigenentwicklung zu testen und abzunehmen, selbst beginnt, seine Applikationen zusammen zu klicken. Ist ja praktisch, er hat ja das fachliche Know- How. Aber ich unterstelle hier mal einfach ein paar nicht so tief ausgeprägte Skills:

• Der BA ist kein Software-Architekt. Er wird nicht im Raum von Software-Design, Entitäten, Datenflüssen und Wiederverwendbarkeit denken, sondern eher nach Gutdünken, Module, Oberflächen und Sonstiges zusammenstellen.
• Er ist auch kein Softwareentwickler. Ihm fehlen wahrscheinlich die Paradigmen, Pattern und Best Practices wie ein Software-Fluss bestmöglich funktioniert.
• Außerdem fällt er als Tester für seine eigene Umsetzung raus. Sprich Tests und die fachlichen Abnahmen müssen anderswo stattfinden.

Software ist Software. Jede anders. Low-Code heißt nicht Low-Test und No-Code schon gar nicht No-Test. Aber halt anders.