Exploratives Testen: Finden wir raus, was wir nicht wissen!

Menschen, die Software benutzen, machen manchmal Dinge, an die kein Entwickler oder Tester denkt. Mit systematischen Tests und durch Testautomatisierung lässt sich zwar ein hohes Maß an Testabdeckung erreichen, aber es besteht immer das Risiko, Fehler zu übersehen. Sie lassen sich nicht durch Automatisierung aufdecken, sondern nur durch das kreative Gehirn eines guten Testers.Grundsätzlich gibt es drei Ansätze, wie Software getestet werden kann:

1. Wir gehen davon aus, dass wir wissen, was uns erwartet. Die Anforderung ist klar formuliert. Wenn ich <Username x> in das <Feld y> eingebe, dann passiert <Aktion z>. Das wollen wir mit einem sogenannten „Gutfall-Test“ überprüfen.
2. Wir wissen nicht, was passiert, wenn wir eine bestimmte, falsche Eingabe machen, oder das Programm mitten in der Datenverabeitung schließen. Diesen Fall wollen wir mit einem sogenannten „Negativ-Test“ überprüfen.
3. Es gibt aber Dinge, von denen man gar nicht weiß, dass man sie nicht weiß. Das kann vor allem bei Software passieren, die man seit Jahren testet - hier entsteht leicht eine Betriebsblindheit. Man konzentriert sich, teilweise auch aus Zeitmangel, nur noch auf das Testen von Akzeptanzkriterien. Aber haben die Tester und Entwickler die Anforderungen genau so verstanden, wie der Fachbereich sie gestellt hat? Haben sie etwas übersehen?

Das Programm aus Anwendersicht erkunden

Beim explorativen Testen nimmt der Tester die Perspektive eines Users ein und begibt sich auf eine Reise durch das Programm. Je nachdem was man entdecken möchte, können das völlig unterschiedliche Reisen sein. Zum Beispiel kann man die Rolle eines Hackers einnehmen, der Spaß daran hat, im Programm Sicherheitslücken zu finden, die er ausnutzen könnte. In dieser Rolle versucht man möglichst ungültige oder ungewöhnliche Eingaben und Aktionen zu machen, um herauszufinden, wie stabil das Programm bleibt. Oder man nimmt die Rolle eines Users ein, der im Umgang mit einem Computer ungeübt ist. Auf dieser Reise möchte man herausfinden, ob das Programm leicht und selbsterklärend zu bedienen ist. Viele andere Rollen und die zugehörigen Reisen werden im Buch „Exploratory Software Testing“ von James A. Whittaker anschaulich beschrieben. Der Autor geht auch darauf ein, warum manche Programmfehler unentdeckt bleiben und wie uns die Technik des explorativen Testens dabei helfen kann, diese doch noch zu finden.In einem Projekt, in dem ich als Softwaretesterin gearbeitet habe, hat sich das gesamte Scrum-Team jeden Morgen nach dem Daily-Scrum zusammengefunden und festgelegt, wer welche Reise macht.Jedes Mitglied des Entwicklungsteams (Tester, Softwareentwickler, Analysten) nahm dabei eine User-Rolle ein und startete eine Reise durch das gesamte System. Die ersten 15 Minuten des Tages waren immer dem exoplorativen Testen gewidmet. Wir konnten so aus „wir wissen nicht, was wir nicht wissen“ oft ein „wir wissen, dass....“ machen.Natürlich gehört eine Dokumentation der Ergebnisse dazu. Diese sollte jedoch so knapp wie möglich und so umfangreich wie nötig sein, denn 15 Minuten pro Tag sind kurz - da will man die Zeit nicht mit überdetaillierter Testdokumentation verstreichen lassen. Es genügt zum Beispiel eine Checkliste oder eine Mindmap: Die bereitet man vor, um sich auf das zu fokussieren, was man in dieser Testsession herausfinden will. Die Punkte auf der Liste, die beim explorativen Testen rot geworden sind (also fehlgeschlagen sind), kann man danach in weiterführende Testfälle umwandeln.Exploratives Testen holt jedes Teammitglied für kurze Zeit aus der Tagesroutine raus, macht Spaß und hilft dabei, das Programm kennenzulernen und so neue, kreative Ideen zu entwickeln. Egal ob man Tester, Entwickler oder Analyst ist: Kreativität ist bei jeder Produktentwicklung gefragt.