Gezieltes Testen ist ein wichtiger Beitrag zur Früherkennung von Problemen. Es bietet wichtige Fingerzeige für präventive Nachbesserungen. Es kann helfen, die Ausbreitung eines Problems einzudämmen, bevor es zu einer ernsthaften Störung oder gar zu Schäden mit Notfallsituation kommt. Wichtig sind dabei rechtzeitiges Testen, wohldosierter Umfang, saubere Durchführung und sachkundige Auswertung. Improvisieren ist da fehl am Platz, und zielgerechtes Testen darf nicht von der ausführenden Person abhängen. Strukturierte Testbeschreibungen stellen hier ein nützliches Hilfsmittel dar. Ihre Erstellung ist gut investierte Zeit und bei Beachtung wichtiger Erfahrungen aus der Praxis auch gut machbar.
Lästiger Zeitfresser oder nützlicher Arbeitsgang?
Das Durchführen von Tests von IT-Lösungen kostet Zeit. Eine neue oder umfangreicher veränderte Installation kann erst entsprechend später zur produktiven Nutzung freigegeben werden. Ein Wartungseingriff zur Durchführung eines Patch- oder Update-Vorgangs dauert durch abschließende Tests länger.
Das vorbereitende Festlegen und Hinschreiben typischer Testinhalte und wichtiger Details zur Durchführung erledigt sich auch nicht von selbst. Überlegen, was wichtig ist, und dies so festhalten, dass jede sachkundige Person darauf basierend typische Tests zielsicher und in erprobter Weise vollzieht und auswertet, dauert mehr als ein paar Minuten.
Solche Zeit wird im IT-Alltag leider oft eingespart oder nur fallweise investiert, wenn etwas zum Thema „Testkonzeption“ vorgezeigt werden muss. Hat man so aber tatsächlich in der Endabrechnung Zeit „gespart“?
Das vermeintlich erfolgreich abgeschlossene Wartungsfenster muss als nachfolgender Incident nachbearbeitet werden. Bei einem aufwändigen Change-Vorgang zeigen sich am Ende Probleme, die zunächst einen Rollback, gar einen vollständigen Rückbau erforderlich machen. Für den IT-Betreiber ist das ärgerlich und bereitet Stress. Für die von einer so entstehenden Störung betroffenen Nutzerkreise ist das arbeitsbehindernd, wodurch ein Folgeschaden entstehen kann.
Hand auf’s Herz, wer hat noch nie solche Fälle erlebt und im Nachhinein das ungute Gefühl gehabt, etwas mehr präventive Kontrolle hätte das vermeiden oder zumindest Schlimmeres verhindern können?
Inhalte einer Testbeschreibung
Eine gute Testbeschreibung hat Gemeinsamkeiten mit einem Kochrezept: Wer nötige Grundkenntnisse mitbringt und konsequent der Beschreibung folgt, wird bei pannenfreier Durchführung zu einem klar bewertbaren Ergebnis kommen. Gelingt das nicht, sollte man gut erkennen können, an welcher Stelle des Durchlaufs es haperte, und kann die Ursache gezielt angehen.
Wie sieht eine Testbeschreibung in diesem Sinne aus? Wie detailliert sollte sie sein? Was sollte nicht fehlen?
Die Antworten hängen sicherlich davon ab, wie komplex eine IT-Lösung ist, und ob schon Betriebserfahrung mit vergleichbaren Technologien und Produkten besteht. Die mit dem Bild des Kochrezepts genannten Effekte geben aber gute Anhaltspunkte. Wichtige Inhalte einer konkreten Testbeschreibung vermeiden praxisrelevante Pannen der folgenden Art:
- Wichtige Hilfsmittel oder Beteiligte an der erfolgreichen Testdurchführung wurden vergessen und müssen erst eilig herbeigeholt werden.
- Durch Abweichen von einer erprobten Schrittreihenfolge kommt es zu Problemen. Es muss nun geklärt werden, ob dies an der Testdurchführung liegt oder daran, dass die getestete Lösung noch nachgebessert werden muss.
- Je nach Person, die den Test durchführt, wird unterschiedlich kontrolliert oder als „in Ordnung“ bewertet. Die Treffsicherheit von Testergebnissen und das Auffinden von Restproblemen hängen zu sehr von der persönlichen Erfahrung ab.
- Es ist unklar, was in jedem Fall zu prüfen ist. Bei verschiedenen Durchläufen des gleichen Tests bleiben mal aus betrieblicher Sicht wichtige Punkte ungeprüft, mal werden sicherheitsrelevante Aspekte nicht kontrolliert.
- Es wird nur „positiv“ geprüft. Wichtige Anzeichen auf Abweichungen vom gewollten, stabilen und sicheren Zustand der IT-Lösung werden nicht kontrolliert. Entsprechende Lehren aus vorbereitenden Labortests oder aus in der Vergangenheit erfolgreich bewältigten Incidents werden nicht berücksichtigt.
ComConsult unterstützt Kunden in verschiedenen Zusammenhängen bei Aufbau oder Verbesserung von Testbeschreibungen. Dabei hat sich das Arbeiten mit einer Strukturvorlage bewährt. Man legt zusammen mit dem IT-Betriebspersonal eine als geeignet und gut verständlich abgestimmte Struktur fest, nötigenfalls mit kleinen Erläuterungen zu den „Überschriften“.
Ein solches Muster kann eine mit einer IT-Lösung gut vertraute Person leicht befüllen, indem sie überlegt, worauf sie jemand anderes gezielt hinweisen würde, der einen bestimmten Test durchführen soll. Gezielte Hinweise sind dann mindestens solche, die Pannen der oben aufgezählten Art vermeiden helfen. Je nach Testgegenstand geben auch Angaben zu Zeitaspekten wesentliche Hinweise und sollten dann in einer entsprechenden Testbeschreibung enthalten sein.
Bestimmte Tests oder Testschritte können es mit sich bringen, dass die getestete IT-Lösung vorübergehend außer Funktion ist. Beispiele sind der Test eines ordnungsgemäßen Neustarts oder Tests zu Redundanzmechanismen. Beschreibungen von Tests, die solche Begleiterscheinungen mit sich bringen, sollten Zeitangaben zur typischen Dauer derartiger Testpunkte enthalten.
So lässt sich entscheiden, ob ein solcher Test zwingend in ein Wartungsfenster gelegt werden sollte und wie lange dieses mindestens sein muss. Auch die Einordnung im Rahmen eines gestuften Testplans wird erleichtert: Ist ein bestimmter Test geeignet als Teil eines Minimal-Testumfangs, etwa bei Routinetests zu Patches, oder als Emergency-Change-Abschluss?
Ähnlich bedeutsam sind Zeitangaben für Testschritte zu zeitkritischen Funktionalitäten:
Hat ein Test gemessen an der Angabe in der Testbeschreibung zu lange gedauert, kann dies ein Anzeichen auf ein verstecktes Restproblem sein. Verletzt die beim Test beobachtete Dauer gar eine Performance-Anforderung, z.B. die geforderte Umschaltzeit im Rahmen einer Redundanz, muss nachgebessert werden. Hier wird die Referenzzeit aus der Testbeschreibung zum wichtigen Parameter für die Aussagekraft eines Tests.
Abbildung 1: Inhalte einer Testbeschreibung
Wenn man vor einem solchen festgelegten Testplan-Muster sitzt und es nicht schafft, einen konkreten Test zu beschreiben, ist dies womöglich auch ein nützliches Testergebnis: Es kann ein Anzeichen dafür sein, dass man im IT-Bereich nochmal (gemeinsam) nachlegen muss, um die betroffene Lösung im aktuellen Zustand im Betrieb sicher zu beherrschen.
Testbeschreibungen können negative Testergebnisse und den mit der Nachbesserung verbundenen Aufwand nicht verhindern. Sie helfen aber, zielsicher und mit reproduzierbarer Qualität zu testen, und tragen so zur Störungsvermeidung bei. Die mit ihrer Erstellung und Pflege verbundene Zeit ist also gut investiert.
Noch ein abschließender Tipp:
Das Erstellen einer Testbeschreibung geht am leichtesten von der Hand, wenn das Wissen über die betroffene IT-Lösung und zu Punkten, auf die es ankommt, „frisch“ ist. Kurze Notizen und Screenshots, die man sich beim Erarbeiten des zu testenden Soll-Zustands nebenbei macht, sind da nützliches Material (was hat man gezielt austüfteln müssen, was war problematisch und sollte im Produktivzustand nicht gegeben sein, …). Keine solchen Notizen haben, und die Testbeschreibung erst mit großem zeitlichem Abstand erstellen – dann wird das eine zähe Angelegenheit, oft mit nur mäßig nützlichem Ergebnis.
