Writing Test Cases

Anatomy of a Test Case

Field	Description	Example
Test Case ID	A unique identifier for tracking and reference	TC-LOGIN-001
Title	A short, descriptive summary of what is being tested	Verify successful login with valid credentials
Preconditions	What must be true before the test starts	User account ‘testuser@example.com’ exists and is active
Steps	The exact actions the tester performs, in order	1. Open login page 2. Enter email 3. Enter password 4. Click ‘Sign In’
Expected Result	What should happen if the software works correctly	User is redirected to the dashboard and sees a welcome message
Priority	How important this test is (High, Medium, Low)	High

Test Case TC-001

5 fields

Title:"Login with valid credentials"

Preconditions:"User account exists"

Steps:"1. Enter email 2. Enter password 3. Click Login"

Expected Result:"User sees dashboard"

Priority:"High"

A Detailed Example

TC-CHECKOUT-003: Verify order total updates when quantity is changed

Preconditions:

• User is logged in
• ‘Blue Running Shoes’ ($89.99) is in the cart
• User is on the Cart page

Steps:

1. Locate the quantity field next to ‘Blue Running Shoes’
2. Change the quantity from 1 to 3
3. Click ‘Update Cart’
4. Observe the line item subtotal and order total

Expected Result:

• Line item subtotal: $269.97 (3 × $89.99)
• Order total updates with tax and shipping
• ‘Cart updated’ confirmation message appears

Priority: High

Quick check

Question 1 of 10 correct

Which expected result is best?

The page works correctlyEverything looks fineA success banner displays 'Order confirmed' and the cart is emptyThe system does what it should

HintSubmit

Scenarios vs. Test Cases

Test Scenario

• High-level: describes WHAT to test
• Example: 'User Login'
• Describes a user goal or workflow
• Typically one per feature/flow

Test Case

• Detailed: describes HOW to test
• Example: 'Login with invalid password'
• Step-by-step through one specific path
• Many per scenario (10, 20, 50+)

VerdictThink scenarios first, then drill into specific cases. One scenario usually produces many test cases.

From one scenario (User Login) we derive many test cases:

Test Case ID	Title	Type
TC-LOGIN-001	Login with valid email and correct password	Positive
TC-LOGIN-002	Login with valid email and incorrect password	Negative
TC-LOGIN-004	Login with empty email field	Negative
TC-LOGIN-006	Login with SQL injection in email field	Negative / Security
TC-LOGIN-008	Login after 5 failed attempts triggers account lockout	Negative

Positive vs. Negative Testing

Positive Testing

Does it work when things are right?

Valid email: user@test.com

Valid password

Login should work

VS

VS

Negative Testing

Does it handle wrong input gracefully?

Invalid email: not-email

Empty password

Should show error, NOT crash

Positive Testing

• Valid inputs, expected workflow
• 'Does it work when used correctly?'
• Valid email + password → login works
• Upload PNG under the size limit
• Usually: one happy path per feature

Negative Testing

• Invalid inputs, unexpected usage
• 'Does it fail safely when used wrong?'
• Email without @ → error shown
• Upload 500MB when limit is 10MB → rejected
• Usually: many paths per feature

VerdictFor every positive case, write 2–3 negative ones. The valid path is one road; invalid paths are many.

---

Practice: Fill in the Blank

The field in a test case that describes what must be true before the test begins is called .

SubmitShow Hint

---

---

Quiz

Question 1 of 30 correct

Which test case field describes the exact actions a tester should perform?

PreconditionsStepsExpected ResultPriority

HintSubmit