We almost missed this week's session because it was too hard to have everyone available at the same time. But Yan insisted, she said:"once we let 1 session pass, there will be more sessions get away. After that, we might just never get this weekly activity on track." So thanks to her, our dojo continued. And this week, we learned scenario testing.
Scenario testing was my favourite. In my testing report, there was a section called user tory - an alias of scenario testing. There, I listed all stakeholders with their interests, and tried to figure out what they wanted to see and to do in the story.
In the past 2 years, this user story section helped me to find a lot of interesting bugs. For example: 2 years ago, I was testing a web application. Before I started, developers did a short demo on what to click, how to check logs and database records. I tested it for 2 weeks. Then one day I decided to write a user story like this:
I am 40 year-old manager, my daughter starts dating some wild kid, my wife just spent 1000 dollars on some stupid sallon VIP card.
Then I login the web app as him, I found a search field on the top of the main page. It was so weird that I never saw it before. Developers didn't mention it, and I was busy working on variables, boundries, domains. But now after I login as a manager with zero knowledge about the app, I noticed it. So I did what a new comer would do, I searched my name, then my department name. None of these search actually worked. Later I proved that only very few queries could work in this search field.
I reported this bug with the scenario and how it confused this poor manager. The bug then got a priority more than several functional issues, and got itself fixed a week later.
Just like my story, the lecture started with a live example. At the end of the example a bug finally got fixed because testers told the right story. Then lecture moved on to " what is ideal scenario testing" and "why we need scenario testing":
* ideal scenario testing
** based on a story, motivating, credible, complex use and complex environment, easy to evaluate results
* why scenario testing
** explore expert use, make a bug report more motivating
It took us 30 minutes to watch the first part of the lecture, and 10 minutes for discussion.
Jing: The story part took too long, even that I know scenario testing could be important, I still do not know how to apply it.
Other testers were all lost while following examples mentioned in the lecture, so we had to start over again, just so to have a better understanding.
I actually didn't like this. For most of the lectures, there would always be something that we didn't understand for the first time. But we didn't have to understand everything in the lecture to learn and apply it. All we needed was to catch what his point was, and how he was proving it.
Then we moved on applying it. This time our SUT was a code checking system. [Admin] defined [several] [rules] for the code, like no logging password in code, always add comments for class, etc. The system did the checking before [user] committed code. If the code was including some thing like "system.log $password", the system would warn user and stop commit.
Though we didn't get to the part on "16 ways to do scenario testing", I applied some of my user story tricks, and we made a sheet like this:
| stakeholders | interests | background knowledge | tasks | desire |
| admin | garantee good code | code structure, invalid code format | define rules | define 1 time, work forever |
| user | easy commit code | coding, commit tools | write good code, commit | pass commit check |
1 scenario we designed was that:
admin added 1 new rule, with interest - wanted this rule to prevent bad code from committing, but also with desire - wanted this rule work forever. So he/she must create some kind of way to verify the new rule. But the system currently did not provide such function. It was exactly one of the reasons why we need scenario testing - bring requirement related issues to the surface.
没有评论:
发表评论