|Industrial XP Storytesting|
StorytestingCapture a story with acceptance criteria that validates its implementation
Storytesting is the process of providing the input data, initiating a process that corresponds to a story being tested and comparing the actual output with the expected output at the end of the process.
After developers implement a story, they run storytests to
verify that their implementation does what the customers expect.
Only after storytests pass will customers mark a story as complete.
All of the storytests for a system represent a contract,
Storytests are most useful when automated, as this empowers customers and developers to launch them at the press of a button and discover the system's state. Coming up with the input data and expected output data for automatable storytests typically involves domain knowledge. Finding the right combination of tests is also important, and the contribution of professional testers can be substantial in this regard.Storytesters are usually:
The best time for writing storytests is usually after Iteration Planning, when the stories to be worked on are identified. The storytests should cover the scope of the stories being implemented in that iteration. They may be written initially on a whiteboard while the test is being researched.
Thereafter, they are captured in electronic form, and checked into version control. At this point, the storytests should be accessible to the entire project community in an executable form, so as to provide Executable Documentation of the system.
Don't Dial Every Number
To test if a mobile phone works correctly, you don't need to dial every number in the telephone book. Dialing a couple is sufficient to test that the phone works correctly for good numbers. Add a few wrong numbers into the mix to verify that you hear an error message and you have covered two major boundaries of the system. There are other boundaries which will merit individual tests, such as emergency numbers (like 911).
Storytesting involves identifying the minimal tests that will cover all boundary conditions by exercising all logic pathways.
e.g. The table below describes the monthly access plan of a mobile phone provider.
To test a system that accurately implements this plan, we'd need storytests to compute the bill amount for a customer who has used up:
Eight tests could sufficiently prove that the system computes the bill accurately. More tests could further strengthen the customer's confidence, but they should be recognized as redundant. Redundant tests can slow the team down as they can cause the tests to take longer to run. In addition, they can reduce the effectiveness of storytests as Executable Documentation by obscuring the sytem's logic.
If you must have redundant tests, consider moving them to your regression test suite. Regression tests will test your system exhaustively. They take longer to run, and hence are not run as often as unit, smoke or storytests.