Test environment
- Base URL
- https://staging.example.com
- Environment key
staging- Description
The release candidate for workspace setup, invitations, and project workflows.
leera QAQuality belongs with the work.Make quality part
Make quality part
of the whole project.
From the first acceptance criterion to the final release check.
Keep the cases, the coverage, and the evidence in one connected workspace.
THE WORKSPACE, IN FOCUS
The test. The result. The work to make it right. All close together.
01 / The test libraryBuild coverage once.
Build coverage once.
Keep making it better.
Give the team a shared home for test cases. Organize by module, find the right coverage, and carry the same cases into the next plan and run.
Test repository
Test cases
The details that make a release dependable.
3 modules
- high1mactive
- high2mactive
- medium45sactive
- medium2mactive
A TC key connects the case to the conversation.
01
Organize around the product.
Group cases into modules such as workspace setup, project workflow, or documents. Keep the full project library within reach when you need the wider view.
02
Find the coverage you need.
Search case titles and keys. Filter by module, tag, or status, and use the sprint or epic linked through Planner issues to find relevant coverage.
03
See useful detail at a glance.
Keep the case identity, priority, tags, and execution estimate visible in the list. Open a case for its full procedure, or start a run from the current scope.
04
Keep the library current.
Create cases, duplicate a useful starting point, and deprecate checks that no longer belong in the active set. Retain context while the product evolves.
05
Connect requirements to checks.
Link a case to the issues it covers. The issue keeps its linked tests visible, and the case keeps the requirement close to its expected result.
06
Let the repository grow.
Search and filtering work across the repository, with more cases loaded as you browse. A larger library does not have to become a longer planning meeting.
02 / Cases & shared stepsClear steps.
Clear steps.
A result you can verify.
A good case tells the next tester what to do, what to expect, and what must already be true. Keep the procedure readable and the details close at hand.
TC-20-104Manual test
Active4 steps1mWorkspace setup
A clear path from action to outcome.
01
The scenario
What are we testing, and why does it matter?
🎯 A new owner should be able to create a workspace and reach a useful starting point. Verify that the workspace name is saved and the owner can start inviting their team.
02
Before you begin
The setup, access, or test data this case needs.
🔑 Use an account with permission to create a workspace. Have a unique workspace name ready. Run against Staging using the shared sign-in preparation below.
Loading test procedure…
04
The expected outcome
Describe what a successful test looks like.
✅ The workspace is created with the chosen name, the owner has access, and the invitation action is available. Refreshing keeps the workspace in the owner’s workspace switcher.
01
Begin with the context.
Describe the scenario, record preconditions, and make the overall expected outcome explicit. Use rich text to make the important parts easy to scan.
02
Do. Then verify.
Separate action steps from verification steps. Put an expected result beside the check, with list and table views for different procedures.
03
Reuse the common setup.
Maintain repeated flows as shared step blocks. Insert them into cases, see how many cases use them, and avoid maintaining the same setup line by line.
04
Learn from each execution.
Return to a case’s run history to review previous outcomes, defects, and measured time. Use that evidence to improve the next version of the test.
A little intelligence. A clearer first draft.From acceptance criteria
From acceptance criteria
to coverage worth reviewing.
Generate suggested test cases from a Planner issue with leera AI. Review the procedures, select the useful cases, and save them to the project library with the issue link attached.
Explore leera AIAI generation requires a configured provider. Your team reviews what becomes coverage.
03 / Test plansDecide what ready
Decide what ready
needs to mean.
Turn the library into a deliberate scope. Bring the right cases into a reusable plan, see the estimated effort, and carry that coverage into a run.
Test plan
Estimated runtime5m
Selected cases 4
Organized across 3 modules. Ready to run together.
Workspace setup2
TC-20-104Create a workspace
high1mTC-20-105Invite a teammate
high2mProject workflow1
TC-20-106Move an issue to Done
medium45sDocuments1
TC-20-107Publish a project document
medium2m01
A purpose, not just a list.
Name the plan and describe what it covers. Use it for release checks, a focused feature pass, or a recurring regression routine.
02
Choose from the repository.
Search the case picker and filter by module, tag, or priority. Add individual cases or the matching set, then review the selected coverage together.
03
Keep the scope readable.
Review selected cases by module, remove work that does not belong, and keep the plan’s ordering clear. Counts show the scope as it changes.
04
Make the effort visible.
See the estimated execution time for selected cases. A case estimate takes precedence over its measured average, and missing estimates remain visible.
05
Set up the next run.
Choose the environment and default tester when starting a run. The run captures the plan’s selected cases so the team can execute a known scope.
06
Reuse, then refine.
Keep an active plan for future runs. Update the next scope as coverage evolves, or archive a plan when it has served its purpose.
- 01
Select
Choose the relevant test cases.
- 02
Prepare
Set the environment and tester.
- 03
Execute
Follow the steps and record evidence.
- 04
Review
Make the outcome visible to the team.
04 / Execution & reportsDo the check.
Do the check.
Keep the evidence.
Move through a focused execution workspace. Mark the steps, record the outcome, and leave enough context for the next person to understand exactly what happened.
0 of 4 complete
TC-20-104pending
Create a workspace
highEstimate 1m
0:0060s of estimate left
Scenario
A new team can create a workspace and start planning.
Before you begin
A workspace owner account is available for this test.
Test steps
2 of 5 steps checked
01
SharedSign in as a workspace owner
Open the sign-in page.
02
Shared
Sign in with a workspace owner account.
03
Action
Open workspace setup.
04
Action
Enter the workspace name.
05
Verify
Confirm the workspace is created.
Expected result
The workspace opens and shows the name you entered.
Expected outcome
The new workspace opens with its name, owner, and a clear place to start.
Execution notes
01
One case. Room to focus.
Keep the case navigator beside a readable procedure. Filter the work, choose a case, and advance to the next pending check within the current scope.
02
Every step has an outcome.
Mark individual steps as passed, failed, or blocked. Record the case as Pass, Fail, Block, or Skip, with guidance before an incomplete procedure can be passed.
03
Evidence arrives with the result.
Paste a screenshot, drop a file, or choose an attachment. Keep notes and evidence with the execution instead of reconstructing them after a failure.
04
A failure becomes work.
Use Fail + defect when the result needs a fix. Keep the defect connected to its execution so developers can return to the procedure and evidence.
05
Time with real context.
Track active execution time and pause when needed. Compare measured time with the original estimate and see the remaining estimated work.
06
A report you can act on.
Open the run report for pass rate, every outcome count, tag breakdowns, and timing. Pending, blocked, and skipped coverage stay visible beside successful checks.
The run keeps its snapshot.
Later changes to a case do not rewrite what the tester saw. Eligible open plan or sprint runs can add newly included cases while preserving existing items.
Completion stays explicit.
Finish a run when the review is complete. Any remaining pending cases become skipped, so the report reflects what was actually covered.
05 / Environments & credentialsSame context.
Same context.
Reproducible results.
A result is more useful when the setup is clear. Keep environments and test account details in the QA workspace, ready for the people doing the checks.
Test resources
Environments
A clear destination for every test run. Keep your team aligned on where to test.
Test environment
- Base URL
- https://preview.example.com
- Environment key
preview- Description
Review the next iteration of the welcome checklist before it reaches staging.
01
Name the environment.
Give an environment a clear name, key, base URL, and description. Choose the right context before a run starts.
02
Keep useful account details.
Store a credential label, role, username, sign-in URL, and setup notes. The list shows the account’s purpose without displaying its secret.
03
Reveal when it is needed.
Open the dedicated reveal flow when the test requires a stored credential. The secret is requested separately from the account metadata.
04
Retire setup with context.
Search active or archived resources. Archive environments and accounts that are no longer in use while earlier run context remains available.
The context belongs with the result.Less reconstruction.
Less reconstruction.
A more useful handoff.
The environment, the case snapshot, the notes, and the defect all help explain a result. Keep them close, and the next conversation can start with the evidence.
06 / The details, all togetherThe small checks.
The small checks.
The complete picture.
Quality work is also the saved procedure, the pause in a timer, and the screenshot that explains a failure. Here are the controls around the core workflow.
The library, in detail
- A stable case identity
- Keep a recognizable test-case key through the library, linked issues, plans, and execution. Copy the key or follow the case back to its definition.
- Modules & project tags
- Organize cases by product area. Share colored project tags with Planner issues, then use them to select relevant coverage.
- Active & deprecated cases
- Keep the active library useful while retaining older case definitions. Filter by status and duplicate a case when a related scenario needs its own checks.
- Coverage from the issue
- Link existing cases or create new ones from a Planner issue. Sprint and epic filters follow those issue relationships instead of requiring a second planning hierarchy.
- Execution history
- Review earlier results, timing, and linked defects for an individual case. A signal for alternating pass/fail results helps identify cases that deserve a closer look.
A procedure worth following
- Rich case descriptions
- Use headings, lists, links, and formatted context to explain the scenario. Keep preconditions and the overall expected outcome with the procedure.
- Action & verification steps
- Distinguish what the tester does from what they must check. Write the expected result beside its step and switch between list and table views.
- Reusable shared steps
- Insert a shared sequence into multiple cases. See its usage, maintain the common setup in one place, and preserve an expanded snapshot when a run starts.
- Step attachments
- Attach useful reference material to individual steps. During execution, keep result evidence beside the case so a failure comes with context.
- Estimates & measured time
- Set an execution estimate, or use the case’s average measured time when an estimate is missing. Plans and runs show the work this adds up to.
Execution without loose ends
- Assign the work
- Choose a default tester when starting a run, assign individual cases, or assign pending work together. Focus on your cases or review the whole run.
- A focused navigator
- Search and filter the case navigator. Move to the next pending case within the selected scope, with the procedure and outcome controls close together.
- Per-step verdicts
- Record passed, failed, or blocked checks as you go. A case can pass when its step checks are satisfied; incomplete work remains visible.
- Evidence & defects
- Paste screenshots, drop files, or use the file picker to attach evidence. Record notes and use Fail + defect to bring the failure into Planner.
- Keyboard & timing
- Use the execution shortcuts for results and navigation. The execution timer tracks active work and lets you pause when the test needs to wait.
A record you can return to
- A run keeps its snapshot
- The case title, description, steps, preconditions, expected result, priority, and estimate are captured for the run. Later library edits do not rewrite that record.
- Coverage can grow deliberately
- Eligible open runs from a plan or sprint can add newly included cases after review. Existing run items and their snapshots stay intact.
- A complete result picture
- Review passed, failed, blocked, skipped, and pending counts, pass rate, and results by tag. See estimated and measured execution time in the run report.
- Explicit completion
- Completing a run marks its remaining pending cases as skipped. A finished run keeps its recorded outcomes, evidence, and historical context.
- Tools around your process
- Use supported QA APIs and MCP tools alongside your testing workflow. Automated browser or CI execution belongs to the test runner you connect.
Test management that works with your test runners.
Leera organizes cases, plans, execution records, and results. Connect your automation through supported APIs or MCP tools; browser and CI test execution continue to run in your chosen testing tools.
Quality is part of the project.Start with the requirement.
Start with the requirement.
Return with confidence.
The practical details
More clarity. Before you begin.
Does test management execute our tests automatically?+
The QA module manages cases, plans, runs, and results. Automated test execution still belongs to your testing tools or CI environment. Where you connect automation through APIs or MCP, verify the supported result tools and access before relying on the integration.
Can we reuse common setup across test cases?+
Yes. Shared steps let you maintain repeated sequences separately from individual cases. Use them for setup such as signing in or creating a test account, and keep each case’s unique expected behavior explicit.
What is the difference between a test plan and a run?+
A plan is a reusable selection of test cases that defines the intended coverage. A run is an execution of a selected scope, with its own case snapshots, environment, testers, step verdicts, notes, evidence, and results. A plan can be used for more than one run.
What happens when a case changes after a run starts?+
The run retains the case definition it captured at the start, including its title, description, preconditions, expanded steps, expected result, priority, and estimate. Later library edits do not rewrite existing run items. Eligible open runs from a plan or sprint can add newly included cases after review.
What happens to pending cases when a run is completed?+
Completing a run marks any remaining pending cases as skipped. The report keeps passed, failed, blocked, and skipped outcomes distinct, so unfinished coverage is not counted as a successful check.
How do test cases connect to Planner issues?+
You can link existing cases or create cases from an issue. Cases are saved in the project test library and remain connected to the issues they cover. The library’s sprint and epic filters use those issue relationships. During execution, Fail + defect brings a failed check into Planner with a linked defect.
Can we estimate and track testing time?+
Yes. A case can have an execution estimate, with its measured average used as a fallback when no estimate is set. Plans and runs aggregate the available estimates. The execution timer records active testing time, supports pauses, and makes measured time available in run reports and case history.
Can AI help create test coverage?+
With a configured AI provider, you can generate suggested test cases from a Planner issue, review the procedures, select the cases to keep, and save them to the project library with their issue link. Generation assists the review; it does not execute the tests or decide release readiness.
Where do environments and test account details live?+
QA has dedicated environment and credential views. Environments store a name, key, base URL, and description, and the selected environment name is captured in the run. Credential metadata includes the account label, role, username, sign-in URL, and notes. Secrets are masked in the list and requested through a separate reveal flow.
leera QAA clear quality story.
A clear quality story.
For every release.
Bring the cases, the checks, and the whole team into one connected workspace.