User story testing – automated. Perform hundreds of tests on every user story.
User story testing and refinement is the ultimate in shift left
Poor quality user stories will lead to rework and waste. So you should consider testing your user stories before the team invests time on trying to build the corresponding software. The testing can be done manually or with the help of tooling. ScopeMaster will test user stories rapidly and thoroughly.
User story testing may sound like a strange idea, but it’s not. In fact it’s one of the most productive things that you can do on a software project. It’s the epitome of extreme left testing. If you want to become a more successful product owner, start testing and refining those stories as early as possible. User stories are an expression of requirements on agile software endeavours. Like other software development deliverables, they too are also prone to errors. The particular challenges with user stories is that they can very easily be misinterpreted, which can lead to a lot of wasted work. In fact they are more likely to be misinterpreted than not.
125 Reasons To Test User Stories
The ratio of words in a user story to the number of coding tokens we typically is 1:125. A 12 word user story would probably end up becoming about 1500 coding tokens, approximately 300 lines of code. So, for every minute spent fixing an ambiguous word in a user story will probably save 125 minutes in coding. Now that’s time well spent!
If it can be misinterpreted, it will
If a user story can be interpreted differently by the key readers (author, user, tester, developer) then it is likely that one of them will be working to the wrong understanding, generating waste and rework. It is very important to nip these ambiguities in the bud.
How to test user stories
So how do we do it? Well becoming a software requirements expert overnight is not likely, but remember the following:
A real business requirement (or capability) is “what must be delivered to provide value to the business” (Robin Goldsmith). User stories are the discrete functional requirements that make up that capability.
Need for Discipline, to Reduce Ambiguity
When we write code, we follow disciplines to improve readability, reduce complexity, increase re-use and much more. (For more on this, read the excellent Code Complete, by Steve McConnell). Writing user stories also warrants such discipline, especially to minimise ambiguity, inconsistency and complexity. In fact a good user story can be rather boring as it is unambiguous. Be prepared to adjust how you write user stories, adopt consistency and discipline to drive out ambiguities. Fortunately ScopeMaster will help you learn as you go.
What if you don’t test your user stories?
Poor user stories (or poor requirements ) are the root cause of as many as 35% of production defects (Accenture 2021). A requirements problem that is not resolved until later phases of the development/deployment may cost 75-1000 times more to fix than if it was fixed before coding starts.
User story testing – automated
Testing user stories is rather dull. Thankfully when you use ScopeMaster to write and refine your user stories the heavy lifting testing is done for you. On average, ScopeMaster will perform 1000 tests on every user story in just a few seconds. Now that’s a level of scrutiny that most product owners and business analysts don’t normally assign to user story QA work.
Related tools
Jsonlint is an online tool for testing the syntax of a json file
HTML Validator is an online tool for testing HTML syntax.
SonarQube for testing code quality
