Software ist ein Text und keine Maschine. Daher können nur vorhandene Fehler und „Lücken“ aufgezeigt werden, jedoch nicht die Richtigkeit nachgewiesen werden.
Analog zu anderen Texten, die eine Funktion erfüllen sollen (z.B.: Gesetze, Verträge, Bedienungsanleitungen, wissenschaftliche Arbeiten, …), können bei der Erstellung verschiedene Arten von Fehlern gemacht werden. Einige dieser Fehler sind leicht zu finden (z.B.: Rechtschreibfehler, Syntaxfehler, …). Andere Fehler können durch Personen mit entsprechendem Fachwissen erkannt werden (z.B. durch Reviews von Juristen, Wissenschaftler, Softwareentwickler, …). Die höchste Stufe der Qualitätssicherung ist es jedoch den Text „anzuwenden“ und dessen Tauglichkeit zu prüfen. Im Falle von Gesetzen und Verträgen finden die meisten Texte erst vor einem Richter Anwendung. Bei Software kann die Funktionalität allerdings schon früher getestet werden.
Die Praxis (Anwendungsbeispiel)
Vergleichen wir an dieser Stelle die Qualitätssicherung von Software mit der Erstellung eines Vertrages zwischen zwei Unternehmen. Beides
- sind von Menschen erstellte Schriftstücke, (weshalb auch für Software das Urheberrecht anzuwenden ist)
- werden formal über Sprache formuliert, (Software über Programmiersprache; Verträge über „Juristen-Deutsch“)
- besitzen eine Struktur (Architektur), (Software durch Klassen und Module; Verträgen durch Paragraphen und Absätze)
- unterliegen Rahmenbedingungen, (Software u.a. technischen Gegebenheiten; Verträge u.a. rechtlichen Gegebenheiten)
- haben eine Funktion (sollen Dinge regeln) und (Software z.B. einen Informationsfluss; Verträge z.B. Rechte und Pflichten)
- werden interpretiert. (Software vom Prozessor; Verträge ggf. von Juristen)
Die beiden Dinge haben somit mehr Ähnlichkeiten, als zuerst zu vermuten wäre – auch in der Qualitätssicherung.
Die grundlegenden Dinge eines Vertrages wie Rechtschreibung und Grammatik (Syntax) können einfach und teilweise automatisiert geprüft werden. Der inhaltliche Zusammenhang (Semantik) bedarf allerdings bereits eines „Prüfers“. Denn die Frage, ob aneinandergereihte (gültige) Sätze schlüssige und verständliche Aussagen ergeben, lässt sich bereits nicht mehr automatisiert beantworten. Spätestens wenn noch die Rechtskonformität sicherzustellen ist, wird die Expertise eines Juristen benötigt.
Richtig knifflig ist es herauszufinden, ob ein Vertrag seine „Funktion“ erfüllt. Ob also inhaltlich alle gewünschten und nötigen Vereinbarungen vollständig und widerspruchsfrei formuliert wurden. Dies kann nun durch einen Juristen alleine nicht mehr beantwortet werden. Es bedarf hierfür zumindest jeweils eines Vertreters der Auftraggeber- und der Auftragnehmerseite. Nur diese sind in der Lage den Vertrag inhaltlich auf Schlüssigkeit zu prüfen (z.B. „Entspricht der Leistungsumfang dem benötigten und lieferbaren?“, „Können die formulierten Termine eingehalten werden?“, „Ist die Vergütung angemessen?“, „Gibt es Spielräume bei Leistungsumfang und Vergütung?“ u.v.m.).
Um den Vertrag abschließend zu „testen“, müssten verschiedene Szenarien entworfen werden, welche anschließend mit Hilfe des Vertrags gelöst werden müssten. Im Idealfall sind dies Szenarien, welche im Vertrag nicht und unzureichend behandelt wurden, und in Folge einen Rechtsstreit verurschen könnten. Ein Unterfangen, dass aufgrund des Aufwands bei Verträgen keine wirkliche Anwendung findet. Bei Software jedoch, die „Funktionalität“ sicherstellen soll.
Auf Software übertragen entspricht
- die Rechtschreib- und Grammatikprüfung der Syntax- und beschränkten Semantikprüfung durch Programme wie IDEs (engl. „Integrated Development Environment“; dt. „integrierte Entwicklungsumgebung“) oder Compiler,
- die Prüfung durch Juristen einem Code-Review durch Softwareentwickler
- die inhaltliche Prüfung auf Vollständigkeit einer Systemabnahme durch den Kunden und
- das Ausarbeiten und Anwenden von Szenarien dem Testen.
Zusammengefasst: Ähnlich wie bei einem Vertrag kann die Richtigkeit von Software nie vollständig nachgewiesen werden.