How to Write Test Cases and Assign Them to Pull Requests

Good QA lives next to the code, not in a separate spreadsheet nobody opens. When you write test cases for pull requests and attach them directly to the PR, every reviewer can see exactly what was verified before merge. KazTrack keeps test cases, suites, and results inside the same GitHub-native workspace as your PRs, so the outcome syncs back to the real pull request. This tutorial covers writing solid test cases, organizing them into suites, assigning them to a PR, and recording results.

Prerequisites

A KazTrack project with a connected repository and at least one open pull request.
A role that allows logging QA work (tester, manager, or owner — or a custom role with the right permissions).
Optional: an MCP token if you want an AI agent to draft cases from the diff.

Step 1: Read the pull request before writing anything

A test case written without reading the change is a guess. Open the PR in your project and review its diff and description. Ask:

What user-facing behavior changed?
What edge cases does the diff touch (empty states, permissions, currency, timeouts)?
What could silently break elsewhere?

If you use an MCP agent, point it at the PR context tool to pull the diff and any already-attached cases. Reasoning over the diff yourself — or letting the agent reason over it — produces sharper cases than generic templates.

Step 2: Organize with a test suite

Group related cases into a test suite so they stay reusable across PRs. Suites map naturally to features:

Checkout — coupons
Auth — password reset
PR review — label sync

Create a suite from the Test Cases area, then add cases under it. Reusing a suite across multiple PRs means you build a regression library over time instead of rewriting the same checks.

Step 3: Write clear, runnable test cases

A strong test case is unambiguous and independently executable. Use a consistent shape:

Title — the behavior under test, stated plainly.
Preconditions — required state before you start.
Steps — numbered, concrete actions.
Expected result — exactly one observable outcome.

A worked example:

Title: Expired coupon is rejected at checkout
Preconditions: A coupon exists whose expiry date is in the past
Steps:
  1. Add any item to the cart
  2. Enter the expired coupon code
  3. Click Apply
Expected: Checkout shows "This coupon has expired" and the total is unchanged

Write one expected outcome per case. If you find yourself writing “and also,” split it into two cases — that keeps pass/fail results meaningful.

Step 4: Generate cases with AI (optional)

When a PR is large, drafting every case by hand is slow. KazTrack can generate test cases from a pull request using its optional AI generation. The agent reads the diff and proposes cases you then review and edit. Treat AI output as a first draft: prune duplicates, tighten vague expectations, and add the edge cases the model missed. Note that AI generation and execution spend your project’s own LLM credits, so use them where they save real time.

Step 5: Assign the cases to the pull request

This is the step that ties QA to the code. From either the test case or the PR, assign your cases to the target pull request:

Open the PR (or the case).
Choose Assign to PR and select the pull request.
Confirm the cases now appear in the PR’s test case list.

Assigning links the case to that specific PR so reviewers see the verification scope right where they approve the merge. You can assign a whole suite at once when the feature maps cleanly to one PR.

Step 6: Execute and record results

Now run each case and record the outcome. For every assigned case, mark it passed or failed with a short note:

Case: Expired coupon is rejected at checkout
Result: failed
Note: Coupon applied a 10% discount instead of erroring. Total dropped from $50 to $45.

Recording results does two things. First, it builds an auditable QA history on the PR. Second, the aggregate outcome can drive the PR’s workflow state — a clean run supports moving the PR to passed, while a failure pushes it to failed, which maps to a GitHub label and syncs back to the pull request.

If you prefer automation, an MCP agent with a tester-level token can execute assigned cases and record results for you, then post a summary comment to the GitHub PR.

Step 7: Report failures back to GitHub

A failed case should not stay buried in QA. Post a comment to the pull request describing what broke, the steps to reproduce, and the expected versus actual result. Because comments post to the real GitHub PR, the author sees the failure in their normal review flow. Move the PR to failed so its label reflects reality, and the developer knows to push a fix before re-testing.

Step 8: Re-run after the fix

When the developer addresses the failure, re-run only the affected cases — your suite makes this fast. Update each result, and once everything passes, move the PR back through ready_for_testing to passed. The regression suite you built now protects this behavior on future PRs touching the same feature.

Troubleshooting

Can’t assign a case to a PR — confirm the PR’s repository is connected to this project and that you have permission to log QA work.
Results don’t change the PR label — workflow labels are a separate action; setting a case to failed records the result, but you (or an agent) still move the PR to failed to update the GitHub label.
AI generation returns nothing useful — the diff may be too large or non-functional (pure formatting). Narrow the request or write the cases manually.
Duplicate cases pile up — keep cases in suites and reuse them across PRs instead of recreating them each time.

Key takeaways

When you write test cases for pull requests and assign them directly, QA becomes part of the merge decision instead of an afterthought. Organize cases into reusable suites, record clear pass/fail results, and let failures sync back to GitHub so authors act on them immediately. Open a pull request in KazTrack and attach your first test suite — your next review will show exactly what was verified.