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:
- 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.
- 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.
Häufig gestellte Fragen
Warum können es sich Unternehmen kaum noch leisten, auf strukturiertes Testen zu verzichten?
Drei Treiber nannte der Artikel 2013: die steigende Komplexität der Systeme, Vorgaben und Reglementierungen sowie die wachsende Qualitätserwartung der Anwender. Der Software-Test hatte sich damit als eigene Profession in der IT-Branche etabliert. Sichtbar wurde das auch am Markt: Dienstleister und Beratungshäuser mit Testfokus reichten vom kleinen lokalen Anbieter bis zum global agierenden Konzern.
Wie stark ist der Software-Test in Deutschland als Profession verankert?
Deutschland stellte 2012 einen auffällig großen Anteil der zertifizierten Tester: Von weltweit 240.000 nach ISTQB zertifizierten Testern arbeiteten 25.000 allein in Deutschland. Der Artikel führte das auf die jahrelange Arbeit von Organisationen wie dem German Testing Board, der Gesellschaft für Informatik und dem Arbeitskreis Software-Qualität und -Fortbildung zurück. Der Bedarf an professionellen Testern blieb damals hoch.
Ist ein Test erfolgreich, wenn alle funktionalen und nicht-funktionalen Anforderungen geprüft sind?
Nein. Geprüfte Anforderungen bedeuten nicht, dass der Anwender zufrieden ist, und genau das ist das Ziel des Tests. Software entsteht immer für Menschen, sei es ein Endkunde oder ein Fachbereichsmitarbeiter. Deshalb gehören Fragen dazu wie: Ist die Lösung brauchbar? Ist sie einfach zu bedienen? Nützt sie dem Anwender überhaupt?
Sollen Tester auch Probleme melden, die in keiner Anforderung stehen?
Ja. Ein Tester sollte den Blick von außen riskieren und Missstände auch dann aufzeigen, wenn sie nicht auf niedergeschriebenen Anforderungen beruhen, selbst wenn Gegenwind und Diskussionen zu erwarten sind. Wer die technische Lösung als gegeben hinnimmt, prüft gar nicht mehr, ob sie sinnvoll ist. Beispiel: Programme voller Konfigurationsmöglichkeiten, die nie jemand verwendet.
Wie lassen sich klassische Testentwurfsmethoden kreativer nutzen?
Methoden lassen sich 1:1 anwenden, doch im kreativen Umgang steckt mehr Potential für bessere Testfälle und damit mehr gefundene Fehler. Genannte Beispiele: eine einstündige Sammelsession zu Äquivalenzklassen im Team oder ein Kaffee mit dem Fachbereich, aus dem zwei Zustandsdiagramme entstehen. Und nicht jedes Problem muss selbst gelöst werden: andere Tester oder Entwickler fragen.
Muss jeder Testfall in die große Testautomatisierungssuite?
Nein. Wenn ein kleines Skript denselben Zweck erfüllt und schneller fertig ist, reicht es aus. Der Artikel plädierte dafür, Werkzeuge und Methoden nach gesundem Menschenverstand einzusetzen, statt jeden Fall formal in die vorhandene Automatisierungslösung zu zwingen. Tester stehen meist vor vielen Herausforderungen und wenig Zeit, das spricht für pragmatische Lösungen.
Braucht es agile Projekte, damit Tester kreativer und kundennäher arbeiten?
Nein. Agile Teams begünstigen das zwar: ständiges Feedback fördert Kreativität und Verständnis, kurze Sprints erzwingen schnelle Lösungen, und Daily Meetings decken langes Problemwälzen auf. Vieles davon lässt sich aber auch in traditionellen Projekten umsetzen, denn entscheidend sind Einstellung und Mindset. Ein Tester kann sich jederzeit entscheiden, nicht nur Testfälle abzuarbeiten, sondern Ideen zu entwickeln und Lösungen zu diskutieren.
