Story Test Plan Template
Develop test automation as you go
As a quality engineer, developer, or team leader, what tools do you use during story refinement? One of them should be a story test plan template to help identify, organize, and clarify testing requirements.
Using a story test plan template in refinement can help you:
- Clarify acceptance criteria
- Make assumptions explicit
- Flesh out technical details
- Improve estimates of story size
- Avoid delays and rework in story implementation
- Identify challenges and gaps in test automation
- Build the right test automation incrementally
- Sustain high velocity creation of business value
- Maintain quality
A story test plan template specifies the types of tests your team will be using. The particulars of story test plan template will vary from team to team depending on architecture and business requirements.
Sample Application
To illustrate the use of a story test plan template I’ll use a sample application called ExerMart. This application will be a simple UI, microservice, and persistence layer. I’ll give just enough detail to illustrate the use of story test plan templates.
The ExerMart application allows users to:
- List equipment for sale
- Shop for equipment
- Compare prices across multiple marketplaces
The diagram below represents the architecture of the application. It shows elements owned by our team on the left in blue and external dependencies on the right in green.
- UI: the UI Front End which supports all user interactions. Could be built using Angular, React, or any other UI framework.
- API: the API Back End which supports the Front End and External Marketplaces, and which connects to the Database, External Marketplaces, and an external payment processor. In an actual application this would likely be broken down into several micro services. But for our purpose this level of detail is sufficient. It could be built using Java Spring Boot, DotNet, Node, or any other back-end framework.
- Database: the Database (DB) which stores equipment for sale, user data, shopping cart status, etc. Could be any relational or object DB.
- OATH: the OATH provider that supports authentication and authorization
- Payment: the external Payment processor
- Marketplaces: any number of External Marketplaces
The UI and the API are each in their own separate repositories and have their own Continuous Integration / Continuous Delivery and Deployment (CI/CD) pipelines. Because of their test automation, they can be worked on and released independently.
Sample Story Test Plan Template
This business and architecture context provides enough information to establish the outline of our story test plan template. Similarly, your context will determine what goes in yours. Below is our project’s test plan template from least to most granular:
- Unit: Verify a class, method, or component in isolation
- Integration: Verify running project in isolation, integrating all the units in that project together
- Journey: Verify a valid user scenario
- Manually test UI look and feel
There are many different terms used for these types of tests, and I’ve chosen these to be as intuitive as possible. For your team, it is important to choose a set of terms that you agree to use. Let’s look in more detail at each type of test and how it applies to our architecture.
Unit
- What to test: Units of code within the UI project and the API project.
- How: Isolate the units of code tested using test doubles as needed.
- Why: Catch issues at the lowest level of logic in your application using the fastest and most reliable tests
- When: Every time you push a code change to a repository, before the project is deployed
Integration
- What to test: The entire UI or API project in isolation
- How: Test the UI in isolation using mock API and OATH; test the API in isolation using mock OATH, Payments, and Marketplaces.
- Why: Catch issues at the level of each project using fast and reliable tests
- When: Every time you push a code change to a repository, before the project is deployed
Journey
- What to test: Verify a valid user scenario at the UI or API layer.
- How: Test against the deployed UI or API.
- Why: Catch issues that would block a user from completing an important task using slower and less reliable tests.
- When: After every deployment of the UI or API project.
Manually test UI look and feel
- What to test: UI look and feel
- How: Manually against the deployed UI
- Why: Because look and feel testing is difficult to automate and is impossible to automate completely
- When: As soon as possible before the application is released to production
Other types of testing
I considered the following common test types but left them out to focus on the main point. You might want to consider them for your team as well as any other qualities or types of testing that make business or technical sense for you.
- Contract
- Health check
- Performance
- Load
- Accessibility (508)
- Browser compatibility
Story Test Plan Template in Context
Having looked at the possible types of tests in a Story Test Plan Template, lets apply this template to a sample story in the ExerMart application, the “Compare Prices” story. This section shows the finished story, ready for development. I’ll show what the refinement progress might look like as the template is incorporated into the story in a subsequent blog post.
Compare Prices Story
As a shopper, I want to compare prices of an item in ExerMart with the prices of similar items in external marketplaces, so that I can make an informed decision about my purchase.
Acceptance Criteria
Given: That I have an item of exercise equipment in my cart
When: I click the Comparison Shop button
Then: A Comparison Table is displayed comparing my item with similar items from the ExerMart and external marketplaces
And: There is no maximum number of items to display
And: The following columns are displayed: Description, Thumbnail photo, Marketplace, Price
And: The styling should correspond to the linked user interface design (UX)
Assumptions
The following have already been developed prior to this story:
- Posting items for sale
- Shopping cart
- Comparables ranking method that takes an item and a possible list of comparable items and returns the comparables in ranked order of match to an item.
Technical Notes
- UI: Add comparison shop button and comparison table component
- API: Add new endpoint:
GET items/<item id>/comparables. This new endpoint takes an<item id>of an item and retrieves comparable items from ExerMart and external marketplaces.
// Sample API request / response:
// Item 27 is a recumbent bicycle in the ExerMart DB
GET items/27/comparables
http 200:
{[{“Id”: 1,
“Description”: “Recumbent bike mfr A”,
“Marketplace”: “ExerMart”,
“Price”: 125},
{“Id”: 7,
“Description”: “Recumbent bike mfr B”,
“Marketplace”: “External Marketplace 1”,
“Price”: 150} ]}Returns an empty list if no comparables are found for the item Also returns http 401 if a valid OAUTH token is not provided http 404 if the <item id> does not exist. Limited via OAUTH token to validated logged in users.
Test Plan
Unit:
- UI: Verify that the component renders with mock data including 0, 1, 2, 3 comparables. If there are no comparables include a message on the UI when the comparables table is displayed that no comparables could be found.
- API: Cover the method that combines data from different sources. It should verify that for 1 to many sources, each returning from 0 to many comparables, that the combined list is as expected.
Integration:
- UI: Using Cypress, verify in a browser that pressing the comparison shop button displays the comparables table or a “0 comparables” message. Do this with mock data for 0, 1, 2, and 10 comparables.
- API: One call to the API endpoint for each of 200 (success), and 404 (item id does not exist)
Journey test:
- UI: N/A for now. Later, add comparables to the existing “Shop for used exercise equipment” journey test. This will be done after the stubs for the queries to ExerMart and two external marketplaces are turned into real implementations.
- API: N/A. Since the shopping cart is stored on the UI only there is no shopping journey test at the API layer.
Manually test UI look and feel:
- UI: Check the look and feel of the comparables table with the expected data returned by the API stubs for comparables sources search.
- API: N/A
Conclusion
I’ve shown how your team can get the following immediate benefits from using a story test plan template in story refinement:
- Clarify acceptance criteria
- Make assumptions explicit
- Flesh out technical details
- Improve estimates of story size
These immediate benefits lead to the following additional benefits over time:
- Avoid delays and rework in story implementation
- Remove gaps in test automation which become tech debt
- Build the right test automation incrementally
- Sustain high velocity creation of business value
- Maintain quality
All these benefits can be achieved by your team with the cost of a little more discussion on each story. Talk with your team today about adding the test plan template outline to your stories and expanding it during refinement together.
Thanks
- Song Kim for comments on the first draft and for encouragement
- Blake Norrish, for in-depth comments on the second draft and for inspiration and practical suggestions for becoming a better writer
- Tom Taylor, for feedback on the final draft
- My clients, who give me the opportunity to help them and apply and grow my knowledge and experience
- My colleagues in Slalom Build Quality Engineering, who openly share their knowledge in a continuous stream
- My teammates, who worked with me to build many software projects
- My wife Jane
All opinions and errors are mine.
