It’s the fourth month since I started working here in BoostSolutions. During last month, I was introduced to a new testing method called Scenario Testing, and I think it is very great especially when it’s used in developing our Workflow Boost product. And I wanna now write down my understanding of it with my real experience of using it.
Simply speaking, a scenario is a story that describes a hypothetical situation. In testing, you check how the program copes with this hypothetical situation. The ideal scenario test is credible, motivating, easy to evaluate, and complex. Scenarios specify actors, roles, business processes, the goal of the actors, and events that can occur in the course of attempting to achieve the goals. A scenario is an instantiation of a use case. A simple scenario traces through a single use case, specifying the data values and thus the path taken through the case. A more complex use case involves concatenation of several use cases to track through a given task, end to end.
In our product, there are many activities including Send Email, Condition, Query Data, Approval, etc. We can create some scenarios to use these activities as much as possible. Let’s assume a company managing the process of taking leave: employee submits the leave requirement to his manager (using Approval activity or Send Email activity). Then the manager approves the requirement (using Create Item activity or Update Item activity), fills in the time sheet accordingly (using Query Data activity), and calculates his wage (using Condition activity). This is a normal scenario, and we can also extend it: think of how to calculate the wage if staff has annual leave and sick leave; who has the permission to approve if the staff asks for leave for a too long period of time; how to proceed if the approver is absent or does not receive the requirement; etc… To sum up, try to imagine as many different scenarios as possible and apply different solutions according to the various scenarios.
However they are derived, good scenario tests have high power the first time they’re run. Groups vary in how often they run a given scenario test. Some groups create a pool of scenario tests as regression tests. Others (like me) run a scenario once or a small number of times and then design another scenario rather than sticking with the ones they’ve used before. Testers often develop scenarios to acquire insight into the product. This is especially true early in testing and again late in testing (when the product has been stabilized and the tester is trying to understand advanced features of the product).