SlideShare ist ein Scribd-Unternehmen logo
1 von 14
Downloaden Sie, um offline zu lesen
Exploratives Testen –
ein Überblick und Praxisbeispiele
> Me e tup Software Te sting Karlsruhe , 19. Oktobe r 2021
Sven Schirmer
Gilda Karimzadeh
> A G E N D A
Unser Topics für euch
1. Wer sind wir?
2. Was verstehen wir unter explorativem Testen?
3. Testchartas, Doku und Transparenz
4. Projekt Beispiel: Session Based Testing
5. Boost your Testautomation
6. Projekt Beispiel : Exploratives Testing
7. Fragen und Diskussion
> W e r s i n d w i r ?
Zwei aus einem Team
von 679 Menschen
Unsere IT-Lösungen bringen Menschen
und Organisationen stärker voran.
Sven Schirmer
Head of QA,
Quality Enthusiast
Gilda Karimzadeh
Test Engineer
Der Mensch steht im Vordergrund
Im Projekt und als Anwendende,
als Gestaltende und als Betroffene.
Spezialisten Teams
Wir kombinieren Software-Engineering-Spezialisten
unterschiedlicher Disziplinen zu passgenauen Teams.
Zielgerichtet
Wir setzen Methoden und Technologien
zielgerichtet und wohldosiert ein.
Weiterbildung
Wir investieren in F&E. Und in Lernen.
So bleiben wir vorne dabei.
Partnerschaft
Wir kennen unsere Grenzen und kooperieren
mit exzellenten Partnern.
W a s v e r s t e h e n w i r u n t e r e x p l o r a t i v e m T e s t e n ?
Ein leichtgewichtiger Ansatz für die Erforschung des SUT
explorativ Formal
Geht nicht nach
vorgegebenen Schritten vor
Wird nicht verwendet, um
spezifische Fakten zu prüfen
Geht in exakt vorgegebenen
Schritten vor, inkl. erwartetem
Ergebnis
Wird verwendet, um
spezifische Fakten zu prüfen,
die z.B. in Anforderungen und
Userstories aufgeschrieben
sind
herumspielen Testchartas
Manuelle
Testfälle
Automatisierung
Ein Pathway, um exploratives Testing tiefer zu verstehen:
http://thatsthebuffettable.blogspot.com/2017/07/pathway-exploratory-testing.html
> T e s t c h a r t e r s
In Testcharters werden der
Inhalt und die Ergebnisse der
Sessions dokumentiert
Wir nutzen dafür Templates in Confluence oder
Testcases (für Tracability) in Jira Xray
› Charter Name der Charter
› Areas Betroffene Areas aus dem Low-Tech-Testing-Dashboard
› Startzeit Session
› Name der Tester
› Länge der Session
› Time Breakdown (in %) Aufbau und Vorbereitung, Testdesign- und
Ausführung, Fehleruntersuchung und Reporting
› Charter vs. Opportunity (in %) Wieviel testest du anhand der Charter
und wieviel frei
› Verwendete Testdaten
› Testdokumentation Text, Screen-Shots, evtl. mit Screen-Recording
› Bugs auch Links zu Jira-Tickets
› Auffälligkeiten die im Debriefing besprochen werden sollten
> S t r u k t u r u n d T r a n s p a r e n z
Mit Session Based Testing
strukturieren wir den explorativen
Ansatz
Wir strukturieren in verschiedene Sessions:
› Vorbereitung z.B. Testumgebungen, Zugänge, Testdaten oder
Räumlichkeiten
› Test-Sessions Abtauchen in ein Thema, Dokumentation in
Testcharters
› Debriefing Auftauchen und Austauschen (z.B. mit der PROOF
Methode - http://testingchef.blogspot.de/2012/05/debriefing-
proof.html)
Die Übersicht über den Testfortschritt behalten wir
mit dem Low-Tech-Testing Dashboard, ohne das
wir konkrete Testfälle haben:
› Area Welchen Bereich des SUT betrachten wir
› Effort wie steht es um den Aufwand für die Tests
› Coverage wie intensiv ist eine Area getestet worden
› Quality Bilder sagen mehr als Worte   
› Comments z.B. aus dem Debriefing
Cheat Sheet Low
Tech Testing
Dashboard
Effort
None Kein Testing, auch keins geplant
Start Testing hat noch nicht begonnen
Low
Nur punktuell oder Regressionstests,
Abdeckung beibehalten
High
Fokussierte Tests,
Abdeckung erhöhen
Blocked
Kann im Moment nicht getestet
werden, es gibt blockierende
Probleme
Paused
Testing unterbrochen und kann
jederzeit wieder aufgenommen
werden
Ship Letzte Tests, kann Live gehen
Coverage
0 Wir wissen noch nichts über die Area
1
Hauptfunktionen und Standarddaten
wurden getestet (Sanity Check)
2
Mehr als ein Sanity Check,
viele Funktionen nicht getestet
3
Alle Funktionen berührt, wichtige und
kritische Tests ausgeführt
4
Ungewöhnliche Testdaten, seltsame
Systemzustände, häufige Fehlerfälle
5
Neben- und Missbrauchsszenarien,
seltene Fehlerzustände, Stresstests
Quality Assessment
 Wir wissen von keinen Problemen, die einen Live-Gang oder weitere Tests
verhindern. Wir sind uns sicher genug, dass keine mehr gefunden werden.
 Wir wissen von Problemen, die zu Showstoppern werden können oder wir glauben
es kann hier Probleme geben, die wir nur noch nicht entdeckt haben.
 Es gibt Probleme, die einen Live-Gang oder weitere Tests verhindern.
> S e s s i o n b a s e d t e s t i n g
Wir haben durch
explorative Testsessions
den End-Benutzer näher an
das Feature Team gebracht
Projektsetting bei einem großen
Medienunternehmen in München, Umfang mit
3 Feature-Teams zur Implementierung des
neuen Content-Katalogs, der für mehr als 20
TV-Sender eingesetzt wird
› Test Session (2 Stunden) jede Woche
› Gleicher funktionaler Scope für die gesamte Test-Session
› Teilnahme des Fachbereiches freiwillig
› Pairing zwischen von einer Person aus dem Fachbereich
und einem Mitglied des Feature Teams
› Wichtig:
 Dokumentation der Ergebnisse (auch für das
Management)
 Debriefing in der kompletten Gruppe Dokumentation der Testergebnisse in
Session Sheets
Ein How-To von Florian Pilz :
https://www.maibornwolff.de/blog/session-sheets-jira-verwenden
> B o o s t y o u r T e s t a u t o m a t i o n
Wir nutzen Explorative Tests um
besser zu verstehen, wie unser
Produkt genutzt wird
Sechs Schritte für die Verbesserung
› In Devops ist das Logging und Monitoring des Systems –
auch in Produktion – ein wichtiger Bestandteil
› Wir nutzen diese Logs auch um fachliche User Journeys aus
der zu bekommen
› Die so gewonnen User Journeys verwenden wir auch um
explorative Testsessions vorzubereiten
› Diese Sessions führen dann mit so vielen Mitgliedern des
Feature Teams wie möglich aus, um zu verstehen wie in
Produktion das System genutzt wird
› Wenn wir wissen wie das System genutzt wird überprüfen
wird, ob die automatisierten Regressionstests diese
Szenarien abdecken
› Mit diesem Wissen verbessern wir unsere
Testautomatisierung fortlaufend, um so nah
der realen Nutzung des Systems zu sein.
> E x p l o r a t i v e s T e s t i n g
Exploratives Testen im
Projekt - Setting
Den Kunden früh in die neuesten Entwicklungen
involvieren.
• Zwei Feature Teams, die eine Plattform im
Bereich des Gesundheitswesens entwickeln.
• Plattform bietet verschiedene Dienste für
Krankenhausangestellte an.
• Zusätzlich zu automatisierten UI-& E2E-Tests,
manuellen & automatisierten Regressiontests
werden explorative Tests durchgeführt.
• Durchführung von explorativen Tests mit dem
Kunden und dem Feature-Team.
• Test-Sessions finden alle 2-3 Wochen statt.
• Ca. 3-6 Teilnehmer pro Session.
> E x p l o r a t i v e s T e s t i n g
Exploratives Testing im Projekt –
Durchführung
• Mit allen Beteiligten User Journeys erfassen.
• Zeitrahmen, Dokumentation der Ergebnisse und Teilnehmer
festlegen.
Vorbereitung
• Explorative Tests innerhalb der vorgegebenen Zeit durchführen.
• Alle relevanten Ergebnisse dokumentieren.
• Nachbesprechung mit allen Beteiligten durchführen.
• Feedback über die Durchführung der explorativen Tests einholen.
Umsetzung
• Fehler und Verbesserungsvorschläge erfassen.
• Explorative Tests auf Basis des Feedbacks modifizieren.
• Falls erforderlich neue Regressionstests erstellen.
Auswertung
Wir testen ohne Testplan –
aber wir haben einen Plan
> E x p l o r a t i v e s T e s t i n g
Vorteile des
explorativen Testings
im Projekt
Funktionen aus
verschiedenen
Perspektiven entdecken.
Verbesserung der
Kundenbeziehung.
Geringer Zeitaufwand.
Exploratives Testing
als zusätzliche Methode
für eine
vollständige Testabdeckung.
12
DANKE
für eure Aufmerksamkeit
und jetzt: Austausch und Diskussion
Materialsammlung
Session-Template • http://www.satisfice.com/sbtm/sample_session.htm
Debriefing
• PROOF: http://testingchef.blogspot.de/2012/05/debriefing-proof.html
• Checkliste: http://www.satisfice.com/sbtm/debrief_checklist.htm
Mindmaps
• Ministry of Testing: https://www.ministryoftesting.com/tag/mindmap/
• Test Insane: http://apps.testinsane.com/mindmaps
Heuristiken
• Buch: Explore IT von Elisabeth Hendrickson
• Cheat Sheet: http://testobsessed.com/wp-
content/uploads/2011/04/testheuristicscheatsheetv1.pdf
Touring
• Exploratory Software Testing von James Whittaker
• https://msdn.microsoft.com/de-de/library/jj620911(v=vs.120).aspx
Mnemonics
• SFDEPO: http://www.satisfice.com/articles/sfdpo.shtml
• FEW HICCUPS: http://www.developsense.com/blog/2012/07/few-
hiccupps/
Dokumentation
• HISToW: http://www.cassandrahl.com/blog/introducing-histow/
• PQIP: https://dojo.ministryoftesting.com/lessons/three-digestible-
diagrams-to-describe-exploratory-testing
Huh? And?
Really? So?
• http://www.developsense.com/presentations/2012-11-EuroSTAR-
CriticalThinkingForTesters.pdf
Inspirationshilfe
• Szenariokarten von MaibornWolff
https://github.com/MaibornWolff/scenario-cards
• Testsphere-Karten von Ministry of Testing
https://www.ministryoftesting.com/testsphere
Selbstlernkurs
• Exploratory Testing Pathway:
http://thatsthebuffettable.blogspot.co.uk/2017/07/pathway-
exploratory-testing.html

Weitere ähnliche Inhalte

Ähnlich wie Exploratives Testen – ein Überblick und Praxisbeispiele

SAP Solman und Testing 2019
SAP Solman und Testing 2019SAP Solman und Testing 2019
SAP Solman und Testing 2019Allgeier ES
 
Usability intern oder extern testen (WUD 2010)
Usability intern oder extern testen (WUD 2010)Usability intern oder extern testen (WUD 2010)
Usability intern oder extern testen (WUD 2010)Sandra Griffel
 
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...QAware GmbH
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernSascha Böhr
 
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0Michael Fischlein
 
Agiles Testen
Agiles TestenAgiles Testen
Agiles Testenoose
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererTobias Schlüter
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?René Spengler
 
WUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick WinsWUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick Winsguest60c1a2
 
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)eparo GmbH
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenGjero Krsteski
 
USECON MuC 2018: User Integration im agilen Umfeld
USECON MuC 2018: User Integration im agilen UmfeldUSECON MuC 2018: User Integration im agilen Umfeld
USECON MuC 2018: User Integration im agilen UmfeldUSECON
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshopmrdoubleb
 
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der PraxisResponsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der PraxisRoberto Rizzi
 
Lean development 04
Lean development 04Lean development 04
Lean development 04SuperB2
 
eparo – Usability 2.0 (Vortrag OMF Hamburg – Rolf Schulte Strathaus)
eparo – Usability 2.0 (Vortrag OMF Hamburg – Rolf Schulte Strathaus)eparo – Usability 2.0 (Vortrag OMF Hamburg – Rolf Schulte Strathaus)
eparo – Usability 2.0 (Vortrag OMF Hamburg – Rolf Schulte Strathaus)eparo GmbH
 
Das funktionierte doch schon einmal! - JUnit Testing in XPages
Das funktionierte doch schon einmal! - JUnit Testing in XPagesDas funktionierte doch schon einmal! - JUnit Testing in XPages
Das funktionierte doch schon einmal! - JUnit Testing in XPagesChristian Güdemann
 

Ähnlich wie Exploratives Testen – ein Überblick und Praxisbeispiele (20)

SAP Solman und Testing 2019
SAP Solman und Testing 2019SAP Solman und Testing 2019
SAP Solman und Testing 2019
 
Usability intern oder extern testen (WUD 2010)
Usability intern oder extern testen (WUD 2010)Usability intern oder extern testen (WUD 2010)
Usability intern oder extern testen (WUD 2010)
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
Bewertung von Qualitätsschulden mit dynamischen Daten aus Test und Betrieb - ...
 
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördernAgile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
Agile Teamarbeit - wie Startups Projekte managen und die Zusammenarbeit fördern
 
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
 
Agiles Testen
Agiles TestenAgiles Testen
Agiles Testen
 
Scrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für ProgrammiererScrum als agiles Vorgehensmodell für Programmierer
Scrum als agiles Vorgehensmodell für Programmierer
 
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
ASQF Dresden: Benötigen wir mit SCRUM noch einen Testmanager?
 
Agilität mit Scrum - Überblick
Agilität mit Scrum - ÜberblickAgilität mit Scrum - Überblick
Agilität mit Scrum - Überblick
 
WUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick WinsWUD 2009 Workshop: Quick Wins
WUD 2009 Workshop: Quick Wins
 
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
eparo – Quick Wins (Workshop WUD 2009 – Rolf Schulte Strathaus)
 
Software-Tests in PHP-Anwendungen
Software-Tests in PHP-AnwendungenSoftware-Tests in PHP-Anwendungen
Software-Tests in PHP-Anwendungen
 
USECON MuC 2018: User Integration im agilen Umfeld
USECON MuC 2018: User Integration im agilen UmfeldUSECON MuC 2018: User Integration im agilen Umfeld
USECON MuC 2018: User Integration im agilen Umfeld
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der PraxisResponsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
Responsive Multichannel-E-Commerce: Vorgehen und Learnings aus der Praxis
 
Agents of D.E.V.O.P.S
Agents of D.E.V.O.P.SAgents of D.E.V.O.P.S
Agents of D.E.V.O.P.S
 
Lean development 04
Lean development 04Lean development 04
Lean development 04
 
eparo – Usability 2.0 (Vortrag OMF Hamburg – Rolf Schulte Strathaus)
eparo – Usability 2.0 (Vortrag OMF Hamburg – Rolf Schulte Strathaus)eparo – Usability 2.0 (Vortrag OMF Hamburg – Rolf Schulte Strathaus)
eparo – Usability 2.0 (Vortrag OMF Hamburg – Rolf Schulte Strathaus)
 
Das funktionierte doch schon einmal! - JUnit Testing in XPages
Das funktionierte doch schon einmal! - JUnit Testing in XPagesDas funktionierte doch schon einmal! - JUnit Testing in XPages
Das funktionierte doch schon einmal! - JUnit Testing in XPages
 

Exploratives Testen – ein Überblick und Praxisbeispiele

  • 1. Exploratives Testen – ein Überblick und Praxisbeispiele > Me e tup Software Te sting Karlsruhe , 19. Oktobe r 2021 Sven Schirmer Gilda Karimzadeh
  • 2. > A G E N D A Unser Topics für euch 1. Wer sind wir? 2. Was verstehen wir unter explorativem Testen? 3. Testchartas, Doku und Transparenz 4. Projekt Beispiel: Session Based Testing 5. Boost your Testautomation 6. Projekt Beispiel : Exploratives Testing 7. Fragen und Diskussion
  • 3. > W e r s i n d w i r ? Zwei aus einem Team von 679 Menschen Unsere IT-Lösungen bringen Menschen und Organisationen stärker voran. Sven Schirmer Head of QA, Quality Enthusiast Gilda Karimzadeh Test Engineer Der Mensch steht im Vordergrund Im Projekt und als Anwendende, als Gestaltende und als Betroffene. Spezialisten Teams Wir kombinieren Software-Engineering-Spezialisten unterschiedlicher Disziplinen zu passgenauen Teams. Zielgerichtet Wir setzen Methoden und Technologien zielgerichtet und wohldosiert ein. Weiterbildung Wir investieren in F&E. Und in Lernen. So bleiben wir vorne dabei. Partnerschaft Wir kennen unsere Grenzen und kooperieren mit exzellenten Partnern.
  • 4. W a s v e r s t e h e n w i r u n t e r e x p l o r a t i v e m T e s t e n ? Ein leichtgewichtiger Ansatz für die Erforschung des SUT explorativ Formal Geht nicht nach vorgegebenen Schritten vor Wird nicht verwendet, um spezifische Fakten zu prüfen Geht in exakt vorgegebenen Schritten vor, inkl. erwartetem Ergebnis Wird verwendet, um spezifische Fakten zu prüfen, die z.B. in Anforderungen und Userstories aufgeschrieben sind herumspielen Testchartas Manuelle Testfälle Automatisierung Ein Pathway, um exploratives Testing tiefer zu verstehen: http://thatsthebuffettable.blogspot.com/2017/07/pathway-exploratory-testing.html
  • 5. > T e s t c h a r t e r s In Testcharters werden der Inhalt und die Ergebnisse der Sessions dokumentiert Wir nutzen dafür Templates in Confluence oder Testcases (für Tracability) in Jira Xray › Charter Name der Charter › Areas Betroffene Areas aus dem Low-Tech-Testing-Dashboard › Startzeit Session › Name der Tester › Länge der Session › Time Breakdown (in %) Aufbau und Vorbereitung, Testdesign- und Ausführung, Fehleruntersuchung und Reporting › Charter vs. Opportunity (in %) Wieviel testest du anhand der Charter und wieviel frei › Verwendete Testdaten › Testdokumentation Text, Screen-Shots, evtl. mit Screen-Recording › Bugs auch Links zu Jira-Tickets › Auffälligkeiten die im Debriefing besprochen werden sollten
  • 6. > S t r u k t u r u n d T r a n s p a r e n z Mit Session Based Testing strukturieren wir den explorativen Ansatz Wir strukturieren in verschiedene Sessions: › Vorbereitung z.B. Testumgebungen, Zugänge, Testdaten oder Räumlichkeiten › Test-Sessions Abtauchen in ein Thema, Dokumentation in Testcharters › Debriefing Auftauchen und Austauschen (z.B. mit der PROOF Methode - http://testingchef.blogspot.de/2012/05/debriefing- proof.html) Die Übersicht über den Testfortschritt behalten wir mit dem Low-Tech-Testing Dashboard, ohne das wir konkrete Testfälle haben: › Area Welchen Bereich des SUT betrachten wir › Effort wie steht es um den Aufwand für die Tests › Coverage wie intensiv ist eine Area getestet worden › Quality Bilder sagen mehr als Worte    › Comments z.B. aus dem Debriefing
  • 7. Cheat Sheet Low Tech Testing Dashboard Effort None Kein Testing, auch keins geplant Start Testing hat noch nicht begonnen Low Nur punktuell oder Regressionstests, Abdeckung beibehalten High Fokussierte Tests, Abdeckung erhöhen Blocked Kann im Moment nicht getestet werden, es gibt blockierende Probleme Paused Testing unterbrochen und kann jederzeit wieder aufgenommen werden Ship Letzte Tests, kann Live gehen Coverage 0 Wir wissen noch nichts über die Area 1 Hauptfunktionen und Standarddaten wurden getestet (Sanity Check) 2 Mehr als ein Sanity Check, viele Funktionen nicht getestet 3 Alle Funktionen berührt, wichtige und kritische Tests ausgeführt 4 Ungewöhnliche Testdaten, seltsame Systemzustände, häufige Fehlerfälle 5 Neben- und Missbrauchsszenarien, seltene Fehlerzustände, Stresstests Quality Assessment  Wir wissen von keinen Problemen, die einen Live-Gang oder weitere Tests verhindern. Wir sind uns sicher genug, dass keine mehr gefunden werden.  Wir wissen von Problemen, die zu Showstoppern werden können oder wir glauben es kann hier Probleme geben, die wir nur noch nicht entdeckt haben.  Es gibt Probleme, die einen Live-Gang oder weitere Tests verhindern.
  • 8. > S e s s i o n b a s e d t e s t i n g Wir haben durch explorative Testsessions den End-Benutzer näher an das Feature Team gebracht Projektsetting bei einem großen Medienunternehmen in München, Umfang mit 3 Feature-Teams zur Implementierung des neuen Content-Katalogs, der für mehr als 20 TV-Sender eingesetzt wird › Test Session (2 Stunden) jede Woche › Gleicher funktionaler Scope für die gesamte Test-Session › Teilnahme des Fachbereiches freiwillig › Pairing zwischen von einer Person aus dem Fachbereich und einem Mitglied des Feature Teams › Wichtig:  Dokumentation der Ergebnisse (auch für das Management)  Debriefing in der kompletten Gruppe Dokumentation der Testergebnisse in Session Sheets Ein How-To von Florian Pilz : https://www.maibornwolff.de/blog/session-sheets-jira-verwenden
  • 9. > B o o s t y o u r T e s t a u t o m a t i o n Wir nutzen Explorative Tests um besser zu verstehen, wie unser Produkt genutzt wird Sechs Schritte für die Verbesserung › In Devops ist das Logging und Monitoring des Systems – auch in Produktion – ein wichtiger Bestandteil › Wir nutzen diese Logs auch um fachliche User Journeys aus der zu bekommen › Die so gewonnen User Journeys verwenden wir auch um explorative Testsessions vorzubereiten › Diese Sessions führen dann mit so vielen Mitgliedern des Feature Teams wie möglich aus, um zu verstehen wie in Produktion das System genutzt wird › Wenn wir wissen wie das System genutzt wird überprüfen wird, ob die automatisierten Regressionstests diese Szenarien abdecken › Mit diesem Wissen verbessern wir unsere Testautomatisierung fortlaufend, um so nah der realen Nutzung des Systems zu sein.
  • 10. > E x p l o r a t i v e s T e s t i n g Exploratives Testen im Projekt - Setting Den Kunden früh in die neuesten Entwicklungen involvieren. • Zwei Feature Teams, die eine Plattform im Bereich des Gesundheitswesens entwickeln. • Plattform bietet verschiedene Dienste für Krankenhausangestellte an. • Zusätzlich zu automatisierten UI-& E2E-Tests, manuellen & automatisierten Regressiontests werden explorative Tests durchgeführt. • Durchführung von explorativen Tests mit dem Kunden und dem Feature-Team. • Test-Sessions finden alle 2-3 Wochen statt. • Ca. 3-6 Teilnehmer pro Session.
  • 11. > E x p l o r a t i v e s T e s t i n g Exploratives Testing im Projekt – Durchführung • Mit allen Beteiligten User Journeys erfassen. • Zeitrahmen, Dokumentation der Ergebnisse und Teilnehmer festlegen. Vorbereitung • Explorative Tests innerhalb der vorgegebenen Zeit durchführen. • Alle relevanten Ergebnisse dokumentieren. • Nachbesprechung mit allen Beteiligten durchführen. • Feedback über die Durchführung der explorativen Tests einholen. Umsetzung • Fehler und Verbesserungsvorschläge erfassen. • Explorative Tests auf Basis des Feedbacks modifizieren. • Falls erforderlich neue Regressionstests erstellen. Auswertung Wir testen ohne Testplan – aber wir haben einen Plan
  • 12. > E x p l o r a t i v e s T e s t i n g Vorteile des explorativen Testings im Projekt Funktionen aus verschiedenen Perspektiven entdecken. Verbesserung der Kundenbeziehung. Geringer Zeitaufwand. Exploratives Testing als zusätzliche Methode für eine vollständige Testabdeckung. 12
  • 13. DANKE für eure Aufmerksamkeit und jetzt: Austausch und Diskussion
  • 14. Materialsammlung Session-Template • http://www.satisfice.com/sbtm/sample_session.htm Debriefing • PROOF: http://testingchef.blogspot.de/2012/05/debriefing-proof.html • Checkliste: http://www.satisfice.com/sbtm/debrief_checklist.htm Mindmaps • Ministry of Testing: https://www.ministryoftesting.com/tag/mindmap/ • Test Insane: http://apps.testinsane.com/mindmaps Heuristiken • Buch: Explore IT von Elisabeth Hendrickson • Cheat Sheet: http://testobsessed.com/wp- content/uploads/2011/04/testheuristicscheatsheetv1.pdf Touring • Exploratory Software Testing von James Whittaker • https://msdn.microsoft.com/de-de/library/jj620911(v=vs.120).aspx Mnemonics • SFDEPO: http://www.satisfice.com/articles/sfdpo.shtml • FEW HICCUPS: http://www.developsense.com/blog/2012/07/few- hiccupps/ Dokumentation • HISToW: http://www.cassandrahl.com/blog/introducing-histow/ • PQIP: https://dojo.ministryoftesting.com/lessons/three-digestible- diagrams-to-describe-exploratory-testing Huh? And? Really? So? • http://www.developsense.com/presentations/2012-11-EuroSTAR- CriticalThinkingForTesters.pdf Inspirationshilfe • Szenariokarten von MaibornWolff https://github.com/MaibornWolff/scenario-cards • Testsphere-Karten von Ministry of Testing https://www.ministryoftesting.com/testsphere Selbstlernkurs • Exploratory Testing Pathway: http://thatsthebuffettable.blogspot.co.uk/2017/07/pathway- exploratory-testing.html

Hinweis der Redaktion

  1. DIES IST DIE TITELFOLIE