Lok Jagruti Kendra University Students: Test Case Review Checklist for Peer Feedback

A good peer review of a test case checks whether a stranger could run it, get the same result, and know exactly why it passed or failed. Use the 12-point checklist and 100-point scoring sheet below to review a classmate’s test cases in about 15 minutes, then hold the short mock session described later to turn scores into specific fixes.

Why peer review of test cases matters more than another round of writing

Most weak test cases are not wrong; they are vague. “Check login works” feels complete to its author because the author remembers the context. A reviewer who does not share that memory spots the gaps immediately: which user, which data, which browser, what counts as “works”. That outside view is the entire value of peer feedback.

For students, review is also the fastest way to learn. Reading ten other people’s test cases teaches you naming habits, coverage patterns and typical omissions far quicker than writing your own ten cases alone. And in a software team, test cases are read far more often than they are written: by developers reproducing a bug, by new teammates, by whoever runs regression next month.

This guide gives you three reusable assets: a checklist (what to look at), a scoring sheet (how to turn opinions into numbers) and a script (how to talk about the results without friction).

The 12-point checklist for reviewing a test case

Take one test case at a time and answer each question yes, partly or no. Keep the author’s text open beside you and do not rewrite it during the review; note the problem and hand it back.

1. Unique, meaningful ID and title. Can you tell what is being tested from the title alone, without opening the case?
2. Clear objective. Is there one sentence stating what behaviour or requirement is being verified?
3. Traceability. Does it point to a requirement, user story or feature name so you can tell what it covers?
4. Preconditions stated. Are the account type, data state, environment and settings needed before step 1 listed?
5. Atomic steps. Is each step a single action a person can perform without guessing?
6. Specific test data. Are actual values given (for example an email format, an amount, a date) instead of “valid data”?
7. Observable expected result. Does each expectation describe something you can see or measure, such as a message, a status or a stored value?
8. One purpose per case. Does it test one thing, so a failure points to one cause?
9. Positive and negative coverage. Between this case and its neighbours, are both valid and invalid inputs covered?
10. Boundary and edge thinking. Are limits (minimum, maximum, empty, just over) considered where they apply?
11. Independence and repeatability. Can it run alone, in any order, and give the same result twice?
12. Priority and type labelled. Is it marked as smoke, functional, regression or similar, with a sensible priority?

Scoring sheet: converting the checklist into a 100-point review

Weights reflect how much each item affects whether the case is usable. Give full marks for yes, half for partly, zero for no. Score the whole set of cases for a feature, not just one, when judging coverage items.

Total: 100 points.

Reading the total and deciding what to do next

• 85-100: ready to share with the team; only polish wording.
• 70-84: sound structure with a few gaps; fix the lowest two criteria and re-review.
• 50-69: a rewrite of steps and expected results is needed before anyone can execute these.
• Below 50: go back to the requirement and restart the design, then review again.

Also record the lowest-scoring criterion across the whole set. A person who loses marks on expected results every time has a habit to fix, not a one-off slip.

Worked example: reviewing a weak password-reset test case

This example is illustrative. The case below was written for this article and is not taken from any real project or student.

ID: TC_07
Title: Check reset
Steps: 1. Open site and reset password.
Expected: Works properly.

A reviewer working through the sheet might score it like this:

Total: 14/100. The feedback should be about the case, not the person. A rewritten version might read:

ID: TC_PWD_RESET_01
Title: Password reset succeeds with valid registered email
Objective: Verify a registered user can set a new password via emailed link
Requirement: REQ-AUTH-04 (illustrative)
Preconditions: Active account for user1@example.com; mailbox accessible
Steps:
1. Open the login page and select "Forgot password".
2. Enter user1@example.com and submit.
3. Open the reset email and click the link.
4. Enter NewPass@2026 in both fields and submit.
5. Log in with user1@example.com and NewPass@2026.
Expected:
- After step 2, a confirmation message is shown.
- After step 4, a success message appears.
- After step 5, login succeeds and the old password is rejected.
Priority: High   Type: Functional

Now a colleague can run it and agree on pass or fail. Neighbouring cases would handle an unregistered email, an expired link and a password that breaks the rules.

Mock review session script: a 20-minute peer feedback conversation

Use two or three people: the author, the reviewer and, optionally, a timekeeper. The reviewer has already scored the cases privately. The script below is illustrative wording you can adapt.

Minutes 0-3: set the ground rules

Reviewer: “I scored your password-reset cases against the sheet. I will point to the case and the criterion, not to you. Please hold your explanations until I finish each point.”

Author: “Understood. I will note questions and answer after.”

Minutes 3-8: start with what works

Reviewer: “Your titles for TC_01 to TC_04 name the condition clearly, and the preconditions are complete. That is full marks on two criteria.”

Minutes 8-16: the top three gaps

Reviewer: “First, TC_05 expected result says ‘error shown’. Which error, and where? Second, no case covers a reset link used twice. Third, TC_06 relies on TC_05 having run first, so it loses points on independence.”

Author: “For the first, the message is ‘Link expired’. I assumed everyone knew. For the second, I did not think of reuse.”

Reviewer: “Good. Write the exact message in the expected result, and add a reuse case. For the third, can you add the setup steps inside TC_06?”

Minutes 16-20: agree actions

Reviewer: “Total is 72. Lowest criteria are expected results and independence. Shall we re-review after you revise?”

Author: “Yes, tomorrow evening. I will update the sheet with a revision note.”

Phrases that keep feedback useful

• Say “I could not tell how to execute step 3” rather than “step 3 is bad”.
• Ask “what would a failure look like here?” to expose weak expected results.
• Offer one rewrite example, then let the author do the rest.
• Disagree about severity by pointing to the requirement, not by arguing preference.

Lok Jagruti Kendra University: using peer review alongside your coursework and placement preparation

Lok Jagruti Kendra University describes itself on its “at a glance” page as a private state university established under Gujarat Act No. 19 of 2019, unifying 13 LJK institutions. Its central syllabus page lists syllabus links for programmes such as BE Computer Engineering, BE IT, BE AI & Data Science, MCA and MSc IT, which are the programmes where test case writing is most likely to appear in software engineering or project work. The links go to an external file share, so the exact place of testing in your semester is something to read in your own programme’s document.

On the career side, the LJ Industry Interaction & Placement Cell page lists workshops, mock aptitude tests, mock interviews, expert lectures and industry visits among its training activities. A reviewed, scored set of test cases is a concrete thing to talk about in a mock interview: you can explain how you found and fixed gaps in your own work.

Whether internship, project-work or online-internship activity carries credit, a fixed duration or specific documents at LJKU is not something this guide can state. Treat any such rule as unconfirmed until you see it in writing. If you want a low-risk way to practise, the free two-week online internship from CareerSwami includes a free offer letter and a free completion certificate after successful completion, and its testing work gives you real cases to put through this peer review. CareerSwami is independent and not affiliated with the university.

Verification steps for LJKU students before you rely on any of this

1. Open your programme’s syllabus from the central syllabus page and search for “testing”, “software engineering” or “project” to see where test design is taught and assessed.
2. Ask your subject faculty in writing whether peer-reviewed test documentation can be submitted as part of a lab or project file, and in what format.
3. Ask your department coordinator whether an online internship is accepted for any internship requirement, and request the answer by email or notice.
4. Check the Academic Calendar linked in the university site footer before planning review sessions around exams or breaks.
5. Ask the placement cell which testing or QA topics appear in its mock interviews or workshops, so your review practice matches them.

Applying the sheet across a 14-day internship plan

A two-week internship is short, so build review into the schedule instead of leaving it to the end.

Review habits that make the scores trustworthy

• Review in a fresh sitting. Read the cases the day after the author writes them, if you can.
• Actually execute one case. Following steps literally exposes missing preconditions faster than reading.
• Score before you talk. Numbers set privately avoid being nudged by the author’s explanation.
• Keep a log. Note date, reviewer, total and lowest criterion so progress is visible.
• Rotate partners. Different reviewers notice different gaps.

Frequently Asked Questions

How many test cases should I review in one sitting?

Aim for 8 to 12 cases, or one feature’s set, in about 15 to 20 minutes of scoring. Beyond that, attention drops and later cases get lenient marks.

Should the reviewer rewrite the test case?

No. Point out the gap and, at most, give one sample rewrite. The author learns more by fixing their own work, and ownership of the case stays clear.

What is the most common reason test cases lose points?

Expected results that cannot be observed, such as “works properly” or “no error”. The heaviest weight on the sheet sits there for that reason.

How do I review test cases when there is no written requirement?

Ask the author to state the intended behaviour in one line per feature before the review. Mark traceability as partial and note that coverage is judged against that stated intent.

Can I use this sheet for automated test scripts?

Partly. Preconditions, data, independence and expected outcomes apply directly. For code, add checks on readability, waits, selectors and reuse, which this sheet does not score.

What if my reviewer and I disagree on a score?

Go back to the criterion’s “full marks look like” column and the requirement. If still unresolved, average the two scores and note the disagreement so a third person can look later.

Does peer review replace a lead or faculty review?

No. It catches clarity and coverage gaps early, but a faculty member or senior tester can judge risk and priority with context you may lack.

Is this checklist useful for practising before a free internship in testing?

Yes. Writing and scoring a few cases beforehand lets you start the CareerSwami two-week online internship with a clear habit for structuring cases and asking for specific feedback.

Related Software Testing guides

• Central University of Kashmir Students: Handling Unreliable Internet During a Testing Internship
• Assam University Students: Choosing a Testing Specialisation Through a Two-Week Trial
• Shreyarth University Students: Turning Internship Bugs Into Interview Stories
• All Software Testing internship guides