Acceptance Criteria? Or Test Cases?

6/6/2016

3 Comments

In one of our recent case studies, we applied our methodology for an online book store that was being developed using Agile methodology. Below is one of the user stories that was in the scope of the first sprint:

User Story:
As a customer, I want to add books to my shopping cart, so that I can build a list of books I want to buy

Acceptance Criteria:
a. I can add books to my cart from search results
b. I can edit the quantity of a specified book
c. I can remove a book from my shopping cart
d. I can proceed to check out from my shopping cart

Using Testing Algorithms' solutions, following test cases were created for add book, edit quantity and remove book functionalities.

Test Cases - Add Book:

Test Cases - Edit Quantity of Book:

Test Cases - Remove Book:

Now the question is, are the given-when-then statements (i.e., test cases) better 'definitions of done'? Should the original acceptance criteria be replaced by them?

There are various ambiguities in the traditional acceptance criteria that were identified while creating the model using Testing Algorithms' approach, as follows:

1. Can a negative quantity be selected while adding a book into shopping cart?
2. How many ways a customer can land on the Search Page?
3. Are cancel buttons present when a book is being added, edited or removed to shopping cart?

Clearly, the traditional acceptance criteria were incomplete. Also, as a matter of fact, creation of the test cases (i.e., Gherkin statements) didn't take any additional time to create. In the product backlog grooming session, before the sprint started, Testing Algorithms' solution was instantly used to create not only these test cases, but various other documents including use case diagrams, process flow diagrams and manual test cases with expected results.

Visit https://www.testingalgorithms.com/online-book-store-agile.html or contact support@testingalgorithms.com for additional details of Testing Algorithms' solution.

3 Comments

Craig Rawstron

7/12/2016 04:28:16 am

I am an Agile Coach with nearly 13 years experience.

I teach BDD and Specification by Example (SBE). The SBE workshops help representatives from the core Team areas (Business / QA / Coder) flesh out the Acceptance Tests and begin the process of writing the Gherkins tests.

There is nothing wrong with some being missing, they can be added later - but these workshops tend to capture just about everything and also put a stop to "Just In Case" code, where a coder might think something is a bright idea - and the rest of the Team may say it will never be needed.

When you use the terminology "Test Cases" that often leads people to believe you are going to write them down as old style Tests.

I never use that phrase any more, I say "Acceptance Tests" - then everyone knows it will result in Gherkin tests, with "Hook" code written by coders to link the Gerkhin test to the code when it is written / changed / ready to test etc.

I also refrain from saying "Developer" as I feel everyone on the Team is a developer of the product, with different areas of focus. Thus my use of QA and Coder. I also use BA and PO for business people.

Janet Gregory link

10/21/2016 08:18:13 am

Craig, I also use the term acceptance tests - especially for those high level examples that define the scope of the story. I tend to use words like variations when examining "all the rest" of the tests or examples that might come out during discussions.

The term "test case" doesn't enter my vocabulary anymore.

Abhimanyu Gupta

10/21/2016 09:40:53 am

Thanks Craig and Janet for your comments. I think it doesn't really matter what nomenclature we use. Instead, what matters is how we be more Agile by being innovative. I just wanted to share an idea here and am flexible about what we want to call it.

Agile has become like a religion where we focus more on the rituals instead of the philosophy behind it. Agile doesn't come with a roadmap or a manual or a curriculum. To me, it is more of improvisation than a process. And I wanted to share how I look at it and how I improvise. There is no one right answer and I don't expect everyone to agree with my approach.