Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Experimenting in Context for Exploratory Testing Maaret Pyhäjärvi Email: <maaret@iki.fi> | Twitter: maaretp
Replacing a test- case-driven style with a learning- tester-driven style in two organizations
What Testing Gives Us UnitTesting ExploratoryTesting SPEC FEEDBACK REGRESSION GRANULARITY GUIDANCE UNDERSTANDING MODELS SE...
Givens. Some things you can’t change (yet)
Experiments. Try changing something!
Finding the appropriate stretch Case 1.
Data-intensive application
Givens. Things I could not change. • Waterfall process. • Contractual distance between acceptance testers and subcontracto...
Experiments. Things I changed. • Acceptance tester degree of freedom. • Test cases from step-by-step scripts to test data ...
Finding the appropriate stretch Case II.
Function-intensive application
Givens. Things I could not change. • Roadmapping creating disconnect to current priorities. • Tendency for remote work. • ...
Experiments. Things I changed. • No test cases or wasteful documentation. • Tester with developer tools. • Removing “accep...
Framework of Management ”A day’s work” Vision (“Sandbox”) Current Charter Other Charters Details Bug Reports Perception of...
Thank you. @maaretp (please connect with me through Twitter or LinkedIn)
Upcoming SlideShare
Loading in …5
×

AgileTD: Experimenting in Context for Exploratory Testing

665 views

Published on

When there’s no best practices and you’re looking for the right way to test, what do you do? You come up with ideas of what you could try and experiment with them. This talk sums up my experience of replacing a test-case-driven style with a learning-tester-driven style in two organizations. To improve, we take what we’re given and can’t change, and make choices that that help us get the best out of what we have. Finding the appropriate stretch for the context at hand taught me that there’s no better way of keeping the team awake than changing the way we test on a regular basis with continuous experiments. Join me in learning what my teams experimented with and what worked for us, to get ideas of what you could try in your organization to enhance your practice of testing appropriately in your context.

Published in: Software
no profile picture user

  • Be the first to comment

AgileTD: Experimenting in Context for Exploratory Testing

  1. 1. Experimenting in Context for Exploratory Testing Maaret Pyhäjärvi Email: <maaret@iki.fi> | Twitter: maaretp
  2. 2. Replacing a test- case-driven style with a learning- tester-driven style in two organizations
  3. 3. What Testing Gives Us UnitTesting ExploratoryTesting SPEC FEEDBACK REGRESSION GRANULARITY GUIDANCE UNDERSTANDING MODELS SERENDIPITY Testing as artifact creation Testing as performanc e
  4. 4. Givens. Some things you can’t change (yet)
  5. 5. Experiments. Try changing something!
  6. 6. Finding the appropriate stretch Case 1.
  7. 7. Data-intensive application
  8. 8. Givens. Things I could not change. • Waterfall process. • Contractual distance between acceptance testers and subcontractor. • Test-case metric based reporting. • I manage, I don’t test. • Business end users as testers.
  9. 9. Experiments. Things I changed. • Acceptance tester degree of freedom. • Test cases from step-by-step scripts to test data with process outline for notes. • Making “change requests” acceptable. • Reporting ~20% of testing to 3rd party. • Inofficial tips sharing sessions with the subcontractor.
  10. 10. Finding the appropriate stretch Case II.
  11. 11. Function-intensive application
  12. 12. Givens. Things I could not change. • Roadmapping creating disconnect to current priorities. • Tendency for remote work. • Developers doing majority of testing. • Requirements / Specifications format as UI spec
  13. 13. Experiments. Things I changed. • No test cases or wasteful documentation. • Tester with developer tools. • Removing “acceptance testing” by moving testing to the team. • Continuous delivery (without test automation). • Holding space for testing to happen. • True teamwork with mob programming.
  14. 14. Framework of Management ”A day’s work” Vision (“Sandbox”) Current Charter Other Charters Details Bug Reports Perception of quality and coverage Quality ReportDebriefing Tester Test Manager Past Results Obstacles Outlook Feelings ? # xCharter backlog of the future testing Out of budget Next in importance!#, ?, x, +20:20:60 Session sheets of the past testing Idea of exploratio n Metrics summar y Coachin g Playbooks
  15. 15. Thank you. @maaretp (please connect with me through Twitter or LinkedIn)

×