Nichtfunktionale Tests: Was definiert, ob das System nicht nur funktioniert, sondern auch gut ist

Ein System kann alle Funktionstests bestehen und dennoch ein Fehler sein.

Es erfüllt genau das, was in der Spezifikation gefordert wurde. Jeder Knopf funktioniert, jede Berechnung ist korrekt, jeder Ablauf vervollständigt sich. Und trotzdem ist es so langsam, dass es irritiert, es stürzt ab, wenn viele Leute es benutzen, es verliert Daten beim ersten Angriffsversuch und es ist so verworren, dass niemand es ändern kann, ohne drei andere Dinge kaputt zu machen. Es funktioniert, und es ist schlecht.

Dieser Unterschied zwischen „macht, was es soll“ und „macht es gut genug, um tatsächlich verwendet zu werden“ ist genau das Gebiet nichtfunktionaler Tests. Sie sind meiner Meinung nach der Teil der Qualität, der professionelle Produkte am meisten von getarnten Prototypen unterscheidet.

Funktional versus nicht funktionsfähig

Die Unterscheidung ist einfach zu formulieren und hat tiefgreifende Konsequenzen.

Funktionstests prüfen, was das System tut: Erzeugt es bei gegebener Eingabe die korrekte Ausgabe? Speichert die Registrierung? Wird die Zahlung bearbeitet? Enthält der Bericht die richtigen Zahlen? Dabei handelt es sich um Verhaltens- und Korrekturfragen.

Nichtfunktionale Tests prüfen, wie das System funktioniert: wie schnell, wie sicher, wie zuverlässig, wie skalierbar, wie einfach zu bedienen und zu warten. Sie fragen nicht „Funktioniert es?“, sondern „Funktioniert es gut?“. Geschwindigkeit, Sicherheit, Stabilität unter Last, Zugänglichkeit, das alles ist nicht funktionsfähig.

Die Falle besteht darin, dass Funktionalität einfach zu spezifizieren und zu berechnen ist und daher fast die gesamte Aufmerksamkeit auf sich zieht. Das Nicht-Funktionale ist diffus, lässt sich leicht aufschieben und wird daher meist vernachlässigt, bis es zum Grund für den Ausfall des Systems in der Produktion wird.

Die Dimensionen, auf die es ankommt

„Nicht funktionsfähig“ ist ein großer Regenschirm. Es lohnt sich, die Hauptdimensionen zu kennen, denn jede davon ist eine andere Möglichkeit, das System zu enttäuschen, selbst wenn es funktioniert.

Die Leistung ist am sichtbarsten: Reaktionszeiten, Geschwindigkeit bei der Nutzung. Ein korrektes, aber langsames System verliert stillschweigend Benutzer. Skalierbarkeit und Kapazität hängen davon ab, ob es Wachstum und Nachfragespitzen bewältigen kann, und funktionieren nicht nur, wenn nur wenige Leute es nutzen.

Bei Zuverlässigkeit und Verfügbarkeit geht es um Kontinuität: Hält das System im Laufe der Zeit stand, erholt es sich nach Ausfällen und beschädigt es nicht die Daten? Die Sicherheit prüft, ob sie einer böswilligen Nutzung standhält, und hier liegt die teuerste Fehlerkategorie, denn eine Sicherheitslücke frustriert den Benutzer nicht, sondern bloßstellt ihn.

Usability und Accessibility fragen, ob echte Menschen mit unterschiedlichen Fähigkeiten und Kontexten es tatsächlich nutzen können. Und die Wartbarkeit, die unsichtbarste von allen, stellt die Frage, ob das Team das System weiterentwickeln kann, ohne dass jede Änderung zu einem Minenfeld wird.

Warum nicht funktionsfähig zurückgestellt wird (und warum es ein Fehler ist)

Dass das Nicht-Funktionale vernachlässigt wird, hat einen strukturellen Grund: Es kommt in der Demonstration nicht vor.

Wenn Sie einem Kunden oder Manager das System zeigen, zeigen Sie die Funktionalität. „Schau, tu dies, tu das.“ Niemand demonstriert, „schaut, wie es zehntausend Benutzern standhält“ oder „schaut, wie es einem Angriff standhält“. Diese Eigenschaften sind bis zu dem Tag, an dem sie fehlen, unsichtbar und treten dann als Krise in Erscheinung.

Das Ergebnis ist eine falsche Ökonomie. Der Last-, Sicherheits- und Barrierefreiheitstest wird verschoben, denn „erst muss es funktionieren“. Dann geht das System in die Produktion, stürzt beim ersten Spitzenwert ab, verliert Daten oder schließt einen Teil der Benutzer aus, und die Kosten für eine verspätete Korrektur sind um ein Vielfaches höher als für einen rechtzeitigen Test.

Im öffentlichen Sektor ist dies besonders gravierend. Ein funktionierendes, aber langsames, unsicheres oder unzugängliches Bürgerservicesystem dient nicht denjenigen, die es am meisten benötigen. Und beim Umgang mit personenbezogenen Daten stößt die nichtfunktionale Sicherheitslücke direkt auf LGPD, es ist kein technisches Problem mehr, sondern ein rechtliches Problem.

Das Testen des Nicht-Funktionalen erfordert eine andere Denkweise

Die Testfunktionalität ist relativ einfach: Eingaben definieren, Ausgaben prüfen. Das Testen des Nicht-Funktionalen ist schwieriger, da dafür definiert werden muss, was „gut genug“ ist, und das ist eine Entscheidung, keine Tatsache.

Wie schnell ist schnell genug? Wie viele gleichzeitige Benutzer kann es „verarbeiten“? Welcher Verfügbarkeitsgrad ist akzeptabel? Auf diese Fragen gibt es keine allgemeingültige Antwort; hängen vom Kontext des Unternehmens und der Benutzer ab. Die erste Aufgabe nichtfunktionaler Tests besteht daher darin, vage Eigenschaften in messbare Ziele umzuwandeln. „Schnell“ wird nicht getestet; „In 95 % der Fälle innerhalb dieser Zeitspanne reagieren“ wird getestet.

Die praktische Konsequenz besteht darin, dass neben den funktionalen auch nicht-funktionale Anforderungen frühzeitig definiert werden müssen. Sie als nachträglichen Einfall zu behandeln bedeutet, dass sie zu spät oder nie getestet werden.

Die Fehler, die den Aufwand nutzlos machen

Der erste Fehler besteht darin, sich keine Ziele zu setzen. Ohne ein Ziel wird „Leistung testen“ zum Sammeln von Zahlen, ohne zu wissen, ob sie gut oder schlecht sind. Das Ziel muss vor der Prüfung kommen.

Die zweite besteht darin, in einer unrealistischen Umgebung zu testen. Die Messung der Leistung auf einer anderen Maschine als der Produktion oder der Sicherheit ohne realistische Angriffsszenarien führt zu irreführenden Ergebnissen. Das Nicht-Funktionale reagiert besonders sensibel auf die Umwelt, die Zahlen sind nur gültig, wenn die Bedingungen der Realität entsprechen.

Die dritte besteht darin, es als ein einzelnes Ereignis zu behandeln. Leistung, Sicherheit und Zuverlässigkeit nehmen mit der Zeit und jeder Änderung am System ab. Ein einmal beim Start durchgeführter Sicherheitstest sagt wenig über die Sicherheit sechs Monate und fünfzig Veröffentlichungen später aus. Das Nicht-Funktionale braucht Wiederholung.

Qualität ist das, was bleibt, wenn Funktionalität als selbstverständlich angesehen wird

Es gibt einen Moment in der Reife eines Produkts und einer Organisation, in dem „es funktioniert“ keine Errungenschaft mehr ist, sondern ein Ausgangspunkt. Von da an wird echte Qualität durch Nicht-Funktionalität definiert: Es ist schnell, es ist sicher, es hält stand, es ist zugänglich, es ist möglich, sich weiterzuentwickeln.

Startup-Teams feiern „es funktioniert“. Reife Teams wissen, dass dies nur der Boden ist. Was ein professionelles System von einem Amateursystem unterscheidet, ist selten, was es leistet, sondern wie gut es es unter Druck, im Laufe der Zeit und für alle leistet. Genau dieses „Wie gut“ schützen nichtfunktionale Tests.

Sie zu ignorieren spart keine Mühe. Dadurch werden die Kosten lediglich auf den ungünstigsten Zeitpunkt verlagert: die Produktion, bei der der Benutzer anwesend ist.

Wenn Ihr Produkt „funktioniert“, Sie aber noch nie gemessen haben, wie schnell, sicher oder belastbar es ist, besteht wahrscheinlich ein nicht funktionsfähiges Risiko. Ich habe weitere Artikel auf dem Blog über Leistung, Sicherheit, Zuverlässigkeit und Softwarequalität, die sich mit jeder dieser Dimensionen befassen.