“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.
Häufig gestellte Fragen
Ist Low-Code eine grundlegend neue Idee oder alter Wein in neuen Schläuchen?
Die Meinungen dazu gehen weit auseinander, von “alter Wein in neuen Schläuchen” bis “die Software-Revolution”. Auffällig ist, dass die Versprechen dieselben sind wie bei früheren Software-Revolutionen: Kosteneffizienz, schnelle Markteinführung, Flexibilität und einfache Umsetzung. Neu ist vor allem die Abstraktionsebene, auf der gearbeitet wird, nicht das Grundmuster des Versprechens.
Lohnt sich der Einsatz von Low- oder No-Code-Plattformen pauschal?
Nein. Die Sinnhaftigkeit hängt von vielen Faktoren ab und muss im Einzelfall genau geprüft werden. Der Wunsch nach einfachen Lösungen und Abstraktionen ist in einer fachlich und technisch hochkomplexen Software-Welt verständlich. Er ersetzt aber keine Prüfung, wo die Plattform trägt und wo ihre Schattenseiten liegen.
Welche Teststufen bleiben relevant, wenn eine Anwendung ohne eigenen Code entsteht?
Die höheren Teststufen bleiben vollständig bestehen. Bei den unteren Stufen kann man sich in Teilen auf die Hersteller der Plattform verlassen, allerdings mit einer gesunden Portion Skepsis. Alles, was aus der Zusammenstellung von Modulen, Oberflächen und Prozessen entsteht, ist neue Software und braucht Test und fachliche Abnahme.
Was prüft man bei einer mit No-Code gebauten Anwendung inhaltlich?
Drei Fragen stehen im Vordergrund: Ist eine passende Architektur für Prozesse und Oberflächen gewählt? Erfüllen die Abläufe die fachlichen Anforderungen? Sind die Module sinnvoll genutzt? Das sind dieselben Fragen wie bei klassischer Entwicklung, nur auf einer höheren Abstraktionsebene gestellt.
Was ändert sich an den Rollen, wenn Fachleute ihre Anwendungen selbst zusammenbauen?
Die Rollen verschieben sich. Ein Business Analyst, der bisher die Eigenentwicklung getestet und abgenommen hat, baut die Applikation nun selbst. Damit verschwindet eine Kontrollinstanz aus dem Ablauf. Test und fachliche Abnahme müssen dann bewusst an anderer Stelle organisiert werden, sonst fällt beides schlicht weg.
Kann ein Citizen Developer seine eigene Anwendung selbst abnehmen?
Nein. Wer die Umsetzung selbst gebaut hat, fällt als Tester für diese Umsetzung aus. Tests und fachliche Abnahmen müssen anderswo stattfinden. Das gilt unabhängig davon, wie gut das fachliche Know-how der Person ist, denn die Prüfung der eigenen Arbeit bleibt blind für die eigenen Denkfehler.
Warum ersetzt fachliches Know-how kein Architektur- und Entwicklungswissen?
Ein Business Analyst ist kein Software-Architekt und kein Entwickler. Ihm fehlt in der Regel das Denken in Software-Design, Entitäten, Datenflüssen und Wiederverwendbarkeit, ebenso die Paradigmen, Patterns und Best Practices für einen tragfähigen Software-Fluss. Ohne dieses Wissen entstehen Module und Oberflächen eher nach Gutdünken zusammengestellt als nach einer durchdachten Struktur.
