by Bill Rinko-Gay
There are two components of quality software: building the right thing and building the thing right. One of the most difficult things to get right is knowing what the right thing is. In non-Agile methods this puts the focus on defining complete and detailed requirements. Experience shows that it is very difficult, if not impossible, to specify exactly what you want when you haven’t seen or worked with it yet.
In the absence of complete and detailed requirements we have to build software with a knowledge of what that software must do to satisfy the user. This knowledge has to be shared by the entire Agile team. We start to share this knowledge with a user story, but that only gives part of the picture. The rest of the picture is given in implementation and test plans.
When we share our plans for testing with the user and with the developer we share a statement of what the right thing is. This statement, developed correctly, becomes an excellent tool to understand what we have to build. Having this plan before development begins is an important part of assuring we build the right thing.
We start by writing the test story. In traditional testing language this would be called a test scenario. It’s a statement of the contents of the test without being hampered by the execution details. Written properly it allows the user to say, “Yes, if it passes these tests, it will be what I want.”
Each user story should have a test story. The test story should be written as soon as it can be after the user story has been accepted. The QA analyst needs to be involved in the user story development so he can have the knowledge to develop the test story. When written, the test story should contain the following elements:
- A specific validation of each acceptance criterion in the user story
- A statement of each behavior being demonstrated
- For each behavior:
- A brief description of how it will be verified
- Any special data setup that will be required
- Any specific system setup that will be required
- Success criteria
Once the user has verified the test story matches the expected use of the system, the developer has a target. The developer can be sure if he hits the target, he has built the right thing.
In the next blog I will talk about the process of refining this test story to the appropriate level for the Agile team and planning out its execution.