Test Case Template with Examples: Login & Authentication Scenarios

What Is a Test Case?

A test case is a set of conditions and steps used to verify that a specific feature or function of a software application works correctly. Each test case defines what to test, how to test it, and what the expected result should be. Think of test cases as the building blocks of your QA process. Well-written test cases are repeatable, unambiguous, and cover both happy paths and edge cases — so any tester can pick them up and execute them consistently. This article provides a practical test case template, then walks through real-world examples based on the most common login and registration scenarios. These test cases cover happy paths and key edge cases — ready to copy into your test management tool.

Test Case Template

Below is a standard test case template you can copy into your test management tool, spreadsheet, or document.


Test Case ID:       TC-[Module]-[Number]
Module:             [e.g., Login, Registration]
Test Title:         [Short, descriptive name]
Priority:           [Critical / High / Medium / Low]
Preconditions:      [What must be true before testing]
Test Data:          [Specific data to use during testing]

Test Steps:
1. [Step 1]
2. [Step 2]
3. [Step 3]

Expected Result:
  [What should happen when steps are executed correctly]

Actual Result:
  [What actually happened — filled in during test execution]

Status:             [Pass / Fail / Blocked / Not Executed]
Bug Reference:      [BUG-XXX if applicable]
Tester:             [Name]
Test Date:          [YYYY-MM-DD]

Test Case Field Reference

Before writing test cases, understand what each field means:

Field	Description	Example
Test Case ID	Unique identifier: `TC-[Module]-[Number]`	TC-REG-001
Module	Which feature/module this belongs to	Registration, Login, Password Reset
Test Title	One-line description of the scenario	Successful registration with valid email and password
Priority	Importance: Critical > High > Medium > Low	Critical = core flow broken; High = major issue; Medium = edge case; Low = cosmetic
Preconditions	State that must be true before testing	User is on the registration page, email is not registered
Test Data	Specific values used during testing, exact strings	email = "<user@example.com>"
Test Steps	Numbered actions, one step per action	1. Navigate to URL; 2. Enter value; 3. Click button
Expected Result	What should happen when executed correctly	Account created, redirected to dashboard
Actual Result	What actually happened — filled in during execution	Same as expected / Error: "Email already exists"
Status	Pass / Fail / Blocked / Not Executed	Filled in during execution
Bug Reference	Related bug tracking ID (if applicable)	BUG-0042
Notes	Additional info: workaround, related tickets	Only reproducible in Firefox

Complete Example

Below is one complete test case showing how the template is filled in:


Test Case ID:       TC-REG-001
Module:             User Registration
Test Title:         Successful registration with valid email and password
Priority:           Critical
Preconditions:      User is on the registration page, no existing account with this email
Test Data:          email = "newuser@example.com", password = "SecurePass123!", name = "John Doe"

Test Steps:
1. Navigate to https://app.example.com/register
2. Enter "John Doe" in the Full Name field
3. Enter "newuser@example.com" in the Email field
4. Enter "SecurePass123!" in the Password field
5. Enter "SecurePass123!" in the Confirm Password field
6. Check the "I agree to Terms of Service" checkbox
7. Click the "Create Account" button

Expected Result:
  - Account is created successfully
  - User is redirected to a "verify your email" page
  - A confirmation email is sent to newuser@example.com within 30 seconds
  - User can log in with the registered credentials after email verification

Test Case Table (Copy-Paste Ready)

Copy this table directly into Excel / Google Sheets / TestRail. The first 5 columns are pre-filled with example data; the remaining columns are for you to fill in during test execution.

ID	Module	Test Title	Priority	Type	Preconditions	Test Steps	Test Data	Expected Result	Actual Result	Pass/Fail	Notes
TC-REG-001	Registration	Successful registration with valid email and password	Critical	Happy Path	User on registration page, email not registered	1. Go to /register 2. Enter name, email, password 3. Agree to terms 4. Click Create	email="<newuser@example.com>", password="SecurePass123!"	Account created, redirected to verify page, confirmation email sent within 30s
TC-LOGIN-001	Login	Successful login with correct email and password	Critical	Happy Path	Verified account <user@example.com> exists	1. Go to /login 2. Enter email 3. Enter password 4. Click Sign In	email="<user@example.com>", password="CorrectPass123!"	Authenticated, redirected to dashboard, session token set

Blank Template Table

Below is the blank table header. Copy it and add rows for your own test cases:

ID	Module	Test Title	Priority	Type	Preconditions	Test Steps	Test Data	Expected Result	Actual Result	Pass/Fail	Notes

How to Write Good Test Cases: Best Practices

1. Make each test case independent

A test case should verify one specific behavior. If it fails, you should know exactly what's broken. Don't combine multiple scenarios in one test case.

2. Be specific with test data

"Enter a valid email" is vague. "Enter <user@example.com>" is precise. Specific test data makes test cases reproducible.

3. Cover the happy path AND edge cases

The happy path (successful login with valid data) is important, but edge cases reveal real bugs:

Empty fields

Invalid formats

Boundary values

Expired tokens

Concurrent sessions

4. Write preconditions

Preconditions set up the test environment. Without them, the tester might start from the wrong state and get a false pass/fail.

5. Use clear, numbered steps

Each step should be a single action. "Fill in the form and submit" is too vague. Break it into individual field entries.

6. Include the expected result in detail

"Login succeeds" is not enough. Specify what the user sees, where they're redirected, what emails are sent, and what happens in the database.

How BugCapturer Helps with Test Case Execution

When executing test cases, testers need to document results quickly. BugCapturer, a free Chrome extension for bug reporting and visual feedback, makes this part frictionless:

Annotated screenshots: When a test case fails, capture the exact state of the page with arrows and text highlighting the issue — no need to describe it in words.

Screen recording: For complex scenarios (e.g., a multi-step login flow with timing issues), record a short WebM video of the full test execution.

Auto tech metadata: URL, browser, OS, screen resolution, and viewport are captured automatically — critical for reproducing environment-specific bugs.

Diagnostic data: Console errors and failed network requests (HTTP status ≥ 400) are captured alongside the visual evidence. Network URLs are automatically redacted for sensitive parameters.

Excel/TSV export: One-click copy a structured bug report row to your clipboard. Paste directly into your test management tool or team spreadsheet.

This means testers spend less time writing bug reports and more time executing test cases.

Download: Test Case Template

Copy the template and examples above into your preferred format:

TestRail / Zephyr / Xray — create test cases with the standard fields

Excel / Google Sheets — use as a spreadsheet with columns for each field

Notion / Confluence — create a database with one entry per test case

Markdown — keep in your repo for version control

The template and examples in this article are ready to use. Customize the login/registration scenarios for your specific application, add your own modules, and build a complete test suite that your QA team can execute with confidence.