The purpose of this article is to document what needs to be in place in order to ensure that:

1. Testing effort can be included in estimates
2. Testing progress can be tracked during a sprint
3. Testers have an idea of the test cases they need to create
4. There is alignment in expectation between developers, testers and product owners

What do I do during planning?

The entire team, including the tester, should participate in this discussion and ensure they fully understand what is required as part of the story. (Hint: Ask Questions)

As a guideline, there should be at least one test task per acceptance criteria item, each test task may (and often will) translate into more than one test case. Test tasks are assigned to the tester, to be translated into test cases.

A story is not considered ready for development if the acceptance criteria or test tasks are not present, and it should not be included in the sprint. It is the responsibility of the team, enforced by the PM, to ensure that this is adhered to.

What do I do during my sprint?

1. The tester must create test cases as per test tasks. This can be done before development, during, or after development depending on what makes sense.
2. Test cases must cover every test task and ensure that the Acceptance Criteria is tested for and met.
3. When development is complete and the feature has been deployed to the Test environment, the developer changes the state of the story to Ready For Testing.
4. The tester is then responsible for running the test cases and reporting on progress.

Guidelines for writing test cases can be found here

What is Acceptance Criteria?

This is the set of conditions that must be met in order for the feature to be deemed complete/fulfilled as per requirements.

Whilst it may be time consuming, writing acceptance criteria has a huge pay off if done correctly. It can help ensure that the developed software meets actual business requirements and reduce rework.

How do I write Acceptance Criteria?

There are many formats you can use to write acceptance criteria. However, it depends entirely on what works best for the team and client/product owner.

Consider the following user story:

As an account holder, I want to search my transaction details, so that I can view all the transactions for a particular day.

1. Scenario based criteria

This uses scenarios to better help the team visualize requirements. The Given/When/Then/And format from BDD (Behaviour Driven Development) is used.

The acceptance criteria for the user story could look like this:

Scenario: Search - results

Given a transaction history search box,

When I select a date and click Search,

Then I should see a list of transaction details, with date, description, debit amount and credit amount, for the selected date.

Scenario: Search – results data format

Given a transaction history search box,

When I select a date and click Search,

Then the transaction details date should be in the format (YYYYMMDD)

And the debit amount and credit amount should have 2 decimal places.

Scenario: Search - performance

Given a transaction history search box,

When I select a date and click Search,

Then I should receive a list of transaction details within 15 seconds.

Scenario: Search – no results

Given a transaction history search box,

When I select a date and click Search,

And there are no results,

Then I should see a “No transactions available for date” message.

Scenario: Search – pagination

Given a returned list of transaction details,

When there are more than 20 transaction details,

Then I should see 20 transaction details on page 1

And I should be able to paginate through the result set by clicking Next or Prev or selecting a page number.

2. Rule based criteria

Requirements are written in a simple list format.

The acceptance criteria for the user story could look like this:

1. I am able to select a date for the search.
2. A list of transaction details are returned (Date, Description, Debit Amount, Credit Amount).
3. If a large set of results are returned, a paginated view is presented with page numbers and ‘Prev’, ‘Next’ links.
4. All amounts are accurate to two decimal places.
5. The search results are returned within 15 seconds.
6. If there are no search results, I see a “No transactions available for date” message.

Putting it all together

This is ideally what we want to achieve, well defined user stories, with dev tasks, test tasks and acceptance criteria.

Where can I find more examples?

https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important

https://www.altexsoft.com/blog/business/acceptance-criteria-purposes-formats-and-best-practices/