Im Code liegt Wahrheit: Software(test)-Anforderungen & Testmöglichkeiten

Was ist ein Software-Test?
Es gibt verschiedene Definitionen davon, was ein Softwaretest ist. Ich persönlich finde jene von Denert gut, bei der ein Test der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen ist. Insbesondere der letzte Teil „[...] zu vorher festgelegten Anforderungen“ ist aus meiner Sicht existenziell wichtig und entscheidend. Ein Softwaretest ohne genaue Softwarespezifikation ist demnach nicht möglich.

Anforderungen von verschiedenen Anforderungsgruppen

Es gibt ganz verschiedene Anforderungen von unterschiedlichen Anforderungsgruppen. Ich unterteile die Anforderungsgruppen in vier Hauptgruppen: Business, Technik, IT-Compliance und Fach-Compliance. Klar, jemand der nicht in Compliance-Abteilungen arbeitet oder gearbeitet hat, würde wahrscheinlich IT-Compliance und Fach-Compliance einfach unter dem Begriff „Compliance“ führen. Ich erlaube mir aber, diese zu trennen.

Business
Hier geht es um die spezifischen Anforderungen des Fachbereichs. Die meisten können mit der Frage, welche Funktionen eine Software haben muss, gruppiert werden.

Technik
Wie der Begriff sagt, geht es hier um technische Anforderungen. Beispiele sind: Plattformen, Protokolle, technische Standards, Deployment, Wartbarkeit etc.

IT-Compliance
Hier stehen häufig die gleichen Standardanforderungen im Raum: Sicherstellung von Vertraulichkeit, Verfügbarkeit, Integrität, Datenaufbewahrung und Datenschutz.

Fach-Compliance
Hier geht es um Compliance-Anforderungen, welche das spezifische Business betreffen. Wird beispielsweise eine Software für den Börsenhandel entwickelt, sind es spezifische regulatorische Anforderungen aus dem Börsenrecht (u.a.).

Testarten und -möglichkeiten

Für möglichst alle Anforderungen sollten spezielle Tests durchgeführt werden. Dazu gibt es unterschiedliche Ansätze und Methoden. Diese kann man je nach Gesichtspunkt in verschiedene Gruppen einteilen:

Nach Testkriterium: Funktionale Tests, Stresstests, Lasttest, Schnittstellentests, Sicherheitstests, GUI-Tests etc.

Nach Informationsstand: Blackbox-Tests, White-Box-Tests (auch Code-Reviews genannt)

Nach Test-Technik: Statische und dynamische Tests.

Sobald eine Software durch einen Kunden oder gar Dritten getestet und abgenommen wird, werden in der Regel Blackbox-Tests gemacht. Das heisst, dass die Tests damit gemacht werden, dass die Software gebraucht wird. Entweder fährt das Auto, oder es fährt nicht. Weshalb es genau fährt, bleibt dem Tester vorenthalten.

Wer muss Software testen? Welche Software muss man testen?
Diese Frage ist so allgemein nicht zu beantworten. Sicher gilt für Finanzintermediäre, dass sie jene Software testen müssen, welche sie für das Kerngeschäft einsetzen. Irgend eine Software für Marketingkampagnen muss nicht, oder nicht im gleichen Umfang wie beispielsweise eine E-Banking-Software, getestet werden. Eine Firma muss im IT-Reglement oder der IT-Weisung definieren, welche Software getestet werden muss und wie. Wer in einer Firma Softwaretests definiert und durchführt, hängt von der Software und den durchzuführenden Tests ab. Meist braucht es dazu Mitarbeiter aus mehreren Abteilungen (Fachbereich, Compliance und IT).

Erfahrungen und Konklusion
Nach meinen Erfahrungen ist es sehr schwierig, gute Softwaretests zu beschreiben, welche tatsächlich dafür nützlich sind, die Umsetzung der gemachten oder geforderten Anforderungen zu prüfen. Meist werden zudem nur Anforderungen aus dem Bereich Business geprüft. Es liegt aber nicht nur an den Test-Verantwortlichen, dass Software häufig nicht ausreichend und nicht effizient geprüft wird. Es liegt auch daran, dass mit Blackbox-Tests allein einfach zu wenig gut geprüft werden kann: Im Code liegt Wahrheit. Hat eine Software beispielsweise interne Limiten (die von verwendeten Datenstrukturen herrühren) ab einem bestimmten Datenvolumen, so bräuchte es schon ein Lasttest, um dies zu merken. Oder ein bestimmter Datenwert führt zu einem Fehler. Ist es da nicht Zufall, wenn Sie Tests haben, welche diese Datenwerte brauchen? Oder die Software macht Fehler, wenn parallel mehrere Benutzer gleichzeitig auf ein Objekt zugreifen wollen? Führen Sie die Tests wirklich so durch, dass Sie dies merken würden? Oder die Software führt gewisse Log-Aufträge nicht aus, wenn man sich mit einem bestimmten Benutzer anmeldet? Prüfen Sie wirklich mit allen möglichen  Benutzern alle Testfälle? Die Liste könnte beliebig erweitert werden. Es gibt so viele mögliche Fehler, die mit Blackbox-Tests in der Praxis fast nicht zu erkennen sind und schon gar nicht mit wirtschaftlich vernünftigem Aufwand. Meine Meinung ist deshalb klar: Bei Geschäftskritischer Software braucht es vermehrt Code-Reviews. Der Source-Code wird angeschaut und geprüft. Diese Code-Reviews ersetzen dabei auf keinen Fall die üblichen Anwendungstests, welche in Form von Blackbox-Tests durchgeführt werden, sondern ergänzen diese. Denn auch der Aufwand von Code-Reviews darf nicht unterschätzt werden – solche Reviews müssen von Personen mit entsprechenden Know-how gemacht werden, was mit entsprechenden Kosten verbunden ist.

Sicherlich ist diese Forderung für die meisten Softwarefirmen nicht opportun. Denn niemand, der Software unter einer proprietären Lizenz verkauft, will seinen Software-Code, oder Teile davon, zwecks Review einem Kunden offen legen. Aber genau das wäre aus meiner Sicht ein wirkungsvolles Mittel, um die Softwarequalität zu erhöhen. Dabei soll Softwarequalität an dieser Stelle vor allem als konnotierter Begriff im Anforderungskontext verstanden werden.

Aber nicht nur die Softwarehersteller sind gefordert. Auch die Kunden und insbesondere die Compliance Officer sind hier gefordert. Und zwar gleich doppelt:

1. Müssen sie sich aktiv in den Prozess der Softwarespezifikation einbringen. Denn wie Eingangs geschrieben, braucht es für einen Softwaretest eine Anforderung und diese muss gestellt werden.
2. Die Compliance Officer müssen aktiv dafür sorgen, dass ihre gestellten Anforderungen mit einem geeigneten Testverfahren auch geprüft werden.

Für einige Leser mag mein Wunsch zum Schluss vielleicht schon fast wie ein Mantra klingen. Aber Mantras haben bekanntlich eine positive Wirkung auf den Geist. Hier ist er: Es wäre wünschenswert, wenn Compliance vermehrt am gesamten Entwicklungsprozess von Software beteiligt wäre – denn nur so kann sichergestellt werden, dass neue Software Compliance konform umgesetzt wird.