How to Write a Software QA Test Case: A Worked Example
Learn to turn a simple login requirement into clear positive, negative and boundary test cases with measurable expected results.
A useful test case answers four questions: what are we checking, what conditions exist before the test, what should the tester do, and what exactly should happen? This guide works through a student project login screen so the ideas can be used in practical SQA assignments.
Start with a testable requirement
Imagine the requirement is: an existing student can sign in with a valid email and password. That statement is the starting point, not yet a test case. Identify the inputs, action, result and important conditions such as whether the student account exists.
Make the expected result observable. Instead of writing 'login works', write 'the user reaches the student dashboard and the sign-in error is not shown'. If requirements are unclear, record an assumption and ask the project stakeholder to confirm it.
Write positive and negative cases
A positive case uses a registered email, the correct password and an active account. Record a unique ID such as LOGIN-01, a brief purpose, test data placeholders, the steps and the expected result.
A negative case might use a valid email with a wrong password. The expected result should be a clear error without creating a signed-in session. Do not put real passwords or personal student data into shared test reports.
- LOGIN-01 — valid credentials: dashboard shown, session established.
- LOGIN-02 — wrong password: error shown, no signed-in session.
- LOGIN-03 — empty email: validation shown before request.
- LOGIN-04 — malformed email: validation shown without a crash.
Use boundary values and repeatable evidence
When a field has a documented maximum length, test a value at the limit, one shorter and one longer. Boundary tests depend on the actual requirement; do not invent a maximum length just to complete an assignment.
Record actual result separately from expected result. A failure report should include the environment, exact steps, input type, screenshot where appropriate and impact. 'Button broken' is less helpful than 'submit remains disabled after both valid fields are completed on a 375px viewport'.
Connect testing to the defect life cycle
After finding a failure, reproduce it, assign an identifier, describe severity and send it for developer review. Retest the specific fix and run a short regression around nearby functionality, such as password reset and account navigation.
A failed test does not always prove a code defect; it can expose a misunderstanding of the requirement or an unavailable dependency. Keep the evidence and update the case once the expected behaviour is confirmed.
Quick checklist
- Each test has a unique ID and a single clear objective.
- Preconditions and safe test data are documented.
- Steps can be followed by another tester.
- Expected and actual outcomes are distinct.
- Defect evidence explains how to reproduce the failure.
- Regression checks cover functionality near the fix.
Always confirm current syllabus, coursework and assessment rules with your institute or lecturer.