Zur Qualitätssicherung in der Baustatik
So schön die Vorgängerprogramme der Baustatik waren, es gab doch immer wieder ein ganz bestimmtes Problem: Mit einem Update wurde ein Fehler behoben - es stellte sich dann aber heraus, das dadurch ein anderes Problem auftrat. Besonders unschön ist sowas natürlich bei den Berechnungsergebnissen.
In der Baustatik habe wir diesem Problem Rechnung getragen, und gleich einen ganzen Satz an Werkzeugen eingebaut, mit dem solche (und ähnlich gelagerte) Qualitätsprobleme vermieden werden können - und Probleme im allgemeinen schneller erkannt und besser beseitigt werden können.
Dazu zählen unter anderem die folgenden Dinge:
· Einführung eines Programms zur Verwaltung und Zuordnung von Problemen und den damit zusammenhängenden Aufgaben - also quasi ein Ticketing-System. Wir verwenden dazu FogBugz.
· Einführung eines deutlich besseren Revision-Control-Systems. Wir verwenden Vault.
· Einführung eines Mechanismus zur Meldung von Programmabstürzen. Wenn das Programm in einen Zustand gerät, den es nicht behandeln kann, dann erscheint ein entsprechendes Meldungsfenster - und die Anwender können dann entscheiden, uns diesen Fehler mitzuteilen: Wenn das passiert, entsteht dadurch (meist) ein neuer "Fall" in der FogBugz - Datenbank, ein Entwickler nimmt sich dessen an, und die Lösung nimmt ihren Lauf. Beim nächsten Update (also Anfang des jeweiligen Folgemonats) sollte das Problem spätestens beseitigt sein.
· Einführung eines Mechanismus für "automatische" Updates - also Updates, die das Programm selbstständig herunterladen kann. Das stellt sicher, das die im vorher genannten Schritt eingeführten "Verbesserungen" auch tatsächlich beim Kunden ankommen.
· Und - ganz wichtig, und am aufwendigsten von allen genannten Punkten - die Einführung sogenannter Testcases. Und genau um diese Testcases dreht sich der Rest dieses Beitrages.
Die Testcases
Bei den Testcases geht es in erster Linie um eines: Wir wollen sicherstellen, das eine Veränderung am Programm nicht dazu führt, das bisher richtige Berechnungsergebnisse plötzlich falsch werden. Sowas kann zum Beispiel auf folgende Art passieren: Ein Entwickler verändert irgendetwas an der internen Repräsentation der Materialien. Das ist weiter nicht schlimm und passiert auch in der Tat hin und wieder - aber bei dieser einen Änderung wurde plötzlich ein Fehler eingeführt der seinerseits dazu führt, das die Einheit für eine Eigenschaft eines einzelnen Materials nicht mehr stimmt.
Führt man also nun eine Berechnung durch, bei der dieses eine Material verwendet wird, dann kommen falsche Ergebnisse raus. Dumm gelaufen. Sowas kann natürlich auch auf vielerlei Arten passieren: Die Anpassung eines Bemessungsalgorithmus für einen Spezialfall führt dazu, das plötzlich ein anderer Spezialfall nicht mehr klappt, eine Änderung am Matrix-Solver führt dazu, das die Schnittgrößen (und damit alles andere) in Randgebieten nicht mehr stimmen - und so weiter und so fort.
In diesem automatischen Zustand lädt das Programm einen recht umfangreichen (und ständig wachsenden) Bestand an Eingabedateien (Dokumenten), und führt für die geladenen Daten alle Berechnungen durch, die damit durchgeführt werden können. (Als Nebeninfo: Allein im Dokumenten-Typ "Faltwerk" geht es da um einige tausend unterschiedlicher Berechnungsergebnis-Arten.)
Die dadurch entstehenden Ergebnisse werden dann mit einem Satz an Ergebnissen verglichen, die zuvor aus Berechnungen mit dem gleichen Dokument ermittelt wurden und als "korrekt" bekannt sind. In diesem Zusammenhang können die unterschiedlichsten Probleme auftreten und gefunden werden:
· Ein benötigtes FE-Netz kann bei einem System nicht mehr generiert werden - die Vorgängerversion des Programms konnte das aber noch.
· Ein Berechnungsergebnis kann nicht mehr ermittelt werden - vorher ging das aber; und auch das Gegenteil deutet auf ein Problem hin: Vorher konnte ein bestimmtes Ergebnis nicht ermittelt werden - und plötzlich geht es.
· Ein einzelner Ergebniswert weicht von Wert des Ergebnisses aus der vorherigen Berechnung ab.
· Etc. pp. - die Liste ist wirklich recht lang
Für alle Dateien wird dann ein Protokoll der gefundenen (oder nicht gefundenen) Probleme erzeugt und über unser Intranet veröffentlicht. Am nächsten Morgen können also alle Entwickler auf die schnelle sehen, ob die "aktuelle" Version irgendwelche Probleme bereitet, und "gestern" ein Fehler ins Programm eingeführt wurde.
Das ist natürlich kein Allheilmittel - auch in Zukunft wird es hin- und wieder zu Problemfällen bei Berechnungsergebnisse kommen: Diese sollten aber nur noch extrem selten auftreten - und das ist auch genau das Verhalten, das ich seit der Veröffentlichung der ersten Version der Baustatik beobachtet habe.