How to Write Test Cases for a Project Report (Format and Examples)

By Vivek Singh · 11 October 2026 · 3 min read

In short

A test case is one check of the system written as a table row: an ID, what is being tested, the steps, the input, the expected result, the actual result and pass or fail. A project report's testing chapter explains the types of testing done, lists the test cases module by module, and ends with a summary of results.

Key takeaway

The testing chapter proves the system works and fails safely. It needs three things: the types of testing you carried out, test cases in a table for every module with valid and invalid inputs, and a summary of results. Examiners look for the table, and for at least a few cases where wrong input is rejected.

Types of testing to describe

Explain each in two or three sentences, and say what you tested with it in your project.

Unit testing: each function or module on its own
Integration testing: modules working together, such as login leading to the dashboard
System testing: the complete system against the requirements
Acceptance testing: the system used by its intended users, or by your guide
Black box and white box testing: testing by inputs and outputs, and testing the code's internal paths

Describe only what you really did. A paragraph on performance testing with no numbers behind it invites a question you cannot answer.

The test case table

These columns are the common format:

Column	What goes in it
Test case ID	A unique ID, such as TC_LOGIN_01
Description	What is being checked
Preconditions	What must be true before the test
Steps	What the tester does
Test data	The exact input used
Expected result	What should happen
Actual result	What did happen
Status	Pass or Fail

If the table is too wide for the page, drop preconditions into the description and keep the rest.

ID	Description	Test data	Expected result	Actual result	Status
TC_LOGIN_01	Login with valid details	Registered email, correct password	Dashboard opens	Dashboard opened	Pass
TC_LOGIN_02	Login with wrong password	Registered email, wrong password	Error message, stays on login page	Error message shown	Pass
TC_LOGIN_03	Login with empty fields	Both fields blank	"Required" message on both fields	Message shown	Pass
TC_LOGIN_04	Login with unregistered email	Unknown email, any password	Error message, no hint of which field is wrong	Error message shown	Pass
TC_LOGIN_05	Open dashboard without login	Dashboard URL typed directly	Redirect to login page	Dashboard opened	Fail
TC_LOGIN_05 (retest)	After adding a session check	Same	Redirect to login page	Redirected	Pass

Use your own results. A row like the fifth, with its retest, is worth more than ten rows of "Pass".

Writing good test cases

One check per case. If the description has "and" in it, split it.
Cover three kinds of input: valid, invalid, and boundary (empty, too long, zero, negative, a date in the past).
Write the expected result before you run the test.
Be exact about test data. "Valid email" is weaker than the email you typed.
Group by module, with a sub-heading for each: login, registration, the main transaction, reports.
Match your requirements. Every functional requirement in the earlier chapter should have at least one test case.

Summary of results

End the chapter with a small table and one paragraph:

Module	Test cases	Passed	Failed, then fixed
Login and registration	[number]	[number]	[number]
[Your main module]	[number]	[number]	[number]
Reports	[number]	[number]	[number]

Then state which defects were found, how they were fixed, and anything still open, which also belongs in your limitations (conclusion and future scope).

Common mistakes

Only valid inputs tested
Expected and actual results copied word for word in every row
Test cases for features the system does not have
No link between the requirements and the tests
Screenshots of test runs with no figure numbers

In a BlackBook report

A blackbook written with BlackBook has a testing chapter with test case tables for its own modules, in this format. They describe what should be tested: run each one on your system and replace the actual result and status with what really happened. Testing is also one of the most asked-about chapters in the viva.

Frequently asked questions

How many test cases should a project report have?

There is no fixed number. Final year reports commonly show 20 to 40, covering every module, with both valid and invalid inputs. Coverage of each module matters more than the count.

What is the difference between black box and white box testing?

Black box testing checks what the system does from the outside, by giving inputs and checking outputs, without looking at the code. White box testing checks the code itself: its branches, loops and paths. Most test cases in a project report are black box.

Should I include failed test cases?

Yes. One or two that failed at first, with what you fixed and the result on retest, show that testing was real. A table where everything passed first time is not believable.

What is the difference between a test case and a test plan?

The test plan says what will be tested, how, by whom and with which tools. Test cases are the individual checks carried out under that plan.

Written by

Vivek Singh

Founder of BlackBook

University of Mumbai graduate and software engineer. He built BlackBook so students can put their time into studies and exams, not months of formatting. More about BlackBook