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.

Agile Prinzipien
Kundenfokus
Agile Toolbox
Scrum
bgloger-redakteur
September 7, 2016

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

KI als Teammitglied - Wie Scrum Master von generativer KI profitieren können
BG

KI als Teammitglied - Wie Scrum Master von generativer KI profitieren können

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein
BG

Die Bildungskrise und warum einfache Antworten nicht reichen – auch Scrum4Schools ist da nur ein Tropfen auf den heißen Stein

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?
BG

Ist KI der neue Kollege von Scrum Master, Agile Coach und Co?

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion
BG

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht
BG

Design Thinking - Wirkung auf Organisationen und Menschen neu gedacht

DeepWork für Autoren – Wie du dein Buch effizient schreibst
BG

DeepWork für Autoren – Wie du dein Buch effizient schreibst

Scrum ist tot, es lebe Scrum!
BG

Scrum ist tot, es lebe Scrum!

Agile Leadership ist nicht gleich agile Leadership
BG

Agile Leadership ist nicht gleich agile Leadership

Seth Godin über Strategie als Denkweise
BG

Seth Godin über Strategie als Denkweise

Die Essenz einer Erfolgreichen Geschäftsstrategie – Einsichten von Seth Godin 
BG

Die Essenz einer Erfolgreichen Geschäftsstrategie – Einsichten von Seth Godin 

Agiles Management – Warum es zur wichtigsten Errungenschaft der Moderne wurde
BG

Agiles Management – Warum es zur wichtigsten Errungenschaft der Moderne wurde

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion
BG

Scrum Beyond IT: Agile Methoden in HR, Marketing und Produktion