User Story Testability | Inflectra

User Story Testability

March 5th, 2015 by inflectra

The language used to define user stories in Agile projects tends to be less prescriptive than that in traditional projects. This means that many developers and testers assume that this means that they are often less testable, when in fact the reverse is true. This article explains why.

Requirements authors with a background in traditional ‘shall’ statement-style requirements are likely to be familiar with the need to write requirements that are testable. When requirements are not testable they usually get thrown back from test-engineers and sometimes even from software engineers who have a broad project view. Un-testable requirements often contain subjective measures or judgments, for example, “The emergency exit shall be easily recognizable.”

While the language used for User Stories is initially sometimes less precise than wording in ‘shall’ statements, it would be a mistake to think that the need for objectivity and lack of ambiguity never applies. Agile methods propose that effort is not expended until it is necessary to do so. Any effort expended to provide this precision before the user story is assigned to the iteration, would be wasteful.

Once a user story is selected for an iteration, it is the responsibility of the entire team – product owner, users, developers, testers, etc. – to ensure that it is clearly and unmistakably understood by all and, if necessary, modifying it in the process. This is one of the benefits of Agile processes: by involving all team members in the discussion of user stories, it is less likely that misunderstandings will occur. And by involving testers there is the opportunity to ensure the testability of whatever is agreed.

Another important aspect of Agile testing is automated regression testing. Unlike traditional, phased projects, Agile methods require that testing be done, like voting, early and often. The code is changing frequently, and it is important to maintain a baseline of ‘correctness’. Regression testing is essentially the same tests performed repeatedly, to ensure that changes have not broken anything; when performed manually, this becomes very expensive and may not even be possible given the short duration of iterations being employed. Automation is a financial as well as practical necessity.

Smaller, commercial, IT-type applications projects have been fastest to embrace Agile development, whereas mission critical, distributed or large systems developments have been more resistant. As a consequence, Agile methods are often used for applications that are graphical user interface (GUI) heavy, requiring automated regression testing of a variety of GUI technologies and GUI component recognition. This means that during development, GUI decisions that take into account GUI testing needs, particularly automated testing needs, will aid in regression testing and so benefit the project as a whole. That’s not to say that user stories need to accommodate technical GUI needs, but it is incumbent on test engineers to consider automated regression testing during initial user story exploration and elaboration.

You may also be interested in:
How to Choose a Test Management Tool
What is a Software Defect?
DevOps make way for TestOps…

agile testing user stories user interface gui