process / Testing

Use Cases, Checklists and Automated Test Cases

Goal

Ensure all public functionality of the application is fully covered by Acceptance Tests, so we can confidently release to production based on test results alone.

When the tests pass, the application is ready for release.

Vocabulary

Application

Application is an independently deployable component (e.g. backend service, frontend web app, or mobile app). The key focus is on its deployment process.

Use Case

Use Case is an action or task that the system or the user performs from the customer's perspective.

For example: Create a contact (in an Contact Book)

Checklist

Checklist is a single-line definition used to verify variable behavior within a use case.

For example:

• Create a contact with only First Name and Phone Number
• Create a contact with Email and no Phone Number
• Create a contact with only First Name and Last Name
• etc

(highlighted text is a checklist item built on top of the use case Create a contact)

Test Case

Test Case is a thorough evaluation of a checklist item, accounting for specified variations, used as the basis for writing an automated test.

Let's write a test case for checklist item:

Test Case Example:

- Go to Contacts page
- Click Create
- Create contact with first name "Alex" and Phone Number "+1 555 22-33-444"

Simple map analogy

• Spain (country) is an application (zoom 100 km)

• Visit Madrid is a use case (zoom 10 km)

• Visit Barcelona is a use case (zoom 10 km)

• "When visiting Barcelona go to Camp Nou" is a checklist item (zoom 1 km)

• "When visiting Barcelona go to Museu Picasso and then to Sagrada Familia" is a checklist item (zoom 1 km)

• Test case for When visiting Barcelona go to Museu Picasso and then to Sagrada Familia (zoom 100m)

  • Go to ticket office
  • Buy a ticket
  • Go to entry
  • etc

Workflow

1. Discover the application and build knowledge about it
2. Define Use Case you want to cover with tests
3. Prioritize the Use Cases
4. Create Automated Test Cases for prioritized Use Cases
5. When single Use Case is covered with Test Cases, go back to step 2 and repeat the process

Adoption Approach

There are 2 approaches to adopt this practice:

1. Discover all Use Cases, and then for each Use Case define exhaustive Checklists and Test Cases. Going one by one. This way you will have some Use Cases fully covered with Test Cases, and some not covered at all.

(orange on the image)
- Write down a wide range of use cases
- For EACH use case develop a comprehensive checklist
- And subsequently for each checklist item write test case

2. Discover all Use Cases, and then for each Use Case create a handful of Test Cases, but covering some of the checklist variations. This way you will have most of the Use Cases covered with Test Cases, but some of them will lack comprehensive testing.

(blue on the image)
- Write down a wide range of use cases
- For ALL use cases develop a small number of checklist items
- Automate a handful of checklist items with Test Cases

Depending on the team's goal and context either approach can be a good fit.

We choose approach 1 when we need to automated acceptance testing of the application. That means we can exclude these use cases from manual testing sooner. Also when teams see the benefits of this approach and automated acceptance testing they go above and beyond to automate it sooner for other Use Cases.

FAQ

When to write use case?

• When there's empty list of use cases
• When there's a new feature in development
• When there's an unknown bug discovered

When to write checklists?

• After we define and prioritize use cases

When to write test case?

• We don't explicitly write test cases in advance in markdown (or anywhere else)
• Test case is iteratively developed when writing acceptance tests