Wo ist eigentlich die Qualität einer Software zu finden?

Ein Schwerpunkt meiner Arbeit besteht darin, Teststrategien zu entwickeln, um Software möglichst ressourcenschonend und gezielt testen zu können. Ich behaupte, dass die Qualität einer Software nur teilweise in der Software selbst zu finden ist und deshalb durch Testen nur begrenzt gesteigert werden kann. Wozu also das Ganze?

Als Hobbybäcker arbeite ich manchmal über Tage an einem Brot. Um ein perfektes Brot zu erhalten, ist es wichtig, die Prozesse der Entstehung zu kennen. Verstehe ich die Prozesse, beispielsweise die Gare, kann ich sie korrekt anwenden. Darüber hinaus brauche ich gute Zutaten und funktionierende Werkzeuge.
Welcher Teil – Prozess, Zutaten oder Werkzeuge – ist am kritischsten?
Der Prozess.
Die besten Zutaten und die besten Werkzeuge bringen nichts, wenn ich nicht weiss, was ich damit machen soll.
Bei Software bedeutet dies, dass ich vor allem verstehen muss, was die Software machen soll. Dann sind Technologie und Werkzeuge zweitrangig.

Wer kennt das nicht:
- “Wenn die Anforderungen bekannt wären, dann...”
- “Wenn die Anforderungen User Stories wären, dann...”
- “Wenn die Anforderungen vollständig wären, dann ...”

Anforderungen zu haben ist wichtig, doch die Realität sieht häufig anders aus.
Softwarelösungen sind oft über Jahre entstanden. Was die Software machen soll, steckt bereits im Quellcode und wurde durch sehr erfahrene und sehr engagierte Softwareentwickler:innen kodiert. Dieses eingebaute Fachwissen vom Quellcode zu trennen ist fast so unmöglich wie das Eiweiss vom Eigelb zu trennen, nachdem es verquirlt wurde.
Aber ohne dieses Fachwissen können Entwickler:innen die Software nicht wesentlich verbessern. Teile werden gelöscht und Funktionen umgeschrieben, ohne alle Zusammenhänge im Blick zu behalten, was zu immer neuen Fehlerwirkungen führt und letztendlich den Testaufwand in die Höhe treibt. Die Kosten für das Testen stehen in keinem Verhältnis zum generierten Mehrwert.
Agile Entwicklungsmethoden stellen daher die Anforderungen einer Software in den Mittelpunkt. Bei der Methode SCRUM ist die Rede von Business Value, also jenem Feature, das sich verkaufen lässt.
Einem Feature sind User Stories zugewiesen, die den Business Value enthalten.
Um den Business Value eines Features oder einer User Story zu rechtfertigen ist es nicht nur wichtig zu wissen, was die Software lösen soll, sondern auch warum.
Während das Fachwissen im Quellcode eingebaut wurde, entwich das “Warum”, ohne eine Spur zu hinterlassen.

Wenn ich Hersteller bin, beispielsweise von Taschenrechnern, baue ich verschiedene Funktionen oder Features ein (Addition, Subtraktion, usw.).
Mit der User Story erzähle ich dann, was die Kund:innen damit machen kann: Ich als Benutzer kann den Term 5+3-8 korrekt berechnen.
Die Kund:innen bezahlen für die Features, und die User Stories sollen ihm zeigen, was sie mit diesen Features machen können.
Bin ich aber auf die Entwicklung von kundenspezifischer Software spezialisiert, stehen die Features nicht im Fokus. Kunden sprechen von ihren Erfordernissen: Sie möchten beispielsweise den Term 5+3-8 korrekt ausrechnen können. Meine Aufgabe ist es dann, die zugrunde liegenden Erfordernisse zu identifizieren und daraus die geeigneten Anforderungen abzuleiten. Der Kunde bezahlt nicht für Features, sondern für die User Story.
Dieses einfache Beispiel zeigt, dass die starre Hierarchie von Anforderungen je nach Anwendung zu Problemen führen kann.
Das soll uns aber nicht daran hindern, qualitativ gute Software zu entwickeln.
Entscheidend ist, dass ich weiss, was der Kunde bezahlt (Feature oder User Story). Dann erfasse ich die Anforderungen präzise und maschineninterpretierbar, damit eine beliebige Toolchain mich zunehmend und langfristig unterstützen kann.

Wir sollten aufhören, von Anforderungen zu sprechen. Anforderung klingt nach vertraglich zugesicherten Leistungen, klingt nach Wasserfall, klingt nach vorsorglicher Absicherung, falls etwas schief geht.
Vor Jahren durfte ich bei der Neuentwicklung der Software einer vollautomatischen Kaffeemaschine erfahren, dass ausformulierte Anforderungen alleine nicht zu Qualität führen.
Wir hatten den Auftrag, die Software für einen Vollautomaten umzuschreiben. Weil die bestehende Software sehr kompliziert war (ein über die Jahre von Expert:innen geschriebener Quellcode), entschied man sich, den Quellcode neu zu schreiben. Der resultierende Quellcode war viel schlanker, effizienter und übersichtlicher. Er wurde intensiv getestet und entsprach allen guten Prinzipien guter Softwarequalität. Nur: Er funktionierte nicht. Niemand hatte daran gedacht, dass es für die Kaffeetemperatur einen Unterschied macht, ob man einen oder mehrere Espressi nacheinander macht. Niemand hatte dies berücksichtigt, denn uns fehlte die entsprechende Fachkompetenz. Wir passten den Quellcode an. Die resultierende Software funktionierte, war aber wieder so kompliziert, dass sie niemand verstand, ausser der Entwickler:innen, welche ihn geschrieben hatten.
Mit der notwendigen Fachkompetenz des Kunden hätten wir die richtigen Erfordernisse erkannt und so das Ziel beim ersten Anlauf erreicht.
Aus solchen Beispielen aus meinem beruflichen Alltag schliesse ich, dass die Fachkompetenz der Kunden für den Erfolg eines Softwareprodukts oder Softwareprojekts der entscheidende Faktor ist.

Eine gute Teststrategie soll darauf abzielen, soviel wie nötig zu testen, die fachliche Qualifikation der Software zu gewährleisten und die Qualität des Quellcodes für ressourcenschonende Bewirtschaftung vorzubereiten.
Einen qualitativ hochwertigen Quellcode herzustellen ist anspruchsvoll. Dafür gibt es aber viel Erfahrung in Form von Patterns, Werkzeugen, Richtlinien, Konzepten und vielem mehr.
Bei der Fachkompetenz in Bezug auf die zu lösende Aufgabe ist die Sache schwieriger. Wie erfasst man Fachkompetenz und worauf kommt es dabei an?
Und genau hier verbirgt sich meiner Meinung nach die Qualität einer Software.
Eine qualitativ gute Software bedient das Fach, unabhängig von der Implementation, sie schont Ressourcen bei der Entwicklung und Wartung und kann ohne fachliche Probleme auf neue Plattformen portiert werden.
In der Fachkompetenz liegen das Wissen und die Erfahrung einer Firma, ihrer Produkte und Dienstleistungen. Nicht im Quellcode. Dieser Mehrwert einer Firma kann nicht durch herkömmliche Software ersetzt werden, er gehört zum geistigen Eigentum einer Firma.
Das Ziel einer Firma sollte es also sein, ihr Fachwissen unabhängig von der Implementation, präzise und automatisiert lesbar und nutzbar zu erfassen. Dies sollte in einer Form geschehen, welche ohne Medienbruch direkt für fachliche Tests eingesetzt werden kann.
Für das Modellieren von Prozessen, das Abbilden von Fachwissen in Datenbanken und das Beschreiben von Fachwissen in fachspezifischen Sprachen gibt es viele Ansätze, Produkte und Methoden.
Es sollte das oberste Ziel eine Firma sein, ihr Fachwissen in ihrer eigenen Sprache abzubilden, damit dieses während der Entwicklung immer wieder direkt eingesetzt werden kann.
Mit geeigneten Werkzeugen kann das erfasste Fachwissen direkt, ohne Medienbruch, zum Testen eingesetzt werden. Änderungen in den Anforderungen finden so direkten Eingang in die Entwicklung und helfen letztendlich, die Qualität der Software hochzuhalten.
Die Teststrategie sollte sicherstellen, dass die Software dieses Fachwissen abbildet und dass der dazugehörende Quellcode eine ressourcenschonende und nachhaltige Bewirtschaftung ermöglicht.