Quality Assurance

User Story

A description of a feature from the perspective of a user, written in common and understandable language.

User Story format

As a [role], I can [capability], so that [receive benefit]. Created by the XP team at Connextra in 2001 and often credited to Rachel Davies.

User Story example

As a Facebook user, I can reset my password, so that I can access my account.

Acceptance Criteria (AC)

The agreed upon standards and instructions for how a feature will function, set by team representatives and stakeholders.

What Acceptance Criteria do

Outline how a feature will complete the User Story, give a clear understanding of how it works and what it includes, are not left to interpretation, and may define what happens when a task ends in an error.

How to write good Acceptance Criteria

Be specific, and describe the context, action, and expected result.

When Acceptance Criteria are completed

During the Plan phase of the SDLC.

G.W.T. technique

Given, When, Then. A common way of writing Acceptance Criteria.

Scenario (in G.W.T.)

Optional. A name for the one specific case you are describing.

Given (in G.W.T.)

The condition and starting state.

When (in G.W.T.)

An action to perform.

Then (in G.W.T.)

The expected result.

Definition of Done (DoD)

Defines when work is complete on a feature or phase.

Common items in a DoD

All AC met and approved by team leaders and stakeholders, approval from all parties documented, manual and automated tests in the Test Plan run and passed, all issues addressed, and documentation completed for the feature.

Multiple DoDs

A DoD can be created for each user story, each feature, the project as a whole, and future releases of the feature or product.

DoD vs Acceptance Criteria

They are not the same thing. AC describe how a feature works, while the DoD defines when the work is complete.

Happy Path

The intended use case for a feature. It accounts for how most users use the software.

Happy Path examples

Entering a valid username and password, entering no special characters, entering a valid email in a contact form, adding only text to a textarea, dragging and dropping an attachment to the correct upload area.

Sad Path

When a user uses the feature in the way we intended, but their actions prevent them from moving forward and completing the User Story. These are the mistakes we anticipate users making, or the path users take when what they want isn't available.

Sad Path examples

Entering an invalid username or password, entering expired credit card info at checkout, an item in a cart becoming sold out, a flight search with the same origin and destination.

Edge Cases

The extremes, like the longest input, the empty input, the oldest browser, and the slowest connection. They sit at the boundary of what you planned for, so they often lead to bugs.

Why plan and test for Edge Cases

They can show vulnerabilities and make a feature behave strangely, so testing them means fewer bugs reach your users.

Edge Case examples

A user with a first name, no middle name, and a very long last name with hyphens and an apostrophe. A 3000 character message with HTML in a small textarea.

Unexpected Use examples

A user starts step three of a three step form first. A user drops a file attachment outside of the drag and drop upload area.

Manual Tests

Tests that check both functionality and usability. A tester completes them by using the UI of the feature, following the steps a user of a new feature would take.

What Manual Tests cover

The Happy Path, Sad Path, and Edge Cases a user may encounter.

Manual Tests and the SDLC

Built during the Plan, Design, and Build phases and completed in the Test phase.

Manual Tests setup and cost

Data and setup instructions are passed to the tester along with the test cases. They are very time and resource intensive.

Automated UI Tests

Tests that check the functionality of an application. Writing them often surfaces usability issues, but testing usability itself needs a person watching a real user.

How Automated UI Tests work

Scripts run through software that performs UI tasks across many platforms and mimics mouse events, touch events, and more. A test may pass if it ends at a desired URL or a correct value appears in an input.

Popular Automated UI Test tools

Playwright, Cypress, and Selenium.

Automated Tests and the SDLC

Built and completed in the Build phase and Test phase. They are somewhat time and resource intensive.

Unit Tests

Tests that check functionality by programmatically testing a code block (or group of code blocks) against an expected result.

When Unit Tests run

Manually or automatically when a developer commits a new block of code. If one fails, automation can alert the team and developer and prevent it from entering the codebase.

Unit Test strengths and limits

They run quickly and exist in many coding languages. They are robust but not foolproof, since a group of units configured or called incorrectly can still give unexpected results.

Regression Tests

Tests run on older features of an application to reduce the risk of unforeseen errors when merging a new feature into Production. They aim to find bugs created by new features that show up in older features.

Regression Tests and Test Cases

They often consist of previously run Test Cases. A new feature's Test Plan may include all previous Test Cases or a subset of them.

Test Cases after deployment

Once a feature is deployed, the Test Cases in its Test Plan may become Regression Tests.