5

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.

  • Can you give a concrete example? – FDM Jul 24 '17 at 19:22
3

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
5

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.