Qase Test Management

Call any Qase REST endpoint directly, for the few things no dedicated tool covers. Pass the HTTP method, a path starting with /v1/, and an optional body or query. See developers.qase.io for the reference. Prefer a dedicated tool wherever one exists: they normalize enums, validate arguments before spending a round trip, and shape the response for a model. This one hands back whatever the API returns. It sends JSON only and cannot upload files — multipart uploads go through qase_attachment_upload. A DELETE through this tool asks for confirmation the same way the dedicated delete tools do. Cost: one API call, typically 0.3-1.5s depending on the endpoint. No caching, no pagination help, no retries beyond the client defaults.

Upload a file and get back the hash that other tools reference it by — screenshots, logs, HAR files, videos. Pass `file_base64` with the base64-encoded bytes, or `file_path` with an absolute path; `filename` with its extension is always required. Use `file_base64` unless the server runs on the same machine as the file: a remote server, the hosted connector included, cannot see your filesystem, and `file_path` will simply not find the file. The returned hash is what goes in the `attachments` field of qase_case_upsert, qase_result_record, qase_defect_upsert or qase_triage_defect — uploading alone attaches nothing, the hash has to be passed on. This is the only tool that sends multipart/form-data, which is why qase_api cannot send them. Upload once and reuse the hash rather than re-uploading the same evidence per case. Cost: one API call per file, dominated by file size rather than round trip — well under a second for a screenshot, seconds for a video. Base64 inflates the payload by about a third.

Create or update a single test case. With `id` it updates that case, without `id` it creates a new one. Enum fields (priority, severity, type, layer, behavior, automation) accept either a label such as "high" or "blocker" or the project's numeric ID — the server normalizes both. Steps can be classic action/expected pairs or Gherkin, and may reference shared steps by hash. Writing more than one case? Use qase_case_bulk_create instead: it takes a list and sends one request. If the project has "Test case review" enabled, direct writes may need to go through a review — run qase_discover_tools with "review" for those tools. Cost: one API call, about 0.6s to create and 0.4s to update. Ten sequential calls measured 5.6s against 1.2s for one qase_case_bulk_create writing the same ten, so a loop is roughly four times slower.

Report a whole CI run in one call: creates the run, records every result, and completes it. This is the tool for a pipeline that has just finished — it replaces qase_run_upsert, then qase_result_record, then qase_run_complete, and leaves no half-open run behind if the agent stops early. Each result needs a numeric `case_id` plus a status, and may carry duration, comment, stacktrace and attachment hashes. Use qase_result_record instead when the run already exists and results arrive in stages; use qase_run_upsert when you need the run left open. A batch larger than 200 is split across requests for you, up to 2000 results in one report. Cost: one tool call covering three API operations, plus one extra request per 200 results. A run with two results measured about 0.7s, against roughly 1.5s for the same work as three separate calls, and it grows with the number of results rather than with the number of round trips.

Create or update a defect — a tracked problem found by testing. Without `id` it creates, with `id` it updates. Creating one requires `title`, `actual_result` and `severity`; the API rejects a defect missing any of the three. Severity is given as a label ("blocker", "critical", "major", "normal", "minor", "trivial") and the server maps it to the workspace's numeric ID, custom options included. Status is a label too ("open", "in_progress", "resolved", "invalid") and passes through as written; setting it to "resolved" on an existing defect goes through the dedicated resolve endpoint. When the defect comes from a specific test failure, use qase_triage_defect instead. The API has no way to attach runs or results to a defect, so reference the failing results in the text rather than expecting a link. Find existing defects with qql_search before filing a duplicate. Cost: one API call, about 0.5s, plus a cached lookup of the severity options.

Find and switch on tools that are hidden by default. Only core tools appear in the tool list; deletes, shared steps and parameters, attachments, external issue links, case reviews, defect triage, and project and custom-field management all exist but stay hidden until discovered. Search by what you are trying to do — "delete", "milestone", "attachment", "review", "custom field" — and matching tools are activated and become callable. Every word in the query must appear in a tool's name or description, so prefer two or three words over a sentence. Never conclude a capability is missing without searching here first. Cost: no API call, matching happens in memory, about 3ms. Free to call as often as needed.

Fetch one known record by type and ID: case, suite, run, result, plan, defect, milestone, environment, shared_step, shared_parameter, configuration, attachment, author, user, review, or custom_field. `code` is required for project-scoped entities and can be omitted for global ones (user, author, attachment, custom_field). Narrow the payload with `fields`, or pass ["*"] for everything. Use this only when you already know the ID and want a single record. For several records, for anything filtered or cross-project, or when you are about to call this in a loop, use qql_search instead — one search returns the whole page at once. Cost: one API call, 0.3-0.5s. Ten of these in sequence measured 5.3s against 1.2s for a single qql_search returning the same ten records, so a loop over IDs is roughly four times slower and ten times more calls.

Seed everything about a project in one call: project details, the full suite tree, milestones, environments, custom fields, and users. This is the first call to make when starting work on a project — it replaces six separate list calls and gives the model the metadata it needs to build any later query. Each collection returns its first 100 entities; the `coverage` field reports { total, loaded, truncated } per collection, so check it before assuming a list is complete, and pass `full: true` to page through everything. For a single record you already have the ID for, qase_get is cheaper; for filtered or cross-project questions, use qql_search. Cost: six API calls behind one tool call, 0.5-1.3s cold, and 16-48KB of response depending on project size. Cached for 5 minutes, so repeat calls inside that window return in about 5ms. `full: true` costs one extra call per 100 entities and can return thousands of items.

Build and start a test run from a suite, a test plan, or an explicit list of case IDs, in one step. Use it to launch a regression cycle without first querying for cases and then creating a run around them — give it the source and it resolves the cases itself. For a run you assemble by hand, use qase_run_upsert and pass the case IDs. For a pipeline that has already finished and just needs its results filed, use qase_ci_report instead: this tool opens a run, it does not close one. Cost: two API calls behind one tool call — resolving the source, then creating the run — roughly 1s, growing with the number of cases the source resolves to.

Record up to 200 results into an existing run. A case says what should be tested; a result says what happened when it ran — status, duration, comment, stacktrace, attachments — so a result always needs a run to live in. Pass several results in one call rather than calling once per test: the tool takes a list and sends them together. 200 is the ceiling for one call, and a longer list is refused before anything is written — split it into consecutive calls rather than dropping the tail. If the run does not exist yet and this is a finished CI job, qase_ci_report is the single call that creates the run, records the results and completes it, and it splits a larger batch for you. Status is a label, one of "passed", "failed", "blocked", "skipped" or "invalid" — unlike the case enums, numeric IDs are not accepted here. Cost: one API call for the whole list, about 0.5s for a small batch, growing with payload rather than with the number of results.

Create or update a test run. Without `id` it opens a new run; with `id` it updates that one. A run is the container results are recorded into, so open it before calling qase_result_record. Optionally scope it to a milestone, an environment, a plan, or an explicit list of case IDs. To build a run from a suite or plan without listing cases yourself, use qase_regression_run. For a CI job that has already finished, use qase_ci_report instead — it opens the run, files the results and closes it in one call, so no half-finished run is left behind. Cost: one API call, about 0.5s.

Create a defect from a test failure, with the failure context written into it. Requires title, actual_result and severity — the API rejects a defect missing any of the three. Note: the API offers no way to attach existing runs or results to a defect. The runs and results seen on a defect in the UI are populated by the test runner when it reports a result as a defect, so there is nothing to pass here for that — reference the failing results inside actual_result instead, and do not expect a link to appear. For a defect unrelated to a test failure use qase_defect_upsert. Cost: one API call, about 0.5s. Triaging a whole run means one call per defect, so cluster identical failures and file one defect per distinct cause rather than one per failed test.

Read the QQL reference before writing a query. Pass a `topic`: overview, syntax, entities, operators, functions, examples, aggregation, or enumValues. `entities` lists the fields each entity actually exposes, and `enumValues` gives the accepted values for status, priority, severity and the rest — both matter, because QQL rejects a query naming an attribute that does not exist on the entity rather than ignoring it, and the field names differ from those in the write tools. Read this once per session before the first qql_search rather than guessing and retrying. Cost: no API call, static text, about 2ms. Free to call, and cheaper than one rejected query.

Search any entity with Qase Query Language: filtering, cross-project queries, sorting, and aggregation. This is the right tool for every question that is not "give me this one record by ID" — "cases without automation", "results that failed this week", "open blockers across projects" — and the right way to fetch many records at once instead of looping over qase_get. Call qql_help first for the syntax, the fields available per entity, and the enum values; a query naming an unknown attribute is rejected outright. Use qase_get instead when you already know the entity and its ID and want just that one. Cost: one API call. 0.5-0.9s for pages up to 50 records; a page of 100 measured 0.9-2.8s depending on how much each record carries. Prefer one search over N single fetches: the same ten records cost 1.2s here against 5.3s as ten qase_get calls.