User stories should be testable

The *T* in the the ‘Invest’ acronym (a way to remember and assess what makes a good User Story) stands for Testable.

The most common forms of User Story that are not testable are big User Stories, known as Epics, or non-functional User Stories…

An Epic can be a User Story that really comprises multiple User Stories. Or perhaps an Epic can also be a User Story that is very complex.

An example from my previous job might be something like: “As a user, I want to calculate the cost of repairing a crashed car”. This is really an Epic and is not really Testable.

Non-functional stories are things like “As a user, I want the system to be fast”, “As a user, I want the system to be secure”, “As a user, I want the system to be easy to use”. None of these things are well written from a Test perspective. Perhaps they could be re-phrased to make more Testable? For instance, “web pages should generally load within 2 or 3 seconds”, “the system should comply with OWASP security standards”…

Let’s take my recent Example of a User Story to see if it’s Testable?

First of all, it’s small and fairly independent, which makes it inherently more testable to start with. This is a simple example so it should be easy to test. The scenarios are: Successful login, Failed login (user id), Failed login (password), Failed login (expired account), Failed login (authentication system unavailable), Remember me (if successful and ticked).

Importantly, identify the tests up-front, before the User Story is implemented. If developers know how the User Story will be tested, maybe they will write it to pass? 🙂