Browse the Knowledge Hub32 resources
Template
A test case template that another engineer can execute without asking you a question
Twelve fields covering identification, traceability, execution and automation status, with worked examples from a real authentication feature rather than placeholder rows. Download as CSV for Excel or Google Sheets, or copy it into your test management tool.
The test case template, with worked examples
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
5 worked examples
Log in successfully with valid credentials
ModuleAuthenticationTypeFunctionalPriorityHighRequirement IDUS-104Automation statusAutomated- Preconditions
- A registered, active account exists with a verified email and no MFA enrolled
- Steps
- 1. Open the login page. 2. Enter the registered email. 3. Enter the correct password. 4. Select Sign in.
- Test data
- [email protected] / Str0ng!Pass2026
- Expected result
- User is authenticated and redirected to the dashboard within 3 seconds. The header shows the account name. A session cookie is set with HttpOnly and Secure flags.
- Postconditions
- Active session exists. Sign out to reset state.
Reject login with an incorrect password
ModuleAuthenticationTypeNegativePriorityHighRequirement IDUS-104Automation statusAutomated- Preconditions
- A registered, active account exists
- Steps
- 1. Open the login page. 2. Enter the registered email. 3. Enter an incorrect password. 4. Select Sign in.
- Test data
- [email protected] / WrongPass123
- Expected result
- Login is refused. A generic message "Email or password is incorrect" is shown, identical to the message for an unknown email so the response does not reveal whether the account exists. No session is created.
- Postconditions
- No session. Failed attempt counter incremented by one.
Lock the account after five consecutive failed attempts
ModuleAuthenticationTypeSecurityPriorityHighRequirement IDUS-104, SEC-11Automation statusAutomated- Preconditions
- A registered account with the failed attempt counter reset to zero
- Steps
- 1. Submit an incorrect password five times in succession. 2. On the sixth attempt, submit the correct password.
- Test data
- [email protected] / five incorrect values, then the valid password
- Expected result
- The sixth attempt is refused even though the password is correct. A lockout message states the account is temporarily locked and when it can be retried. An account lockout event is written to the audit log.
- Postconditions
- Account locked. Reset via admin unlock or wait for the lockout window.
Enforce the password minimum length boundary
ModuleAuthenticationTypeBoundaryPriorityMediumRequirement IDUS-106Automation statusCandidate- Preconditions
- Password policy set to a minimum of 8 characters
- Steps
- 1. Open the password change form. 2. Enter a 7-character password and submit. 3. Repeat with 8 characters. 4. Repeat with 9 characters.
- Test data
- 7 chars: Ab1!xyz | 8 chars: Ab1!xyzz | 9 chars: Ab1!xyzzz
- Expected result
- 7 characters is rejected with a message naming the minimum length. 8 and 9 characters are both accepted. The rejection happens before submission where client validation exists, and is also enforced server-side.
- Postconditions
- Password changed to the last accepted value.
Operate the login form using the keyboard only
ModuleAuthenticationTypeAccessibilityPriorityMediumRequirement IDA11Y-03Automation statusManual only- Preconditions
- Login page loaded, no pointing device used for the duration of the test
- Steps
- 1. Tab through every control on the page. 2. Enter credentials using the keyboard. 3. Submit with Enter. 4. Trigger a validation error and observe announcement.
- Test data
- Valid credentials, then a blank password to force an error
- Expected result
- Focus order follows visual order with a visible focus indicator on every control. All controls are reachable and operable. The form submits with Enter. Validation errors are associated with their field and announced by a screen reader (WCAG 2.1.1, 2.4.7, 3.3.1).
- Postconditions
- None
What goes in each field
Test case ID
RequiredA stable unique identifier. Prefix by module so an ID tells you where it belongs, for example AUTH-012. Never renumber existing cases, because defect reports and traceability references point at these.
Title
RequiredOne line stating exactly what is verified, written so it is readable in a list without opening the case. Start with a verb and name the condition, for example "Reject login with an expired password".
Module
The feature area, used for filtering and for measuring defect density by module. Keep the vocabulary consistent across the suite rather than inventing new names per case.
Type
Functional, negative, boundary, security, accessibility, performance, usability or compatibility. Classification is what lets you check coverage spread rather than discovering you wrote forty happy-path cases.
Priority
RequiredRisk-based, not effort-based: High for revenue, data integrity and security paths, Medium for common flows, Low for cosmetic or rare paths. This is the field that decides what still gets run when time is short.
Requirement ID
The user story, acceptance criterion or specification this verifies. Populating it turns the suite into a traceability matrix for free and exposes requirements with no coverage.
Preconditions
RequiredThe state that must already be true before step one: account state, data present, permissions, feature flags. Anything a tester would otherwise have to guess or discover by failing.
Steps
RequiredNumbered, one action per step, unambiguous enough that another engineer runs it without asking you a question. Avoid embedding expected results here; they belong in their own column.
Test data
The specific values used, including the invalid and boundary ones. "Valid credentials" is not test data; an actual username and the class of password it represents is.
Expected result
RequiredThe precise observable outcome that decides pass or fail, including the message text or state change where that matters. If it cannot be observed, it cannot be tested.
Postconditions
The state left behind, and any cleanup needed. Important for suites that run repeatedly or in parallel, where leftover state is a common cause of false failures.
Automation status
Not automated, candidate, automated, or manual only. Keeps the manual and automated suites from drifting into duplicate coverage nobody notices.
Adapt it rather than adopting it wholesale
A template that fits every team fits none of them well. These four decisions are the ones worth making deliberately.
Cut fields you will not maintain
An empty column is worse than a missing one, because it signals the process is theatre. If nobody will fill Postconditions, delete it.
Keep IDs stable forever
Defect reports, traceability and automation all reference these. Renumbering a suite breaks every link pointing into it.
One assertion per case
If a case checks three things, a failure does not tell you which one broke. Split it, even though the row count goes up.
Write the expected result first
Deciding what correct looks like before writing steps stops you documenting current behaviour and calling it a test.
The three fields most teams skip, and regret
Requirement ID is the first casualty when a team is busy, and its absence is felt later: without it you cannot answer whether every acceptance criterion has coverage, and you cannot do impact analysis when a requirement changes. Populated consistently, this single column turns the suite into a traceability matrix at no extra cost.
Test data gets written as "valid input" far too often. The specific values matter because they encode the thinking: which boundary, which invalid class, which unicode case. A case that says "enter a valid email" has not documented anything a tester could not have guessed.
Automation status stops the manual and automated suites drifting into silent duplication, where the same flow is verified twice and a third one is covered nowhere. It also gives you a defensible list of automation candidates rather than a vague intention to automate more.
The fields we deliberately left out are Actual Result and Status, because those belong to a test run rather than a test case. Keeping execution results inside the case definition is why so many spreadsheets become unusable after two releases.
Suggest an improvementWant the cases written for you?
QAble writes and maintains test suites for client products, including converting undocumented features into a traceable case library.
Manual testing servicesMore templates and checklists
View allTest plan template
Template10 sections with per-section guidance and filled examples from a real release, trimmed from IEEE 829 to the parts that change a decision.Bug report template
TemplateA defect format that shortens developer triage, with worked examples and the fields that stop a report bouncing back.QA release checklist
ChecklistPre-release gates across functional, regression, performance, security, accessibility and rollback readiness.API testing checklist
ChecklistEndpoint coverage from status codes and schema through auth, security and performance, with the reason each item earns its place.Mobile app testing checklist
ChecklistDevice, network, permission, lifecycle and store-readiness checks for iOS and Android releases.Regression testing checklist
ChecklistHow to scope a regression pass by impact instead of running everything, with the areas teams most often miss.Sources
- ISTQB Glossary standard definitions for the testing terms used here.
Need a test suite built, not just a template?
QAble designs and executes test suites with ISTQB-certified engineers. Start with a free QA audit of your product.