Gut sein, besser werden

Es ist unbestritten: der strukturierte Software-Test hat sich als Profession in der IT-Branche etabliert. Nicht zu testen kann sich kaum noch ein Unternehmen leisten, sei es aufgrund der steigenden Komplexität der Systeme, der Vorgaben und Reglementierungen oder aufgrund der immer größeren Erwartung an Qualität seitens der Anwender. Ob German Testing Board, Gesellschaft für Informatik e.V. oder Arbeitskreis Software-Qualität und -Fortbildung e.V. – die Gebetsmühlen für Test und Qualität haben gerade in Deutschland Früchte getragen. So gab es Mitte 2012 von weltweit 240.000 nach ISTQB zertifizierten Testern 25.000 alleine in Deutschland. Und auch ein Blick auf den Markt zeichnet ein ähnliches Bild: Die Dichte und Bandbreite an Dienstleistern und Beratungshäusern mit einem Fokus auf Software-Test ist groß. Vom kleinen lokalen Unternehmen bis zum global agierenden Konzern ist alles dabei. Und der Bedarf an professionellen Testern bleibt hoch, das zeigen die vielen offenen Stellen in diesem Bereich. Und während die einen erst beginnen, ihren Test zu strukturieren und zu professionalisieren, sind die anderen schon so weit, um sich an Themen wie Testprozessverbesserung zu machen. Auch diese Modelle sind ausgereift und werden immer besser. Auch wenn man das als Tester immer etwas kritisch sieht, kann man sagen: “Testing made in Germany”: Ja – wir machen das gut!

…und wir wollen besser werden! Doch neben all den Möglichkeiten, die uns Testprozessverbesserungen bieten, gibt es noch andere Dinge, bei denen Tester noch viel Potential haben:

1. Die Sicht durch die Kundenbrille. Letztendlich entsteht Software immer für Anwender. Sei es ein Endkunde oder ein Fachbereichsmitarbeiter. Und auch wenn alle funktionalen und nicht-funktionalen Anforderungen geprüft sind, heißt es noch lange nicht, dass der Anwender dann auch zufrieden ist. Das ist aber das Ziel des Tests. Als Tester sollte man sich immer wieder von den definierten Testkonzepten und Testfalllisten lösen, um somit frei und ohne Vorgaben von außen auf die Applikation blicken zu können. Ist die Lösung brauchbar? Ist sie einfach zu bedienen? Macht es Spaß damit zu arbeiten? Nützt sie dem Anwender? Man läuft so leicht Gefahr die technische Lösung als gegeben zu akzeptieren, sodass man gar nicht darüber nachdenkt, ob diese überhaupt sinnvoll ist. So gibt es z.B. Unmengen an Programmen, die vor Konfigurationsmöglichkeiten nur so strotzen – die aber nie verwendet werden. Als Tester muss man diesen Blick von außen riskieren und auch Dinge aufzeigen, die vielleicht nicht explizit in den Anforderungen stehen – auch wenn vielleicht mit Gegenwind und Diskussionen zu rechnen ist.
2. Kreative Lösungen: Als Tester steht man meist vor vielen Herausforderungen und wenig Zeit. Es gibt für deren Bewältigung ein gut sortiertes Werkzeug- und Methodenset. Diese lassen sich 1:1 benutzen, aber gerade in deren kreativer Anwendung steckt viel mehr Potential. Mit neuen Ideen, einem Blick über den Tellerrand und gesundem Menschenverstand lassen sich so qualitativ viel bessere Testfälle erstellen und damit mehr Fehler finden. Wie wäre es mit einer einstündigen Äquivalenzklassensammelsession im Team? Oder einem Kaffee mit dem Fachbereich und zwei abgeleiteten Zustandsdiagrammen? Auch bei der Automatisierung muss vielleicht nicht jeder Fall in der großen Testautomatisierungssuite implementiert werden, wenn es ein kleines Skript auch tut – und das noch schneller. Zudem muss man nicht jedes Problem selbst lösen – viele Lösungen finden sich in den Weiten des Internets – oder auch einfach bei einem anderen Tester oder Entwickler. Einfach mal fragen!

Testern, die in agilen Teams arbeiten, kommt das vertraut vor. Das Feedback und der ständige Austausch miteinander fördern die Kreativität und das Verständnis. Durch kurze Sprints sind schnelle Lösungen erforderlich. Lange Problemwälzereien werden durch die knallharte Transparenz der Daily Meetings enttarnt. Und dabei werden Tester und Entwickler im Team laufend auf ein Ziel eingenordet: Mit dem Ergebnis, beim Kunden Nutzen zu stiften.

Dazu braucht es nicht zwangsläufig ein agiles Vorgehen. Viele Dinge lassen sich auch in traditionellen Projekten umsetzen, denn es kommt auf die Einstellung und das Mindset an. Als Tester kann ich mich immer dazu entscheiden, etwas anders als bisher zu machen: Nicht nur Testfälle abzuarbeiten, sondern über den Tellerrand zu blicken, Ideen zu entwickeln, Lösungen zu diskutieren, auch Missstände dann aufzuzeigen, wenn sie nicht auf niedergeschriebenen Anforderungen basieren.