Experiences with Semi-Scripted Exploratory Testing
•Télécharger en tant que PPT, PDF•
0 j'aime•829 vues
Presentation for talk at Agile Testing Days 2011, 15 November, Potsdam, Germany
![About ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
Similaire à Experiences with Semi-Scripted Exploratory Testing
Similaire à Experiences with Semi-Scripted Exploratory Testing (20)
Dernier
Dernier (20)
Experiences with Semi-Scripted Exploratory Testing
- 1. Experiences with Semi-scripted Exploratory Testing Simon Morley Agile Testing Days 2011 15 Nov 2011
- 7. Scripted Execution vs Scripted Testing?
- 13. Background
- 15. Environment Unchanged Changed NE NE (SUT) Sim NE NE NE NE Sim NE Sim NE Sim NE
- 16. Result?
- 21. Test Feasibility
- 22. Learning
- 24. Feature Walkthrough -> Brainstorming for risks
- 25. Brainstorming #1
- 26. Brainstorming #2
- 27. First real testing of the feature!
- 28. Test Ideas
- 29. Test Ideas -> Test Feasibility
- 30. Learnings Gather the right people to look at the problem. Allow time for reflection.
- 32. Test Execution
- 33. Semi-Scripted? Same input Same input Config Changes Provisioned Data Changes NE NE (SUT) Sim NE NE NE NE Sim NE Sim NE Sim NE
- 34. Test Execution
- 35. Test Execution
- 36. Test Execution
- 37. Test Execution
- 38. Test Execution
- 39. No “test idea constraints” linked with tester thinking & reflection from execution feeds back into better test ideas.
- 40. When you're not interested in numbers Then testers are no longer interested in talking about them!
- 44. “ Feature A tested, there are some interaction issues with feature B and, by implication, risks for features C and D. We have not explicitly tested feature C. Recommend some further investigation with feature A in combination with features B and C. As feature D is not to be used in trial a priority decision is needed on the inclusion of D into scope. If feature D is to be put into general usage then further test and investigation is recommended.”
- 45. Pilot activity spread to end-2-end teams with greater engagement and end-value appreciation. Issues in the product for end-user usage & interactions are found -> adding value to the product reporting
- 47. What's happening here? Testing has been framed as an investigative activity! Scripting is re-framed as a tool rather than a goal for testing!
- 49. Sometimes labels get in the way! Framing a choice differently -> transition!
- 55. Lessons
- 60. Questions?
- 61. Thank You! Blog: http://testers-headache.blogspot.com Twitter: @YorkyAbroad
Notes de l'éditeur
- These experiences are based on bullets 2&3, and through bullet 1 spreading the word to other teams.
- Marionette: Following instructions of the puppeteer But suppose there is some danger in front of him that the puppeteer doesn't see? He can decide to divert or modify his action, and even when to continue following directions. So, it's not blindly following instructions...
- Using some pre-defined set-up as an enabler to an exploratory session, i.e. there can be a certain amount of pre-meditated design and thought before you start exploring The pre-defined set-up and exploration should not exclude observation and feedback. Walking with someone else is valuable (just like testing with someone else adds a new/different dimension)
- Note, you need a way to determine if/when to carry on Script usage could also be called script-supported testing
- Large Organisation Some features are for trial purposes Many specifications & protocols Many features and interactions Perpetual question: “How much detail is enough?” Prototype in a conservative test team set-up But, the new thinking has followed into end-2- end team set-ups
- “ Erfinden sie ein problem” = “they invent a problem”
- Say which bits will be zoomed-in....
- Trial, demo & live? A trial might have different performance requirements to live usage. Other apsects not required might be expansion/scaleability needs or robustness and negative testing.
- This is a 'weeding-out' activity also. Input to 'silent evidence' here is: not possible due to tool or time restraints.
- Some traditional aspects kept Some new aspects/ideas introduced
- Note, you can't just make things ambiguous and then thinking and reflection happens. The thinking and questioning must be encouraged as a part of the activity. The ambiguity stops ideas getting 'boxed-in'.
- Don’t let test cases ”constrain” (box-in) ideas – create them with ”enough” ambiguity so that you’re not constrained, boxed-in, no restricted to a comfort zone and eventually ”thinking outside your comfort zone/box”
- Testing has been framed as an investigative activity Try this, what happens?, grey areas? Look closer Contrast with, “this is the spec -> test to that” Moves away from reliance on only confirmatory testing
- By changing the frames of reference the labelling of the activity was avoided. Sometimes labels get in the way. Framing a problem differently is much more subtle -> acceptable.
- I think of test cases as test idea constraints – because they tend to lock-in ideas about what a test case produces -> it takes on much more value than it should... Getting past test case counting Relating value in test ideas to end-user value Emphasized with PO/team involvement early Working with good test story telling is important Whole team involved in initial analysis Reduces handovers + creates a feeling of involvement Prototype early – good toolsmiths are important Fail fast – throw away ideas before they cost too much!
- The thinking and reflection about the test ideas, feeding back to improve them -> these are attributes of what I call good testing and attributes that align with many aspects of good agile testing. BIg challebge – abscence of team set-up, wow & processes----- (was also an aid to not have defined WoW & processes!) Reflect on semi-script & exploratory....
- Q&A session