QA / Test management / Software testing
QA test management: from test cases to release evidence
Use a worked test-case example and reusable template to connect requirements, shared steps, test runs, defects, and release evidence in Leera QA.
At a glance
Whether a person or AI produced the change, a release needs evidence. Use a library for expected behavior, a plan for coverage, and a run for recorded results. Keep manual checks and configured automation connected to requirements, defects, and the environment, with missing coverage visible in the release decision.
QA test management is the practice of keeping intended coverage, test procedures, execution results, and defects connected. A useful system lets a team answer four questions: what should work, what was checked, what happened, and what still needs a decision. Storing many test cases is helpful only when those records support those questions.
This guide describes a practical workflow using Leera QA, for changes produced by people or with AI. It distinguishes coverage records from execution and explains where configured automation fits. An illustrative workspace invitation feature shows how requirements become evidence. The examples are proposed procedures, not test results from a real release.
Give each record a clear job
Many reporting problems begin when a test case is treated as both a procedure and the latest result. Editing it for the next release then makes it difficult to understand what happened in the previous one. Separate reusable definitions from execution records.
| Record | Question it answers | Example |
|---|---|---|
| Requirement or issue | What behavior should change? | Expired invitations show a recovery path |
| Test case | How will we verify a behavior? | Open an expired link and inspect the response |
| Shared steps | Which repeated procedure can be maintained once? | Sign in as a workspace administrator |
| Test plan | Which coverage do we intend to include? | Invitation regression checks |
| Test run | What happened in this execution? | Checks against the release candidate in staging |
| Defect | What failed and needs work? | Resend action creates an unusable replacement |
In Leera, the library holds reusable cases, plans select coverage, and runs preserve execution details. Linking cases to Planner issues helps connect verification with the work that motivated it. Keep names specific enough that a reviewer can recognize the purpose without opening every record.
Select coverage from behavior and risk
Begin with acceptance criteria and the consequences of failure. A successful path is necessary, but it rarely covers the entire feature. Consider permissions, invalid inputs, expired state, repeated actions, interrupted requests, and interactions with existing behavior.
For invitations, a risk discussion might ask whether a link can be reused, whether the wrong role can resend it, and whether a user sees private workspace information before accepting. These are candidate questions. The expected behavior must come from the product’s actual requirements.
For security-sensitive web behavior, the OWASP Web Security Testing Guide provides a maintained reference covering areas such as authentication, authorization, and input validation. Use the relevant sections to improve a review; a passing functional test list is not a substitute for a security assessment.
Prioritize checks according to the impact of failure, the likelihood of change, and what other evidence already exists. Record the reason for important exclusions. A team can make a deliberate decision to defer low-impact coverage; it cannot reason reliably about coverage that disappeared without explanation.
Write cases another tester can reproduce
A useful case identifies the purpose, preconditions, input data, actions, and expected results. It should describe enough detail to reproduce the check while avoiding irrelevant instructions that will become maintenance work.
Here is a worked manual case for an illustrative invitation policy. The proposed product rule is: an expired link cannot create membership; the page explains the expiry and tells the recipient to request a replacement from an administrator. Confirm the real policy before reusing this case. This is a test-design example, not a claim about Leera’s own invitation behavior.
| Field | Example content |
|---|---|
| Reference | INV-01, linked to the approved expired-invitation requirement |
| Title | Expired invitation is rejected without creating membership |
| Preconditions | A synthetic recipient is not a member; an unaccepted invitation exists with an expiry in the past; a workspace administrator can inspect membership |
| Data | A disposable workspace, controlled expired-link fixture, and synthetic recipient |
| Coverage purpose | Verify the expired path and absence of unauthorized membership |
| Cleanup | Revoke the fixture and remove disposable data using the approved test procedure |
| Step | Action | Expected result |
|---|---|---|
| 1 | Open the controlled expired link in a fresh signed-out browser session | The page displays an expired-invitation message; it does not complete acceptance |
| 2 | Inspect the recovery guidance and available actions | Guidance tells the recipient how to request a replacement; it does not expose a usable accept action for the expired link |
| 3 | Refresh the page and open the same link again | The expired result remains; repeating the request does not grant membership |
| 4 | In a separate administrator session, inspect the recipient’s workspace membership | No membership was created by the expired-link requests |
Step 4 checks an effect that a reassuring message alone cannot establish. If the tester cannot inspect membership, that part of the case is unverified. Record the limitation instead of marking the whole procedure passed.
Keep the reusable procedure separate from the execution record. A completed execution should identify the case snapshot, build, environment, browser, tester, execution time, actual result per step, evidence references, and any linked defect. Record observed results after performing the check; do not prefill them from the expected-result column.
For example, if the message is correct but the recipient appears as a member, record the failed membership expectation and the observed evidence. Open a linked defect, retain the failed execution, and retest against the fixed build. A later passing run should not erase the earlier failure.
A reusable test-case template
Copy this structure into your case and its associated run notes. Some context belongs in a linked requirement or run note rather than a dedicated Leera case field.
| Template field | Fill in |
|---|---|
| Purpose and requirement | The specific behavior and source issue or decision |
| Preconditions | Required state, role, environment access, and setup |
| Test data | Controlled fixture references; avoid secrets in prose |
| Numbered steps | One meaningful action and observable expected result per step |
| Evidence required | What another reviewer needs to verify the observation |
| Cleanup | How disposable state is removed or reset |
| Execution context | Actual build, environment, tester, time, and case snapshot |
| Execution outcome | Observed step results, evidence links, and defect reference where needed |
Add separate cases for a valid link, an already-used link, and unauthorized replacement requests when the requirements call for them. The template helps the author ask consistent questions; it cannot decide the coverage boundary for the team.
Do not place a secret invitation token in a broadly visible description. Reference a controlled fixture or use the team’s approved method for obtaining test data. Likewise, “use the usual account” is only reproducible for people who already know what the author meant.
Split checks when their results can fail independently. A single case that tests account creation, invitations, billing, and deletion is hard to diagnose and expensive to repeat. Keep the expected result close to the step that establishes it.
Reuse setup without hiding the important behavior
Shared steps are valuable for stable procedures such as signing in or creating a disposable workspace. They reduce duplicated setup and provide a clear place to update it. They can also make a case difficult to understand if every significant action is hidden behind a generic reference.
Use shared steps for repeated setup and keep the behavior under test explicit in the case. If different roles produce different outcomes, name the role in the case rather than letting an inherited sign-in sequence make that choice implicitly.
Before changing a shared sequence, review which cases depend on it. A login flow change may require new preconditions or different test data. An improvement to a helper procedure should not silently change what a test claims to verify.
Leera expands shared steps into the snapshot used by a run. That separation helps preserve the procedure associated with an execution while allowing the library to evolve. Add a maintenance note when a change has a broader effect on coverage.
Build a plan for the release question
A plan should reflect a decision the team needs to make. Examples include a focused smoke check, a feature regression pass, or a broader release review. Avoid starting with “run everything” if the team cannot explain why each case belongs in that scope.
For an invitation release, the plan might include the changed expiration behavior, role checks around resending, successful acceptance, and a small set of related account flows. Additional cases can be included when the implementation touches a shared component.
Record assumptions outside the case list: supported environments, required setup, relevant build, known exclusions, and the person who coordinates the decision. A test plan is a coverage selection, so the team may keep this additional release context in a linked project document or run notes where appropriate.
Leera can organize cases by module and connect them to issues. Sprint and epic filters use those issue relationships. Clean links therefore help both navigation and coverage selection; the filter cannot infer a missing relationship from a similar title.
Start the run with reproducible context
Before execution, confirm that the environment and selected cases match the intended release candidate. Use a clear run name and record the application build or commit in notes when it is not a dedicated field in the workflow. Capture browser, device, feature flags, or dataset details when they affect the behavior.
Leera environments can hold a name, key, base URL, and description, and the run captures the selected environment name. A familiar environment label alone does not prove that two executions used the same application version. Preserve the additional context needed to interpret the result.
The run captures case definitions so later library edits do not rewrite existing run items. If the procedure changes substantially during testing, explain which version was executed and decide whether a new run or additional case is needed. Avoid editing the library and assuming the in-progress execution now contains the new instructions.
Assign testing work clearly enough to avoid duplicate effort and orphaned cases. Before starting a time-sensitive run, verify that test accounts, permissions, and evidence upload work for the people doing the checks.
Record outcomes without hiding missing coverage
Use results to describe what actually happened. A blocked case is different from a failure in the product, and an unexecuted case is different from a pass. Keep notes concise but sufficient for another person to understand the outcome.
| Outcome | What the reviewer needs to know |
|---|---|
| Passed | The expected behavior was observed in the recorded context |
| Failed | Actual behavior differed; evidence and a defect should explain how |
| Blocked | A prerequisite prevented a meaningful execution |
| Skipped | The case was not executed, with the reason recorded |
| Pending | Work remains before the run is complete |
Completing a run in the Leera web app marks remaining pending items as skipped; REST API (Preview) integrations must explicitly request that behavior. Review those items before completion so a report does not appear more conclusive than the underlying work. A skipped result may be an intentional exclusion or unfinished coverage; the accompanying explanation matters.
Time estimates and measured execution time can help plan later work. Leera supports case estimates, aggregated plan and run estimates, and an execution timer. Interpret recorded time with context: waiting for an environment, exploring an unexpected failure, and executing a routine check have different causes.
Turn a failure into an actionable defect
A good defect connects the failed expectation to reproducible evidence. Include the environment and build, relevant preconditions, minimal steps, actual result, expected result, and the case or run reference. Explain impact without inflating severity to get attention.
For example, “Resend is broken” leaves a developer to reconstruct the observation. “Resending an expired invitation returns a replacement link that immediately displays the expired message in staging build X” identifies the path and symptom. Add a screenshot or log excerpt with sensitive details removed.
Leera’s Fail + defect workflow can bring a failed check into Planner with a linked defect. After a fix, record a follow-up execution rather than treating the developer’s status change as proof that the behavior now passes. Check whether nearby coverage should be repeated because of the fix.
Close the communication loop by linking the result back to the original issue. The next reviewer should be able to follow requirement, case, failure, fix, and verification without relying on someone’s memory.
Keep automated execution and management connected
Test management organizes intended coverage and recorded outcomes. Automated execution needs a runner that can reach the test environment and perform the checks. Connecting the two requires a clear relationship between the procedure, run, environment, and result states.
Leera includes native automation support alongside manual execution. Automation scripts attach to test cases and are validated against their steps. Configured runner pools receive queued jobs, and project-bound CI tokens can create runs. Supported MCP tools can read the case procedure, validate and save a script, list pools, and queue automated items from a run. Items without a script remain pending for a person; scripts using stored sign-in credentials require the additional QA secrets scope.
This depends on your deployment’s enabled platforms, compatible runners, permissions, and environment. Confirm that setup with a representative run and inspect its recorded results and evidence. The availability of a queueing tool alone does not establish that a runner is configured or that a test has passed.
The Practical Test Pyramid discusses using tests at different levels and avoiding excessive dependence on slow end-to-end checks. For this workflow, choose the appropriate execution layer and avoid duplicating a manual procedure merely to increase the apparent case count.
If you also use other testing tools or CI jobs, the REST API (Preview) and MCP can connect their records to the workspace. The connection still needs authentication, permissions, environment context, and handling for retries or partial failures. Verify that a result was saved to the intended run before treating a successful script exit as a complete reporting integration.
AI-generated cases need similar discipline. Leera AI can suggest cases from a Planner issue; an external AI client with MCP QA access can create and update them. Review the procedures for incorrect assumptions, repeated checks, and missing edge cases. Keep the requirement linked, execute the coverage, and inspect the evidence. An AI-written implementation and an AI-written test can share the same mistaken assumption, so compare both with the intended behavior before deciding to ship.
Review release readiness with the limits visible
Before a release decision, look at the important failures, blocked checks, skipped coverage, and unresolved defects. Confirm that the tested build corresponds to the candidate being considered. A pass percentage by itself cannot express the impact of the remaining issue.
Use a short decision note: tested scope, environment and build, evidence links, unresolved risks, the responsible decision-maker, and follow-up work. If the team accepts a known defect, record the impact and any mitigation rather than presenting the run as entirely successful.
In Leera, that note can be a test report issued from the completed run. It freezes the results as they stood, with a verdict of accept, accept with reservations, or reject, your summary of scope and risk, and sign-off from the reviewers and approvers you name. The pass rate it shows counts only cases with a verdict, and cases the run never reached are listed as not run. A completed run is read-only. Correcting a result means reopening the run with a reason, completing it again, and issuing a new version of the report; the version already issued does not change.
Afterward, maintain the library. Remove duplicate procedures, update outdated setup, improve ambiguous expected results, and add a regression case when a real defect reveals a useful gap. A smaller library with clear intent and trustworthy results is easier to operate than a large collection no one understands.
Frequently asked questions
What is the difference between a test case, plan, and run?
A case describes a repeatable check and its expected result. A plan groups cases for intended coverage. A run records an execution with its own case snapshots, environment, testers, results, and evidence. The same plan can support multiple runs.
What should a test-case template contain?
Record the requirement, purpose, preconditions, controlled test data, numbered actions with expected results, cleanup, and evidence needed. Record the actual result, build, environment, tester, and linked defect in the execution record so a reusable case does not become confused with its latest result.
Does Leera execute automated tests?
Leera manages manual testing and includes native automation support: scripts attached to cases, validation against case steps, runner pools, queued jobs, and project-bound CI tokens. Automated execution requires a configured, compatible runner and test environment; adding a case alone does not run it. Confirm the platforms and runner setup available on your deployment, then check a representative run and its evidence before relying on automation.
Can changing a case rewrite an existing Leera run?
A run keeps the case snapshot captured when it starts, including its procedure and expected result. Later library edits do not rewrite that snapshot. Review significant procedure changes and use a new execution when necessary.
What happens to pending cases when a run completes?
Completing a run in the Leera web app marks remaining pending cases as skipped. REST API (Preview) integrations must explicitly request that behavior when pending items remain. Skipped, blocked, failed, and passed outcomes remain distinct; review pending coverage before completing a run.
How can AI help create test coverage?
With a configured provider, Leera AI can suggest cases from a Planner issue for you to review and save. An external AI client connected over MCP can also create and update cases with the required QA scopes. Review the setup, steps, expected results, and relevance. Generated cases still need actual execution and evidence before a release decision.