I’ve presented a lecture on Scenario Testing that leverages material from http://www.testingeducation.org/BBST/ScenarioTesting.html and other places. In my most recent presentation Greg Veith reminded me to include (in the future) the concept of personas as stand ins for users.
From one tester comes an e-mail:
Thank you for presenting this, it was very useful information and I want to bring some of the ideas to my team.
I’ve got a couple questions
- how do you store the specifications (outlines) for your testing scenarios – are they Word docs? Have you considered using VSTS? I’m looking for something that will enable us to
- create a testing scenario catalog that would provide more detail than a directory listing of Word files
- assign owners, priorities, complete
The Indigo team used a Test Case Manager (TCM) called MadDog [internal to MS]. You can describe your test cases (scenarios) and implement them later. MadDog has the owners, priorities, completeness, etc. as tracking fields
could you send me some links to
- Indigo Scenario Template – I looked , but couldn’t find scenarios.
- exemplary test scenarios (TDS?) we could use as a reference
I’ve copied it to end of this post.This version of the concept was created by David Pallman. An alternative “template” was once stipulated in the Windows Standard Quality (Test) Criteria and I’ve posted an edited version at Windows E2E Scenario template.
The full blown scenario template as envisioned by Dave Pallman never really took off.
One of the purposes was to get testers to think about what information they needed from PM in specifications.
|Reviewer||scenario team fills out|
|Status||scenario team fills out|
|Categories||scenario team fills out|
Describe the essence of the scenario in one paragraph.
2. Conditions & Requirements
All scenarios can be expressed in terms of conditions and requirements.
Conditions are the constraints of the situation. Requirements are what needs to be accomplished.
3. Detailed Scenario
Include as much detail as the required to fully describe the scenario. Diagrams may be helpful for complex scenarios.
4. Actors and Sequence of Events
If applicable, describe the actors and sequence of tasks/events involved in this scenario, or attach a sequence diagram. An actor can be a user, an org, a department, a system, or a software component.
|Actor||Task or Event|
5. Feature Set
Summarize the features relevant to the scenario. Use standardized terms for features where possible.
Describe any variations of the main scenario that should be considered.
7. Open Issues
List any questions or open issues relating to the scenario.