Agile Testing with no Acceptance Criteria or Documentation to refer to

Question

I have been asked to test a new software application. The project is run Agile. In some cases I have no Acceptance Criteria and no documentation to refer to and I am being asked to write test cases for a User Story. Is this even possible? Has someone had to do this before and do you have any advice? Thanks!!

Answer 1

This is sadly not uncommon especially with newer Agile teams. I would take the proactive approach and write the Acceptance Criteria and then have it reviewed with the Product Owner (or whoever wrote the User Story) and Devs. I recommend writing it in the Gherkin Given-When-Then format. The example given in the agile alliance website is like this:

Given my bank account is in credit, and I made no withdrawals recently,

When I attempt to withdraw an amount less than my card's limit,

Then the withdrawal should complete without errors or warnings

You can have multiple ACs for a User Story. And these ACs can easily be used as test cases.

At the very least, you should raise this issue in Sprint Retrospective - the team needs to come to agreement on what is an acceptable User Story, be it more description and/or acceptance criteria. And at the next Backlog Grooming and Sprint Planning meetings, be sure to call out any user story that is not ready.

Answer 2

User Stories provide good insight into how a product should behave. While they seldom contain explicit testing criteria, there is often much implied that can be extracted from a user story which the test can develop into more formalized testing.

I like to break each user story down in three different passes:

1. First pass, identify functionality and features

2. Second pass, identify any limits imposed by a given environment, operating conditions, etc. This can be things like performance/throughput, duration, security.

3. Third pass, identify:

   • Interfaces (other software, files, databases, peripherals, etc.)
   • Inputs and outputs (records, messages, files, reports, objects, etc.)
   • Configurations (System level, application level, hardware, network, etc.)
   • Usage scenarios (normal "happy path", error handling/recovery, backup, installation,etc.)

This may not be the perfect approach for every person or every project, but it is one approach that helps in developing a somewhat nebulous concept into a more concrete form.

Answer 3

Talk to the developers, product owners and stakeholders. Figure out what was build and what needs testing.

If you are being assigned to a new product I would try some of the Tour heuristics:

• Feature tour: Move through the application and get familiar with all the controls and features you come across.
• Complexity tour: Find the five most complex things about the application.
• Claims tour: Find all the information in the product that tells you what the product does. Verify every claim
• Configuration tour: Attempt to find all the ways you can change settings in the product in a way that the application retains those settings.
• Persona tour: Imagine five users for the product and the information they would want from the product or the major features they would be interested in.

Research Exploratory testing and figure out ways to come up with new test ideas.