To document software test cases, connect each case to a requirement, specify the starting conditions and steps, and compare what actually happened with a defined expected result. Keep the execution record and software version. A screenshot of an open application does not establish that every feature works.
This guide helps you prepare and record tests for software you built. The results-chapter guide covers presenting that evidence in Chapter Four. Your supervisor and departmental brief decide the required testing scope and report layout; this article is not a certification or an institutional standard.
Still selecting the deliverable? The Computer Science project-topic guide helps compare candidate work by accessible inputs and evaluation evidence before turning a proposal into a test plan. Its examples are fictional planning exercises, not completed tests.
You have two jobs: test the software and explain the evidence clearly. UniDraft helps organise the written project around the test records and results you confirm, with an editable Word document for review. Start your project document with UniDraft; you remain responsible for executing the tests and checking the observations.
Start with a requirement you can check
The requirements-source and acceptance worksheet helps turn an actual need into a clear, traceable statement. Keep proposed wording and stakeholder confirmation separate from implementation and test results.
Check the design models against the same requirements. A relationship or goal drawn in a diagram should not be mistaken for an implemented, tested rule.
“The system is efficient” does not specify a testable outcome. Identify a concrete behaviour and the conditions under which it should occur. If a requirement remains ambiguous, clarify it before assigning pass or fail.
Fictional teaching example: a proposed equipment-booking application has a rule that a user cannot reserve an item already booked for the same time. No application, test run or successful result is being reported here. This invented requirement only illustrates planning.
| Requirement | Candidate check | What would remain untested? |
|---|---|---|
| Reject an overlapping reservation | Attempt a second reservation for the same item and period | Other dates, different items, concurrent requests and access controls need their own relevant checks |
| Allow a valid reservation | Submit an available item and permitted period | One successful path does not establish performance under load |
| Explain missing required input | Omit a field that the specification requires | An error message alone does not establish that invalid data was excluded from storage |
The ISTQB Foundation Level syllabus v4.0.1, by its credited authors and copyright holder ISTQB, explains comparing actual and expected results and tracing tests to their basis. Those testing concepts inform this guide; no accreditation or endorsement is claimed.
Separate the case from its execution
A case describes the planned check. A run records what happened when you executed it against a particular version. Keep both: changing the code should not erase the earlier run.
Use this original worksheet, adapted to your project:
| Field | What you should enter |
|---|---|
| Case ID and requirement | A stable identifier and the behaviour being checked |
| Preconditions | Starting data, account role and relevant configuration |
| Input and steps | Values and actions sufficient to repeat the check |
| Expected result | The observable outcome required by the specification |
| Build and environment | Software version, relevant device, browser or runtime, and configuration |
| Run date and actual result | What you observed, including uncertainty or interruption |
| Evidence reference | A permitted screenshot, log or other retained record |
| Status and issue reference | Your defined status and any associated defect record |
NIST's 2017 draft data-integrity test plan, section 7.1 illustrates separating requirements, procedures, expectations and observations in a specific laboratory context. Its security controls and test scenarios are not a required template for Nigerian student projects. The worksheet above is an original student documentation aid.
Write an expectation before seeing the outcome
In the fictional booking example, the planned case could say:
- Start with a permitted test account and an existing booking for a specified item and period.
- Attempt a second reservation that overlaps that period.
- Check the response and the permitted record of whether another reservation was created.
The expected result should state the specified rejection and data outcome. The actual result is not filled in here because no test was run. Do not copy an expected result into the actual-result column or mark a planned test as passed.
Record enough detail to repeat the check without publishing passwords, real students' details or private infrastructure addresses. Use authorised test data and an appropriate environment. Permission to develop a system is not permission to test somebody else's live service.
Choose cases for the behaviours and risks
Do not stop at the easiest successful journey. Consider relevant invalid inputs, boundaries, permissions and interactions. Which cases matter depends on your requirements and the consequences of a failure.
For the booking example, an overlap rule needs a definition: does one booking ending exactly when another begins count as a conflict? Resolve that requirement before choosing the boundary inputs. Do not invent a convenient rule after the application behaves differently.
Functional checks do not automatically establish usability, security or performance. If you claim a response time, record what action was timed, under what conditions, with which tool and how repeated observations were summarised. If you did not run an authorised user evaluation, do not turn your own demonstration into participant feedback.
For a separate user-task evaluation, use the usability-testing guide to plan neutral tasks and record independent completion, assistance and observed barriers. Keep those participant observations distinct from functional test passes.
Define statuses and keep failures visible
For your report, define statuses clearly. One practical scheme distinguishes a completed pass, a completed failure, a blocked attempt and a case not yet run. This scheme is illustrative, not a mandated taxonomy. A blocked test is not a pass, and it may not establish a defect in the feature itself.
When an observed result differs from the requirement, retain the original run. Record the steps, expected behaviour, actual behaviour, environment and relevant evidence in the issue note. Avoid a claim about the root cause until it has been investigated.
After a change, test the affected behaviour again and consider related behaviour that could have been affected. ISTQB distinguishes checking a particular fix from checking for unintended consequences of a change. Identify the new build and run; do not replace the original failed entry with a later pass.
Summarise what the evidence supports
Your report should let a reader follow requirement → case → run → evidence → issue or conclusion. Explain the scope, environment, remaining failures and work not tested. A percentage needs a defined denominator and a rule for blocked or unexecuted cases. Counting the same case's repeated runs as new requirements would misrepresent coverage.
For Chapter Four, show a readable summary and refer to detailed records in the appropriate appendix. Retain enough evidence for review while protecting confidential data. A narrow set of passing cases cannot justify “the system is error-free.”
Before your defence, practise showing one requirement, its case and the actual evidence. Explain one limitation and, where relevant, how a failure led to a documented change. Do not invent perfect results to make the presentation easier.
UniDraft can help organise project documentation around the methods and findings you confirm. It does not execute your software tests or create their results. Explore the project workflow.
