Why English? | Writing a Software Test Case Through Objective, Preconditions, Test Data, Steps, Expected Results, Traceability, Status and Defects

ORIENTATION

What this guide covers

Current fact check

Checked on 8 November 2026, the official ISTQB glossary defined a test case through preconditions, inputs, actions, expected results and postconditions. ISTQB CTFL v4.0.1 described test design as elaborating test conditions into test cases and identifying test data and environment needs. The current Test Analyst syllabus said cases should be repeatable, verifiable and traceable to the test basis.

What this guide does not cover

This article owns writing an individual software test case. It does not own a usability test plan, test strategy, automated test framework, defect report, user story, product requirements document, security assessment or release approval.

Worked example

Every chapter returns to a fictional secondary-school event-registration page that accepts eligible students, prevents duplicate registration, displays accessible confirmation and preserves an auditable status. It is fictional, low-stakes and educational; it does not report a real school, clinical decision or guaranteed outcome.

Warm up with eduKate’s guides to explaining scientific evidence and asking better questions in class.

CHAPTER 1 OF 16

1. Start With the Test Basis

Back to contents

Why this move matters

Identify the approved requirement, acceptance criterion, rule, design, risk or defect that justifies the test.

Turn a requirement into an observable check

Identify the approved requirement, acceptance criterion, rule, design, risk or defect that justifies the test. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The duplicate-registration rule is copied from the current user story and product requirement, not from a tester’s memory. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

If the test basis is contradictory, pause and clarify rather than choosing the easiest interpretation. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Start With the Test Basis”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 2 OF 16

2. State One Observable Objective

Back to contents

Why this move matters

Write what behaviour the case will check and the outcome that can be observed.

Turn a requirement into an observable check

Write what behaviour the case will check and the outcome that can be observed. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The objective is to prevent a second active registration for the same student and event. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

One case may exercise several screens, but its decision should remain clear. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “State One Observable Objective”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 3 OF 16

3. Name the Relevant Risk

Back to contents

Why this move matters

Explain what could go wrong, who is affected and why this case deserves attention.

Turn a requirement into an observable check

Explain what could go wrong, who is affected and why this case deserves attention. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, Duplicate registration could consume limited places and mislead organisers about attendance. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Risk guides priority but does not predict that failure will occur. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Name the Relevant Risk”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 4 OF 16

4. Choose the Test Technique and Coverage Item

Back to contents

Why this move matters

Use an appropriate technique such as equivalence partitioning, boundary analysis, decision tables or state transitions and name what this case covers.

Turn a requirement into an observable check

Use an appropriate technique such as equivalence partitioning, boundary analysis, decision tables or state transitions and name what this case covers. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The case covers the already-registered state and the attempted transition to a second active booking. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

One representative value does not cover every value in a partition. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Choose the Test Technique and Coverage Item”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 5 OF 16

5. Define Preconditions Precisely

Back to contents

Why this move matters

State the required system, account, permissions, configuration, record state and dependencies before execution.

Turn a requirement into an observable check

State the required system, account, permissions, configuration, record state and dependencies before execution. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The student account is active, eligible for the event and already has one confirmed booking. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

A precondition that cannot be reproduced weakens the result. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Define Preconditions Precisely”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 6 OF 16

6. Create Controlled Test Data

Back to contents

Why this move matters

List safe, representative and versioned input data, including boundary and invalid values where relevant.

Turn a requirement into an observable check

List safe, representative and versioned input data, including boundary and invalid values where relevant. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The tester uses a synthetic student ID and an event with exactly one existing active booking. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Do not use real personal data merely because it is convenient. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Create Controlled Test Data”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 7 OF 16

7. Identify the Test Environment

Back to contents

Why this move matters

Record build, browser or device, configuration, integrations and tools that could affect behaviour.

Turn a requirement into an observable check

Record build, browser or device, configuration, integrations and tools that could affect behaviour. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The run uses the staging build, a named browser version and the test notification service. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

A passing staging result does not automatically prove production behaviour. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Identify the Test Environment”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 8 OF 16

8. Write Steps as Unambiguous Actions

Back to contents

Why this move matters

Use numbered actions with one clear actor, object and value while avoiding needless micro-steps.

Turn a requirement into an observable check

Use numbered actions with one clear actor, object and value while avoiding needless micro-steps. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The tester opens the event, selects Register and confirms using the defined account. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Interface labels can change, so preserve intent as well as the visible control name. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Write Steps as Unambiguous Actions”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 9 OF 16

9. Write Expected Results Before Execution

Back to contents

Why this move matters

Describe the observable response and state change that must follow each decisive action.

Turn a requirement into an observable check

Describe the observable response and state change that must follow each decisive action. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The system blocks the duplicate, displays an accessible explanation and leaves the original booking unchanged. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

“Works correctly” is not an expected result. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Write Expected Results Before Execution”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 10 OF 16

10. Include Postconditions and Cleanup

Back to contents

Why this move matters

State the data and system state after the test and any restoration required.

Turn a requirement into an observable check

State the data and system state after the test and any restoration required. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, No second booking exists, the original remains confirmed and synthetic notification records are removed. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Cleanup should not destroy evidence needed for defect analysis. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Include Postconditions and Cleanup”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 11 OF 16

11. Record Actual Result and Evidence

Back to contents

Why this move matters

During execution, capture the observed result, timestamp, build and proportionate evidence.

Turn a requirement into an observable check

During execution, capture the observed result, timestamp, build and proportionate evidence. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The blocked message appears, the booking count stays at one and the log records a rejected duplicate attempt. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

A screenshot alone may omit data or backend state. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Record Actual Result and Evidence”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 12 OF 16

12. Assign Status With a Defined Rule

Back to contents

Why this move matters

Use agreed states such as passed, failed, blocked or not run and apply their meanings consistently.

Turn a requirement into an observable check

Use agreed states such as passed, failed, blocked or not run and apply their meanings consistently. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The case is blocked when the notification dependency is unavailable, not passed because the first screen looked correct. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Status names differ across teams and tools. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Assign Status With a Defined Rule”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 13 OF 16

13. Link Failures to a Separate Defect Record

Back to contents

Why this move matters

Reference the defect ID and preserve expected versus actual behaviour, severity evidence and reproduction context.

Turn a requirement into an observable check

Reference the defect ID and preserve expected versus actual behaviour, severity evidence and reproduction context. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, A duplicate booking is created, so the case fails and links to a defect containing logs and impact. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Test-case failure and defect severity are related but not identical decisions. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Link Failures to a Separate Defect Record”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 14 OF 16

14. Maintain Bidirectional Traceability

Back to contents

Why this move matters

Link requirement to test and test result back to the relevant requirement, risk or change.

Turn a requirement into an observable check

Link requirement to test and test result back to the relevant requirement, risk or change. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, A reviewer can see which duplicate-booking rule was tested and which cases would need rerunning after a change. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Traceability does not prove that coverage is sufficient. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Maintain Bidirectional Traceability”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 15 OF 16

15. Review for Clarity, Independence and Accessibility

Back to contents

Why this move matters

Ask a second person to run the case and report every assumption, ambiguous noun and inaccessible instruction.

Turn a requirement into an observable check

Ask a second person to run the case and report every assumption, ambiguous noun and inaccessible instruction. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, A keyboard-only tester reveals that “click the green icon” is both ambiguous and inaccessible. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Independent review cannot simulate every user or technology. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Review for Clarity, Independence and Accessibility”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

CHAPTER 16 OF 16

16. Update Without Erasing History

Back to contents

Why this move matters

Version the case when requirements, interfaces or risks change and preserve prior execution evidence.

Turn a requirement into an observable check

Version the case when requirements, interfaces or risks change and preserve prior execution evidence. Name the behaviour, input and visible outcome before writing clicks or commands. A test case is stronger when the reader can tell which rule is being challenged.

Run the worked case exactly as written

For the fictional service, The registration flow gains a waitlist, so expected states and coverage are revised with a dated change note. A second tester should be able to prepare the same state, use the same data and recognise pass or fail without reading the author’s mind.

Separate expected result from actual result

Write the expected result before execution. Record the actual result, evidence and environment during execution; otherwise hindsight can quietly redefine success around whatever happened.

Keep the test bounded and traceable

Editing an old expected result after execution can falsify the record. Link the case to its requirement or risk, preserve the version tested and route a failure into a separate defect record rather than rewriting the case to make the run pass.

Student, parent and career transfer

Make one evidence card for “Update Without Erasing History”: source location, plain-language meaning, limit and next question. A parent or teacher can ask for one everyday explanation and one specialist explanation; both must preserve the same conditions. This habit supports software testing, development, product work, quality assurance, business analysis, digital services, school computing projects and user acceptance testing without promising a grade, admission, funding decision or job.

PRACTICE LAB

Build a software test case decision trail

Student route

1. Choose one original report inside this guide’s scope.
2. Copy its objective and underline actor, action, context, evidence and intended decision.
3. Draw the specific reasoning chain used in this article.
4. Mark each step reported, inferred, contested or unknown.
5. Rewrite the conclusion so it preserves the narrowest important limitation.

Parent or teacher route

Ask the learner to explain turn a software requirement or risk into a repeatable, verifiable and traceable test case twice: once to a classmate and once to a method specialist. Praise a precise correction and a well-stated unknown; both show disciplined attention to evidence.

Early-career route

Create a one-page software test case audit with source link, date checked, scope, method logic, decisive wording, contrary evidence, limit and next action. A colleague should be able to continue without guessing.

Continue with eduKate’s guides to reading course and career information and giving useful feedback in group projects.

USEFUL NEXT READING

Connect this narrow owner to its neighbour

Read the user-story guide for a related but different reader job. Return here when the question is specifically how to turn a software requirement or risk into a repeatable, verifiable and traceable test case. Use each guide for the reader task named in its heading.

For English practice across research, school and career communication, visit the Singapore English Tuition Centre learning site.

FREQUENTLY ASKED QUESTIONS

Questions students and parents often ask

Is a test case the same as a test scenario?

A scenario is often broader; a case normally specifies reproducible conditions, data, actions and expected results.

How detailed should test steps be?

Detailed enough for repeatability and control, but not so brittle that harmless interface wording creates constant rewrites.

Should expected results appear after every step?

Use them wherever an observable checkpoint matters. Follow the team’s template and keep the pass decision unambiguous.

Can one test case cover several requirements?

Yes when the behaviour genuinely connects them, but traceability and the reason for grouping should remain clear.

Does a passed case prove the software has no defects?

No. It shows that the specified case passed in the recorded environment and version.

Should real student or customer data be used?

Use approved synthetic or protected data unless authorised policy and safeguards require otherwise.