In The Code: Context-Driven Testing

Fachartikel für inside-it.ch vom 7. November 2017

Seit vielen Jahren sind wir als Test Engineers in Unternehmen unterschiedlicher Grösse tätig. In verschiedenen Projekten haben wir Erfahrungen mit Testautomatisierung gesammelt. Die Herausforderungen glichen sich in all diesen Projekten: ständige Veränderung der Benutzeroberfläche durch neue Kundenanforderungen, nicht adressierbare Objekte im GUI, Timeouts beim Laden von Seiten, unzuverlässig erscheinende Elemente oder unzureichende Kommunikation zwischen Entwicklungs- und Testteams.

Solche Probleme allein erklären das Scheitern von Automatisierungsprojekten nicht. Und doch hören wir immer wieder von abgebrochenen Automatisierungsversuchen, auch wir selbst haben diese Erfahrung bereits gemacht. Was sind denn die Gründe, wenn wir die erwähnten technischen und organisatorischen Schwierigkeiten nicht als Erklärungen akzeptieren? Der eigentliche Grund ist vordergründig einfach: Der erzielte Nutzen rechtfertigt die Kosten nicht.

Undokumentierte Kundenerwartungen berücksichtigen

Softwareentwicklung ist keine standardisierbare Fliessbandarbeit. Mit einem Testansatz, der einzig auf Automatisierung basiert, werden wir ihrem komplexen Wesen nicht gerecht. Was nützt uns eine umfangreiche Suite an gekonnt umgesetzten automatisierten Tests, mit der wir alle Aspekte der Spezifikation abdecken, wenn wir uns im Test nicht mit den undokumentierten Erwartungen unserer Kunden auseinandersetzen? Der Nutzen, der durch einen solchen mechanistischen Testansatz erzielt wird, rechtfertigt die damit verbundenen hohen Kosten in der Regel tatsächlich nicht.

Mit einem eindimensionalen Blick auf das Testing verschliessen wir die Augen vor vielen Fragestellungen, die für erfolgreiches Testing relevant sind. In der Ergon verfolgen wir hierzu den Context Driven-Ansatz, der die konsequente Anpassung des Testvorgehens an die Eigenheiten in jedem Projekt propagiert.

Testing ist eine soziale Tätigkeit

Der Context Driven-Testing-Ansatz stellt den Wert in den Vordergrund, den wir mit unseren Systemen für uns und für unsere Kunden generieren. Alles was diesen Wert gefährden kann, ist ein potentielles Problem, ein potentieller "Bug". Eine wichtige Aufgabe für uns als Tester ist das Sammeln und Aufbereiten von Informationen für unsere Stakeholder zur Unterstützung von Entscheidungsprozessen.

Dabei lassen wir uns leiten von einer von den Projektrisiken abgeleiteten Testmission, die je nach Projekt oder Projektphase völlig unterschiedlich ausfallen kann. In einem Projekt steht eine allgemeine Aussage über den Zustand des Systems im Vordergrund, in einem anderen soll die Zertifizierung gegenüber einem internationalen Standard sichergestellt werden. In einem dritten Projekt prüfen wir eine wichtige Schnittstelle zu einem Umsystem auf Herz und Nieren, um die Konsistenz der Daten im System zu garantieren.

Von unserer Testmission leiten wir ein konkretes Testvorgehen ab. Dabei berücksichtigen wir relevante Rahmenbedingungen wie zum Beispiel Verfügbarkeit von Personal und Infrastruktur. Das Testvorgehen setzt sich zusammen aus einem Mix von Testverfahren, mit deren Gesamtheit wir unsere Testmission verfolgen. Automatisierte Tests spielen dabei fast immer als Entwicklertests eine wichtige Rolle. Nur ganz selten reichen aber automatisierte Tests als alleiniges Verfahren aus, um unsere Testmission zu erfüllen.

Das gilt sowohl für das Testing in traditionellen Entwicklungsprozessen wie auch in Projekten mit agilen Vorgehensweisen. In agilen Projekten erhält die Testautomatisierung aufgrund der kürzeren Lieferzyklen eine höhere Bedeutung. Aber auch dort gilt: Mit einem Mix an Testverfahren können wir unsere Testmission zielgerichteter und effektiver verfolgen.

Testing ist eine soziale Tätigkeit, da es sich an der Schnittstelle zwischen technischen uns sozialen Systemen bewegt. Eine zentrale Frage für uns ist immer: Kann mit dem aktuellen System der intendierte Nutzen für Benutzer oder Auftraggeber des Systems erreicht werden? Das bedeutet unter anderem, dass wir Kundenanforderungen richtig verstehen müssen. Idealerweise sind Tester von Beginn weg in die Projekte involviert, damit sie schon in der Konzeptphase Ideen hinterfragen und potentielle Probleme erkennen können. "Deckt die beschriebene Lösung wirklich die Bedürfnisse der Nutzer an der Front ab?" "Lohnt sich die mit diesem Feature einhergehende Komplexität wirklich auf lange Sicht?"

Im weiteren Verlauf des Projekts verändern sich die Fragestellungen: "Wurde das System so umgesetzt wie geplant?" "Wurde der intendierte Nutzen eines Features tatsächlich realisiert?" Oder: "Müssen wir das Feature noch verbessern, um unsere Benutzer optimal zu unterstützen?"

Mit diesem Verständnis von Testing können wir in einem umfassenderen Sinn mögliche Probleme und damit "Bugs" erkennen, so dass unsere Software auch wirklich ihren intendierten Zweck erfüllen und damit den erwarteten Wert generieren kann.

Diesen Auftrag ans Testing können wir mit einem eindimensional auf Automatisierung ausgerichteten Testvorgehen nicht erfüllen.

Die Ausbildung von Ergon-Testern

Ein erstes Credo von Ergon ist, dass alle Ingenieure ihre Software selber testen. Dies geschieht in Code Reviews, individuell mit Unit Tests oder anderen Formen von automatisierten und manuellen Tests. Diese Entwicklertests sind das Fundament für stabile und nachhaltig wartbare Software.

Daneben arbeiten wir für die Systemtests nach dem Context-Driven Ansatz mit einem Team von temporären Testern (meist Maturanden oder Werkstudenten), die zwischen neun und zwölf Monaten bei uns arbeiten. Diese werden durch erfahrene Tester ausgebildet und in den Projekten begleitet.

Von unseren Testern erwarten wir keine technische Vorbildung oder Vorkenntnisse im Testing. Entscheidend sind Neugier, Engagement, ein gewisses technisches Flair sowie den Willen zur persönlichen Weiterentwicklung. Wir schulen unsere Tester mit bewährten Konzepten, wie sie zum Beispiel auch in den anspruchsvollen Online-Schulungen zum Black Box Software Testing der Association for Software Testing (AST) unterrichtet werden.

Unsere Ansprüche sind hoch, wir bieten aber auch viel: Wir vermitteln die nötigen Skills, um später, z.B. während eines Studiums, als professioneller Tester arbeiten zu können. Wir unterstützen unsere Tester intensiv, wenn wir sie von Anfang an ins kalte Wasser werfen und in verantwortungsvoller Position in Projekten involvieren. Wir vermitteln ihnen die notwendigen und zum Teil anspruchsvollen Werkzeuge für ihre Arbeit. Von ihnen erwarten wir selbstständiges Mitdenken und Widerspruch, wenn Dinge für sie keinen Sinn ergeben. Sehr wichtig ist mir, dass auch wir erfahrene Tester von ihnen immer wieder herausgefordert und hinterfragt werden.

Die Schulung erfolgt durch ein zweimonatliches Kurrikulum mit wöchentlichen Unterrichtseinheiten und praktische Übungen, bei denen unsere Tester erlernte Testverfahren an realen Projekten ausprobieren. Gutes Testen ist kognitiv anspruchsvoll, denn man muss mit möglichst vielen unterschiedlichen Ansätzen an ein Problem herangehen. Dazu gehört nicht nur die nötige Intelligenz, sondern auch viel Übung.

Für Context-Driven Tester ist die Fähigkeit zentral, präzis und nachvollziehbar Auskunft zu geben über ihre Arbeit: Es geht darum, in den Tests gewonnene Informationen für unsere Stakeholder als Entscheidungsgrundlage aufzuarbeiten. Diesen Aspekt schulen wir gezielt: Unsere Tester dokumentieren ihre Tests detailliert in Session Notes. In regelmässigen Debriefings berichten sie über ihre Erfahrungen: das gewählte Vorgehen, durchgeführten Tests, gefundene Probleme und Erkenntnisse für das weitere Testvorgehen. Wir nutzen diese Debriefings für das Coaching und für die Steuerung der Testaktivitäten in den Projekten zugleich.

Testen ist ein Lernprozess

Ein zentraler Gedanke des Context-Driven Ansatzes ist die Nutzung der in den Tests gewonnenen Informationen zur Steuerung des weiteren Testvorgehens. Mit jedem Test lernen wir unsere Systeme besser kennen. Wir entdecken neue Risiken und Schwachstellen, antizipierte Risiken lösen sich bei den Tests in Luft aus, wir entdecken unerwartete Stärken, die weiterverfolgt werden können. Und wir entwickeln neue Testideen, die es uns ermöglichen, weitere Lernschritte zu machen.

Testen als Lernprozess mit dem Ziel, Entscheidungsgrundlagen für unsere Stakeholder zu schaffen: Dies kann weder Testautomatisierung noch manuelles Testing mittels genau vorgeschriebenen Testprozeduren leisten.

Context-Driven Testing ist anspruchsvoll und braucht viel Übung. Qualifizierte Tester sind am Markt schwer zu finden, nicht zuletzt, weil die Vermittlung von Testing Skills in der Ausbildung für Software Engineers sträflich vernachlässigt wird.

Die Testing-Ausbildung von Praktikanten und Werkstudenten ist unsere Antwort auf dieses Problem. Ein Nachteil für unser Modell ist vor allem die begrenzte Beschäftigungsdauer unserer Tester. Nach 12 Monaten ziehen sie weiter und ihr Know-how ist für uns verloren. Dies ist gerade deshalb schade, weil viele von ihnen ein recht hohes Niveau erreichen.

Fazit: Automatisierte Tests sind heute erfreulicherweise in vielen Organisationen ein integraler Bestandteil des Entwicklungsprozesses geworden. Davon profitieren wir Tester, weil es uns von notwendiger repetitiver Arbeit entlastet und somit Freiräume eröffnet. Diese Freiräume nutzen wir für kreative Experimente zum Finden von Informationen, mit denen wir unsere Stakeholder in ihrer Arbeit unterstützen.

Sandro Ibig arbeitet als Test Engineer bei Ergon Informatik AG, Roland Weber ist Leiter des Testerteams und ebenfalls Test Engineer bei Ergon.