QA test management: from test cases to release evidence

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. It distinguishes test management from automated test execution and uses an illustrative workspace invitation feature to show 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.

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 an illustrative manual case:

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.

Completing a run in the Leera web app marks remaining pending items as skipped; API 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

Automated tests run in the relevant testing tool or CI environment. Test management organizes the intended coverage and recorded outcomes. Connecting them requires an explicit mapping between automated identifiers, cases, runs, and result states.

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.

Leera exposes supported QA operations through APIs and MCP. An integration 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. Review them for incorrect assumptions, repeated checks, and missing edge cases. Generated procedures improve a draft only when a knowledgeable reviewer checks their meaning and someone executes the resulting coverage.

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.

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.

Does Leera execute automated tests?

Leera QA manages test definitions, plans, runs, and results. Automated execution remains in your testing tools or CI system. Integrations through supported APIs or MCP need their own setup, permissions, and result mapping.

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. API 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 can suggest cases from a Planner issue. Review the setup, steps, expected results, and relevance, then select cases to save. Generated cases still need human review and actual execution.

Sources and further reading

• OWASP: Web Security Testing Guide
• Ham Vocke: The Practical Test Pyramid