📝 Summary (TL;DR)

This guideline is used to determine whether a system or developed software meets customer expectations.

The basis are acceptance criteria, which are the link between requirements or user stories and test cases. Since many projects require a systematic method for deriving acceptance criteria, this page presents a procedure based on questioning keywords. The presented method consists of up to five steps.

1. Identify keywords

2. Insert keywords in question catalog

3. Find, check and discuss answers

4. Define acceptance criteria

5. Specify test cases*

_{*recommended for manual test cases}

👨‍🏫 Prolog: The benefit of acceptance criteria

Since requirements or user stories are often open to interpretation by different stakeholders (e.g. requirement owners, customers, developers and testers), a common understanding of the actual content must be achieved. In addition, the goals of the different stakeholders may be conflicting, so they need to be sharpened and agreed upon. For this reason, it is necessary to talk about it and establish a common understanding. Defining acceptance criteria in this conversation can be used to concretize the requirements. The defined criteria serve as proof that this communication has taken place and sharpen the mutual understanding.

🏗 The Fundament - Description

User stories typically follow this structure:

As a(n) <Type of user> I want to <Request/Function> to be able/so that <Reason>

⚙️ From user story to acceptance criteria and test case in five steps

Step 1: Identify keywords

One way to define acceptance criteria is to ask for keywords. These must first be identified in the user story (description). Keywords are verbs, adjectives and subjects that can be assigned to the category <request/function>.

User Story (example)

As a user I want to save my profile so that I do not have to enter my data again and again.

Step 2: Insert keywords in question catalog

Then it has to be checked if questions - based on the so-called W-questions (who, when, how often, etc.) - can be answered in a meaningful way (a catalog of questions is attached below). Questions that do not allow a meaningful answer in the given context will be ignored. Your question must lead to a meaningful answer and must complement or concretize a user story.

User Story (example)

V_1 - Who must <save>?

V_2 - When should <save> take place?

V_3 - When is <save> completed?

V_4 - How can <save> be performed exactly?

S_1 - Which contents are contained in <Profile>?

S_2 - Which optional / mandatory aspects apply to <Profile>?

S_3 - Which contents of <Profile> and according to which rules should be checked?

S_4 - What does the layout for <Profile> look like?

Step 3: Find, check and discuss answers

Step 3 is for communication between stakeholders to achieve a common understanding of the desired implementation. The answers to the questions allow the definition of concrete acceptance criteria, which must correspond to quality criteria.

Possible quality criteria

Clarity - Completeness - Consistency  - Comprehensibility - Traceability - Identifiability - Freedom from redundancy

Need - Correct level of abstraction  - Correctly derived - Feasibility - Atomicity

User story (example):

Example: Find, check and discuss answers (extract of possible answers)

V_1 - Only the user; there shall be no automatic caching

V_2 - Only if all mandatory fields have been filled in and the content has been checked by e-mail address

S_1 - Names, address and contact data should appear as content in the profile

S_2 - Optional should be the phone numbers and the artist name, all other fields are mandatory

Step 4: Define acceptance criteria

There does not have to be a 1:1 relationship between the stakeholder responses and the acceptance criteria, but several responses can be combined into one acceptance criterion, or one response can lead to several acceptance criteria.

User story (example):

AC_1 - The profile data must come from the fields (first name, last name, artist name, street name, house number, city, zip code, cell phone number, landline number and e-mail address).

AC_2 - The fields artist name, cell phone number, and landline number are optional.

AC_3 - The user can save his profile when all mandatory fields have been filled in and the e-mail field has been checked for the regular expression [a-zA-Z0-9_-.]+@[a-zA-Z0-9.]+a-zA-Z{2,4}.

AC_4 - If the "Save" function cannot be performed, the user must be given a corresponding reason.

Step 5: Specify test cases*

_{*recommended for manual test cases}

The last step is to create test cases that cover the proposed areas.

The following areas should be covered:

Precondition - Test steps to be performed  - expected result - Postcondition

User story (example):

Example: specified test cases(extract)

T_1 - Test invalid e-mail address

Precondition

• The user has registered, logged in and called up the input page for profile data

Test steps to be performed

1. Enter values in mandatory fields
2. Enter invalid value for e-mail address
3. Click save button

Expected result

• The save operation is not performed; the database is empty.
• an error message is displayed indicating an incorrectly entered e-mail address

📚 Catalog of possible questions