How should agile stories be written to make QA testing easy?

Question

I often see agile stories that don't clearly describe what is being developed. Often, nothing is mentioned about how the story must be tested at a high level. I generally don't see this issue in UI stories because its obvious to see the changes from the screenshots.

So, it becomes hard or impossible for a QA to develop test cases for such stories right away. They have to chat with other people who are often busy and not available easily. Everyone wastes time in finding out information that should have already been in the ticket for the story.

How can one solve this problem ?

PS - I understand that some communication is required for daily work, but if people can start including basic information in stories, then work becomes easy & smooth.

Answer 1

Consider adjusting your development workflow to include and promote some of the following practices:

• QA can tag a ticket for a developer to talk to qa before they start writing code
• QA reviews tickets for what sort of testing should be used (unit, integrated, performance, etc.)
• QA writes high level tests that are initially failing as the code is yet to be written
• QA participates in sprint review and gives input on story pointing and testing
• Sprint review includes input from multiple viewpoints to ensure tickets are well understood
• Use a high level language such as Cucumber to describe the high level process
• Include QA work in the definition of done and avoid practices that assume it
• A clear description in the ticket of what business purpose the ticket serves

Answer 2

Introduce high-level testing methods may help, such as behavior-driven development (BDD)

Direct quote from Wikipedia:

• BDD is largely facilitated through the use of a simple domain-specific language (DSL) using natural language constructs (e.g., English-like sentences) that can express the behavior and the expected outcomes.

It may require some additional training for business analysts and test analysts so that they can be on the same page in terms of how to communicate in BDD.

One example is shown below:

Story: Authenticate a web page login

• As a commercial user
• In order to log into my online account
• I want to make sure when my user name and password are correct, I can log in.

Scenario 1: User name and password are both correct

• Given that a commercial user enters correct a user name

• And then enters correct password associated with this given user name

• When this user clicks log in button

• Then this user is logged in.

Scenario 2: User name and/or password is wrong

• Given that a commercial user enters correct a user name

• And then enters incorrect password associated with this given user name

• When this user clicks log in button

• Then this user is not logged in and a message pops up saying: You have entered a wrong username and/or password.