Test Management

QualityMax organizes work as projects containing test cases, with automation scripts and executions linked to the intent they verify. Preserve that traceability when importing an existing test-management catalog or moving browser tests from another framework.

Migration paths

For each migration, keep the source system available until counts, steps, expected results, automation links, and a representative execution have been reconciled. Use core concepts for the underlying data model.

Project instructions for preview and staging URLs

Open Project → Settings → Agent instructions to give your coding agent a project-specific workflow for deployments whose domains change. Use Copy prompt for a one-time handoff, Copy skill for the full instructions, or Download SKILL.md to install them in your repository. The prompt includes your project ID; replace <PASTE_PREVIEW_URL> with the deployment you want tested.

The downloaded skill shows installation paths for Codex (.agents/skills/qualitymax-preview-<project-id>/SKILL.md) and Claude Code (.claude/skills/qualitymax-preview-<project-id>/SKILL.md). It requires your existing QualityMax MCP connection. Refresh it when project settings change.

Agents can retrieve the same instructions directly through MCP:

{
  "tool": "get_project_agent_instructions",
  "arguments": {
    "project_id": 42,
    "workflow": "preview-testing"
  }
}

Replace 42 with your project ID. The tool is available in the core tool profile and accepts the read-only OAuth scope. get_test_capabilities also includes a discovery hint for it. Its response contains prompt, skill_markdown, installation_paths, a deterministic revision, and allowlisted saved project facts. Native mobile projects return available: false because this workflow tests web deployments.

For OAuth connections, mcp:read permits retrieving these instructions. Executing the workflow requires mcp:write for run_tests and for update_script when edits are authorized. A read-only connection can retrieve the handoff but needs a connection with mcp:write before executing tests or changing scripts. OAuth scopes do not replace user authorization or project access checks.

For API clients, GET /api/projects/{project_id}/agent-instructions?workflow=preview-testing returns the same content with success: true. It requires project access and does not change settings, create tests, or start executions. Responses use Cache-Control: private, no-store.

The workflow uses run_tests.base_url to select a deployment for saved scripts while leaving the project’s default URL unchanged. This override does not rewrite hardcoded URLs inside test code. Agents must check script portability, deployment identity, access, and the actual tested origin, then report execution IDs and real test counts. trigger_framework_run currently has no per-run URL override; test_deployed_environment creates new tests rather than rerunning a saved suite.

Application login profiles and Vercel Deployment Protection are separate access requirements. Do not place credentials or protection bypass tokens in prompts, skills, test code, or URLs. An enabled preview gate or an integration test ping alone does not prove a real deployment was tested. See execution tools for runner parameters and result inspection.