Lately, in software development lifecycle, vastly formalized requirement documents are being replaced by more agile, so called “user stories” which are actually short software requirements formulated in users own words. User stories are created by the customer or it’s representative preferably in the meeting with developer. User stories should be short and have in focus only one aspect of the software which is to be designed. For example:
- “As a user I shall have a profile which I can edit.”
- “User profile is consistent of Name, Email, Location, Title, Homepage”
Easy and clean. Both developer and user can reformulate the user story until agreed. But, problem can occur with interpretation of the user story. Let say developer took the profile shall be editable in this way:
But customer had in mind something more traditional, with only one link to “edit my profile” which then look like this:
So, user was not satisfied with the implementation. Comic artist draw this to depict whereabouts of this process in funny way:
Who knows is it a accidentally or with purpose, but on comic above there are no software testers mentioned. And if quality assurance is taken seriously in product development, those are the guys which can help the product is building right.
Luckily enough for end users, there is a way out of the mess depicted in the comic. One way we already outlined at the start. Monolithic requirement specification documents we replaced by user stories which mean we will discover problems much earlier. However, process of developing software cannot live solely on user stories. Many of us read some book before watched the movie based on that book. From each reader perspective some movies got the book just right and some not. Why? How to escape that in our user stories case? Easily. Each user story has to have its Acceptance test. Acceptance tests are ideally written by the customers representative and software tester. Those tests are high level test which test completness of the user story.
Traditionally, acceptance tests are considered to be the final barrier of quality assurance before the product ship. However, in agile way of developing software, features are implemented rapidly so battle on this barrier is fought more intensive than in traditional software development models. This battle with defects, misinterpreted features, tight release schedule and big quality demands are fought every day by software testers.