User Story Testing is all about knowing what your users are experiencing in the real world. All you have to do is ask the crowd. Present your User Stories to testers and they will report on whether or not they can register, checkout, login, etc… in the form of an up or down answer.
Exploratory testers are already planning on trying every part of your product. As they roam now they can also let you know what they could do right alongside the bug reports you get when they couldn’t.
Usually, exploratory testing
only yields bugs, but when testing efforts only seek defects you can miss half the quality picture. Now you can get positive validations and bolster your confidence in your software’s release readiness without having to constantly rewrite test cases.
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. Products are ready when those requirements have been fully satisfied. Take for example the Checkout / Cart feature on an eCommerce website, this would be the ability to put products into the cart, change the amount of products, remove a product, select the payment and more.
Each feature has conversion relevant or crucial steps for success and those can be captured as User Stories.
User Story examples:
A user can add a product to the cart
A user can delete a product placed in the cart
A user can change the quantity of an item after it is added to the cart
Of course, the format and style of User Stories differ from team to team. However, User Stories should always be easy to understand, so most use natural language and are written as if they would be used to explain functionality to an actual user or customer.
Adding User Stories to your Exploratory tests is simply a matter of updating the Features you’ve already put into the test IO platform. Since Features are used to group
core functionalities of a website, it’s natural for user stories to fall under
those same buckets. Then run a crowd test like usual, but this time in addition
to the bug report, you’ll get results like this:
Crowdtesting is an effective way for you to expand test coverage and ensure release quality by finding bugs before they can reach potential users. These findings come in the form of bug reports that include details such as the steps to reproduce a bug, the URL of where the bug was found, the expected versus actual result, and a screencast of the interaction. While our bug reports are comprehensive and full of beneficial information, our customers still ask:
How do I know that the testers tested every part of my website, app, etc...?
How do I know what parts of my ____ did work?
These concerns are valid. Bug reports contain information that allows you to identify exactly where and when a bug occurs, that’s it. So what if there are no bugs reported with a feature? Ideally, this means that the feature is flawless, but it could also mean that testers missed a section. With just a bug report the only way you’d know is to check yourself but that would bring you back to square one, so do you trust that testers did check it? With the addition of User Story testing to the test IO platform, there is no need to trust. Now you can verify.