How to get the most out of User Story Testing

As you know, test IO has added User Story Testing to the platform - and that the crowd can now give you positive confirmation feedback on your product’s functionality. Now the question is: how does it work - and when should you take advantage of it? Luckily, it’s as simple as adding a one-line description to your features under test and letting the crowd do the rest.

A User Story is a one to two line description of a requirement that a functionality or feature must have, written from the perspective of the end-user. Adding User Stories to your Exploratory Tests is simply a matter of updating the Features you’ve already put into the test IO platform. Features are used to group core functionalities of your software, so it’s natural for user stories to fall under those same buckets. However, not all User Stories are created equal. To make sure that you get the most out of testing them while maintaining the low maintenance of guided exploratory testing we’ve put together some tips on how to write your User Stories.

A User Story Should:

• Use Goal-oriented language, not step-oriented (it's not a test case)
• Be written from a user perspective (As a shopper...)
• Define one objective Pass/Fail criteria per User Story
• Be small enough in scope that it can be executed in a minute or two

It’s easy to extend any functional test, into a User Story Test. All you need to do is select the desired stories while adding Features during the test setup.

Depending on the package you have, you have access to some number of monthly user story executions (your CSM can get you this if you are unaware) - and not every one of your products’ features will need them. Take your Footer for example. You could use an execution to check whether or not a "user will be taken to the contact page when they click on the contact button” or you could run an exploratory test that checks for broken links throughout the entire footer. Both will give you the same information, but the non-core flow is more efficiently served with a pure exploratory test.

User Story Testing is best used when:

• UAT: testing new features to see if they pass
• You NEED positive confirmation for a critical flow/ core functionality
• Product flow is complex and has multiple required checkpoints

With good User Stories written and your test started you can sit back and let the testers handle the rest. When the standard exploratory results are in, you’ll get your User Stories and the positive (or negative) confirmation feedback alongside it. If you’d like to see it for yourself, please reach out to our team at [email protected] or click here.