Before it ships,
prove it works.

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.

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.

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.

Yes, for everyone with a role in the run’s project. A run opens on its Overview, which shows the whole run: each case’s status, who is working on it, the progress of automated cases, and the evidence each attempt recorded. Use the Test cases tab to record your testing. Opening a case does not mark it as in progress; a tester presses Start testing (or Retest on a case that already has a result), or begins marking steps, attaching evidence, or writing notes on a case waiting for a result. Other viewers see the change without reloading the page. Presence is separate from results: an idle or disconnected tester never passes, fails, or skips a case, and a retest is kept as a separate attempt.

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.

Completing a run marks any remaining pending cases as skipped, and issued test reports list them as not run. The report keeps passed, failed, blocked, and skipped outcomes distinct, so unfinished coverage is not counted as a successful check. The pass rate counts only cases with a verdict: passed ÷ (passed + failed). A completed run is read-only. A member who can manage the project’s test cases can reopen it with a reason, which is recorded with the run, and a corrected result keeps the one it replaced.

Yes. When a run is complete, a member who can manage the project’s test cases can create a numbered test report with a verdict (accept, accept with reservations, or reject), a summary, and optional reviewers and approvers chosen from the project’s members. Its copy of the run’s results is frozen when the report is created, before review. Reviewers sign before approvers, and each can send the report back with a comment instead. The report is issued after all required sign-offs, or immediately if no reviewers or approvers are named. Each sign-off records the person’s name, the time, and what the signature means. Download the report as PDF, Excel, CSV, JUnit XML, or JSON; until it is issued, the PDF carries a draft watermark. Create a new version with a note on what changed; it supersedes the previously issued version only when the new version is issued. Type a report’s number, such as RPT-20-3, in a document, issue, or comment and it becomes a link to the report showing its title and where it stands; people outside the project see only the number. Sign-off is recorded in Leera; the PDF itself is not digitally signed.

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.

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.

With a configured provider, Leera AI can suggest test cases from a Planner issue for you to review, select, and save with their issue link. An external AI tool connected over MCP can also create and update cases with the required QA scopes. Generating a case does not execute it or decide release readiness; your team checks the coverage and recorded evidence.

Keep the requirement and its acceptance criteria in a Planner issue, link the cases that verify it, and select release coverage in a plan. An AI tool connected through MCP can create cases and record results within its granted access. Review the procedures and evidence, follow linked defects, and rerun the affected checks after a fix. A completed issue is not a substitute for a recorded test result.

Supported MCP tools can read a case’s steps, validate and save an automation script, list runner pools, and queue automated items from a test run. Scripts are checked against the case’s steps before saving. Execution depends on the configured runners, enabled platforms, environment, and granted scopes. Items without a script remain pending for a person; scripts that use stored sign-in credentials also require QA secrets access.

QA has dedicated environment, credential, test data, and test file views. Environments store a name, key, base URL, and description, and the selected environment name is captured in the run. For automation, an environment can also hold an API base URL and the domain used for generated e-mail addresses. Each environment is marked test or production; new environments start as test. Automated cases marked as changing data do not run on production environments or on environments nobody has marked yet, while read-only cases still run. Leera does not inspect scripts to decide this, so mark every case that creates, changes, or deletes data. Credential metadata includes the account label, role, username, sign-in URL, and notes. An account can also hold a fixed one-time code for apps with two-step sign-in. Secrets are masked in the list and requested through a separate reveal flow.

Yes, when the app under test accepts a fixed one-time code for chosen test accounts on its test environments. Store that code with the account’s QA credential: it is encrypted like the password, masked in the list, and shown only through the reveal flow. Automation scripts type it with {{credential.otp}}, and the runner redacts it from step notes and debug logs. Automation does not read codes sent by e-mail, text message, or an authenticator app, and jobs that type the code need an up-to-date runner. Make sure your production environment never accepts the fixed code.

Yes. A case can declare test data references: names for records that already exist in the system under test, such as an overdue customer. Each reference holds a value for each environment, or one for any environment, made of plain text fields. A run uses the environment’s own value first and falls back to the value for any environment only on environments marked test. When queueing automation, a person can choose which of the two values the run uses; a chosen value is used on any environment, including production. Testers see the resolved values on the run item and can refresh them while the item is pending and no automated job for it is queued or running, and automation scripts read them with placeholders such as {{data.overdue_customer.id}}. Values are visible to project members and are not a place for passwords. References do not create, reset, or remove data, and automated jobs that read test data need an up-to-date runner.

Yes. A project keeps its test files in one place: uploaded files, such as an invoice PDF or a CSV import, and generated files described by a file name, a size of up to 2 GB, and zeros or random bytes, for size-limit, empty-file and corrupt-file checks. Generated files are not stored; they are written where they are used. A case declares the files it needs, and testers download them from the run item. Automation scripts hand a file to the app with an upload action and a placeholder such as {{file.invoice_pdf}}: into a web page’s file input, through the file chooser a button opens, or onto a drop zone. A test data field can name the file, so each environment can use its own. Scripts only hand over the project’s test files, never a path on the runner machine. Files are visible to project members, so keep real customer files out, and automated jobs that upload files need an up-to-date runner.