Exploratives Testen

Exploratives Testen ist ein Ansatz zum Testen von Software, der als gleichzeitiges Lernen, Testdesign und Testausführung beschrieben wird. Cem Kaner, der den Begriff 1984 geprägt hat[1], definiert exploratives Testen als "einen Stil des Softwaretests, der die persönliche Freiheit und Verantwortung des einzelnen Testers betont, die Qualität seiner Arbeit kontinuierlich zu optimieren, indem er testbezogenes Lernen, Testdesign, Testdurchführung und Interpretation der Testergebnisse als sich gegenseitig unterstützende Aktivitäten verwendet, die während des gesamten Projekts parallel ablaufen."[2]

Während die Software getestet wird, lernt der Tester Dinge, die zusammen mit Erfahrung und Kreativität neue Tests hervorbringen. Exploratives Testen wird oft fälschlicherweise als Black-Box-Testtechnik angesehen. Korrekterweise ist es ein Testansatz, der auf jede Testtechnik in jeder Phase des Entwicklungsprozesses angewendet werden kann. Der Schlüssel ist weder die Testtechnik noch das zu testende oder zu überprüfende Objekt. Der Schlüssel ist das kognitive Engagement des Testers und die Eigenverantwortung des Testers für den sinnvollen Einsatz seiner Zeit fürs Testen.[3]

Geschichte

[Bearbeiten | Quelltext bearbeiten]

Explorative Tests wurden schon früher von erfahrenen Testern durchgeführt. In den frühen neunziger Jahren war Ad-hoc oft ein Synonym für schlampige und nachlässige Arbeit. Infolgedessen begann eine Gruppe von Testmethodikern (die sich jetzt als kontextgesteuerte Schule bezeichnen), den Begriff "explorativ" zu verwenden, um den vorherrschenden Denkprozess bei Tests ohne Skript hervorzuheben und die Praxis zu einer lehrbaren Disziplin zu entwickeln. Diese neue Terminologie wurde erstmals von Cem Kaner in seinem Buch Testing Computer Software[4] veröffentlicht und in Lessons Learned in Software Testing.[5] erweitert. Exploratives Testen kann genauso wie jede andere intellektuelle Aktivität gelernt werden.

Beschreibung

[Bearbeiten | Quelltext bearbeiten]

Explorative Tests versuchen herauszufinden, wie die Software tatsächlich funktioniert, und Fragen zu stellen, wie sie mit schwierigen und einfachen Fällen umgehen kann. Die Qualität des Tests hängt von der Fähigkeit des Testers ab, Testfälle zu erfinden und Programmfehler zu finden. Je mehr der Tester über das Produkt und die verschiedenen Testmethoden weiß, desto besser wird der Test.

Explorative Tests können mit ihrer Antithese, den geskripteten Tests verglichen werden. Bei geskripteten Tests werden Testfälle im Voraus entworfen. Dies umfasst sowohl die einzelnen Schritte als auch die erwarteten Ergebnisse. Diese Tests werden später von einem Tester durchgeführt, der das tatsächliche Ergebnis mit dem erwarteten vergleicht. Bei der Durchführung von explorativen Tests sind die Erwartungen offen. Einige Ergebnisse können vorhergesagt und erwartet werden; andere vielleicht nicht. Der Tester konfiguriert, betreibt, beobachtet und bewertet das Produkt und sein Verhalten. Er untersucht das Ergebnis kritisch und meldet Informationen, bei denen es sich wahrscheinlich um einen Fehler handelt (der den Wert des Produkts reduzieren könnte) oder um ein Problem (das die Qualität des Testens gefährdet).

In der Praxis ist das Testen fast immer eine Kombination aus explorativen und skriptbasierten Tests, jedoch mit einer Tendenz zu beiden, je nach Kontext.

Laut Cem Kaner und James Marcus Bach ist exploratives Testen eher eine Denkweise oder "... eine Art, über das Testen nachzudenken" als eine Methodik.[6]

Die Dokumentation von explorativen Tests reicht von der alleinigen Dokumentation der gefundenen Fehler bis hin zur Dokumentation aller durchgeführten Tests.

Beim Pair testing testen zwei Personen gemeinsam, oftmals besteht das Paar aus einem professionellen Tester und einem Softwareentwickler oder einem Business-Analyst. Als Nebeneffekt gewinnt im ersten Fall der Softwareentwickler voraussichtlich Einsichten über Risiken, während der Tester einen Einblick in die Architektur erhält. Wenn ein Tester und ein Business-Analyst im Paar arbeiten, wird der Tester dabei wahrscheinlich mehr vom Geschäft und den Erwartungen an die Software lernen.[7]

Strukturiert exploratives Testen kurz SET ist eine Methode des explorativen Testens, bei der es darum geht weiter zu gehen als bloß bei den spezifizierten Anforderungen. Man macht sich Gedanken zu Abläufen an die zuvor noch niemand gedacht hat. Bei der Durchführung geht es darum, dass es eine vorgegebene Zeitdauer gibt, in welcher die Testpersonen ein vorher definiertes Testziel testen. Nachdem die Zeitdauer abgelaufen ist, tauschen sich die Testpersonen aus und zeigen ihre Erkenntnisse auf. Die Erkenntnisse müssen dokumentiert werden.

Sessionbasiertes Testen ist eine Methode, die speziell entwickelt wurde, um explorative Tests in größerem Maßstab überprüfbar und messbar zu machen.

Explorative Tester verwenden häufig Tools, einschließlich Bildschirmaufnahme- oder Video-Tools als Aufzeichnung bzw. Dokumentation der Tests, oder Tools, um schnell für den jeweiligen Tests interessante Situationen zu generieren, z. B. James Bachs Perlclip.

Vor- und Nachteile

[Bearbeiten | Quelltext bearbeiten]

Der wichtigste Vorteil explorativen Testens gegenüber herkömmlichem Test besteht darin, dass weniger Vorbereitung erforderlich ist, wichtige Fehler schnell gefunden werden und bei der Durchführung intellektuell anregender ist als die Ausführung von Skripttests.

Ein weiterer großer Vorteil besteht darin, dass Tester auf Ergebnisse früherer Tests reagieren, und ihre aktuellen Tests geeignet verändern können. Sie müssen keine Reihe von Skripttests absolvieren, sondern können sich zielgerichtet auf neue Anforderungen konzentrieren oder diese erkunden. Dies beschleunigt auch die Fehlererkennung.

Ein weiterer Vorteil ist, dass die meisten Fehler eines Programmes oder Programmteiles bei explorativem Testen bereits nach kurzer Zeit entdeckt werden. Programme, die bestimmte Tests bestehen, bestehen in der Regel weiterhin dieselben Tests und bestehen mit größerer Wahrscheinlichkeit andere Tests oder Szenarien, die noch nicht untersucht wurden."

Ein Nachteil explorativen Testens ist, dass die im laufenden Betrieb erfundenen und durchgeführten Tests, nicht im Voraus überprüft werden können, wodurch Missverständnisse hinsichtlich der Anforderungen oder Fehler in Testfällen entstehen können. Weiterhin kann es schwierig sein, genau zu zeigen, welche Tests durchgeführt wurden. Die Nachvollziehbarkeit der gefundenen Fehler leidet unter Umständen darunter.

Es ist unwahrscheinlich, dass explorative Tests bei einer erneuten Durchführung auf genau dieselbe Weise ausgeführt werden. Dies kann von Vorteil sein, wenn es wichtig ist, neue Fehler zu finden, aber auch ein Nachteil, wenn es wichtiger ist, bestimmte Details der früheren Tests zu wiederholen. Dies kann mit spezifischen Techniken (z. B. die Aufzeichnung der Tests) durch Vorbereitung automatisierter Tests gesteuert werden.

Untersuchungen

[Bearbeiten | Quelltext bearbeiten]

Replizierte Experimente haben gezeigt, dass geskriptete und explorative Tests zu einer ähnlichen Effektivität der Fehlererkennung führen (die Gesamtzahl der gefundenen Fehler). Explorative Ergebnisse führen zu einer höheren Effizienz (Anzahl der Fehler pro Zeitspanne), da kein Aufwand für die Vorplanung der Testfälle aufgewendet wird.[8]

Beobachtungen an explorative Testern haben ergeben, dass die Verwendung von Wissen über die Domäne, das zu testende System und Kunden, ein wichtiger Faktor für die Effektivität von explorativen Tests ist.[9]

Eine Fallstudie bei drei Unternehmen ergab, dass die Fähigkeit, schnelles Feedback zu geben, als Vorteil von explorativem Test angesehen wird, während das Management der Testabdeckung als Mangel eingestuft wurde.[10]

Eine Umfrage ergab, dass explorative Tests auch in kritischen Bereichen eingesetzt werden und dass explorative Tests hohe Anforderungen an die Person stellen, die die Tests durchführt.[11]

Verwendung

[Bearbeiten | Quelltext bearbeiten]

Exploratives Testen ist besonders geeignet, wenn Anforderungen und Spezifikationen unvollständig sind oder wenn für das Testen die Zeit fehlt.[12] Der Ansatz kann auch verwendet werden, um zu überprüfen, ob frühere Tests die wichtigsten Fehler erkannt haben.

[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. ↑ Cem Kaner: A Tutorial in Exploratory Testing. (PDF) April 2008, S. 2, abgerufen am 5. September 2022 (englisch).
  2. ↑ Cem Kaner: A Tutorial in Exploratory Testing. (PDF) April 2008, S. 36, archiviert vom Original (nicht mehr online verfügbar) am 12. Juni 2013; abgerufen am 1. März 2020 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.kaner.com
  3. ↑ Cem Kaner: A Tutorial in Exploratory Testing. (PDF) April 2008, S. 37–39, archiviert vom Original (nicht mehr online verfügbar) am 12. Juni 2013; abgerufen am 1. März 2020 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.kaner.com
  4. ↑ Cem Kaner: Testing Computer Software. 2. Auflage. John Wiley & Sons, 1999, ISBN 0-471-35846-0, S. 6, 7–11 (englisch, 496 S.).
  5. ↑ Cem Kaner, James Bach, Bret Pettichord: Lessons Learned in Software Testing. A Context-Driven Approach. 1. Auflage. John Wiley & Sons, 2004, ISBN 0-471-08112-4 (englisch, 320 S.).
  6. ↑ Cem Kaner, James Bach, Exploratory & Risk Based Testing, www.testingeducation.org (Memento des Originals vom 11. Mai 2008 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.testingeducation.org, 2004, p. 10
  7. ↑ Hendrickson, Elisabeth.: Explore It! : Wie Softwareentwickler und Tester mit explorativem Testen Risiken reduzieren und Fehler aufdecken. 1. Auflage. Dpunkt-Verl, Heidelberg 2014, ISBN 978-3-86490-093-8, 13.2 Forschen in Paaren: „Eine Möglichkeit, um alle Teammitglieder in das Forschen mit einzubeziehen, ist, Paare zum Forschen zu bilden. Besonders Paare aus einem professionellen Tester und jemand anderem sind sehr effektiv. Wenn ein Tester und ein Business-Analyst im Paar arbeiten, wird der Tester wahrscheinlich mehr vom Geschäft und den Erwartungen an die Software lernen... Wenn ein Tester und ein Programmierer sich zum Forschen als Paar zusammentun, gewinnt der Programmierer voraussichtlich Einsichten über Risiken, während der Tester einen Einblick in die Architektur erhält.“
  8. ↑ Juha Itkonen, Mika Mäntylä: Are test cases needed? Replicated comparison between exploratory and test-case-based software testing. In: Empirical Software Engineering. Band 19, Nr. 2, 11. Juli 2013, ISSN 1382-3256, S. 303–342, doi:10.1007/s10664-013-9266-8 (englisch).
  9. ↑ Juha Itkonen, Mika Mäntylä, C. Lassenius: The Role of the Tester's Knowledge in Exploratory Software Testing. In: IEEE (Hrsg.): IEEE Transactions on Software Engineering. Band 39, Nr. 5, 11. September 2012, ISSN 0098-5589, S. 707–724, doi:10.1109/TSE.2012.55 (englisch, ieee.org [abgerufen am 1. März 2020]).
  10. ↑ Juha Itkonen, K. Rautiainen: Exploratory testing: a multiple case study. In: 2005 International Symposium on Empirical Software Engineering. 2005, ISBN 0-7803-9507-7, S. 84–93, doi:10.1109/ISESE.2005.1541817 (englisch, researchgate.net [PDF; abgerufen am 1. März 2020]).
  11. ↑ Dietmar Pfahl, Huishi Yin, Mika V. Mäntylä, Jürgen Münch: How is Exploratory Testing Used? A State-of-the-practice Survey. In: ACM (Hrsg.): Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement. ESEM '14. New York, NY, USA 2014, ISBN 978-1-4503-2774-9, S. 5:1–5:10, doi:10.1145/2652524.2652531 (englisch, researchgate.net [PDF; abgerufen am 1. März 2020]).
  12. ↑ Cem Kaner: A Tutorial in Exploratory Testing. (PDF) April 2008, S. 37,118, archiviert vom Original (nicht mehr online verfügbar) am 12. Juni 2013; abgerufen am 1. März 2020 (englisch).  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.kaner.com