Planning & Decision Guides Overview

Evidence-led guides for evaluating AI testing vendors, architecture, security, operating cost, team readiness, model routing, and workflow fit.

Editorial owner: ContextQA Documentation · Last updated: September 12, 2026

Quick answer

Use this section when the question is not “where is the button?” but “what should our team choose, measure, own, or require?” Each guide produces a concrete decision artifact—a scorecard, cost model, security request, architecture record, or experiment—without assuming ContextQA is automatically the right answer.

Choose the decision you need to make

Decision	Guide	Output
Which vendor deserves a hands-on pilot?	AI testing vendor demo scorecard	Common-task evidence matrix
Which alternative fits our constraints?	Compare AI testing alternatives	Constraint-weighted shortlist
What does testing cost per release?	Test automation cost per release	Buyer-owned cost model and sensitivity range
Should we buy a service, platform, or mixed model?	Testing service or QA platform	Responsibility and transition matrix
Is runtime actually our bottleneck?	Test runtime and release lead time	PR-to-verdict timeline and experiment
What security evidence should we request?	AI testing vendor security evidence	Evidence request and exception register
What is the smallest stack we can operate?	Smallest operable AI testing stack	System-of-record and ownership decision
Can we prove chart and file-export outcomes?	Chart and download assertion evaluation	Automated/manual/unsupported matrix
Which QA capabilities need investment?	QA skills for agent-assisted teams	Observed capability matrix and practice plan
Which event fits our current problem?	Choose a QA conference	Event-format decision worksheet
Which conference claim deserves a follow-up?	Turn a conference demo into an evaluation	Claim log and owned experiment
Can QA context use a model router?	OpenRouter controls for QA context	Endpoint, data, provider, fallback, and budget record
Does an agent task need a workflow graph?	QA agent workflow graph or simple loop	State, approval, retry, and termination design
Does an AI-testing update change a decision?	AI testing change-to-decision log	Verified consequence and guide-update record

How to use these guides

1. Name the decision owner and date.
2. Choose one representative application, service, or workflow.
3. Record the current baseline before changing the tool or process.
4. Separate documented claims, observed results, and unresolved questions.
5. Test a reversible negative path or seeded failure where possible.
6. Retain result IDs and artifacts that another reviewer can inspect.
7. Decide adopt, revise, restrict, defer, or stop.

Do not turn illustrative numbers into ContextQA or customer results. Enter your own workload, currency, rates, permissions, and evidence.

Technical companion guides already in GitBook

The remaining active workbook topics live with the technical workflow they extend. This keeps one authoritative procedure while making every planned topic discoverable.

Reader question	Canonical GitBook guide
Build or buy when the team uses Claude Code and Playwright?	Build vs Buy Analysis
Can we leave with usable tests?	Clean-Environment Portability Test
What evidence should an AI testing pilot produce?	30-Day AI Testing Pilot Scorecard
Can we trust test-impact selection?	PR Impact Analysis Evaluation Ledger
Can we replace or coexist with a browser grid?	Browser-Grid Migration Checklist
Is the CI integration safe to require?	CI Integration Acceptance Runbook
What evidence should an AI-generated PR carry?	Agentic PR Evidence Checklist
Do generated tests represent requirement coverage?	Requirements Coverage Ledger
Did self-healing repair or weaken the test?	Self-Healing Acceptance Experiment
Who may read, run, change, or approve?	Agent Authority Boundaries
Can a dependency graph support a release decision?	Context Provenance and Unresolved Edges
How should we triage overnight failures?	Evidence-First Failure Triage
How do we verify API state and UI behavior together?	API-to-UI Business Workflow
Which tests run when release time is fixed?	Risk-Based Run Plan
Will the deployment fit our identity, network, data, and evidence needs?	Deployment Fit Matrix
How do retries and skipped tests affect the release?	Retry and Skip Release Readout
What should a bug investigation handoff contain?	Support-to-Engineering Handoff
How do prompts produce assertions rather than clicks?	Generation Prompts with Observable Assertions
Can a generated test detect a real failure?	Generated-Test Negative Control
What does an AI testing workflow cost per accepted result?	Cost per Usable Verdict
What happens when a run queues, times out, or loses its result?	Execution Recovery
How do meeting notes become release criteria?	Requirements Handoff
How should test data be scoped and reset?	Resettable Test Data
Why does a test pass locally and fail in staging?	Local-vs-Staging Evidence
How do we test role and tenant boundaries?	Role-and-Tenant Matrix
How should models be compared for QA work?	Model Cost per Usable Verdict
What belongs in a weekly quality review?	Weekly Quality Review
What context should a testing agent receive?	Reviewable Context Pack
How do flaky tests get an owner and restoration gate?	Flaky-Test Ownership
What is the difference between a prompt, skill, and MCP tool?	QA Agent Skill Layers
Which MCP capabilities are actually connected?	Manifest Verification
How do we stop an unbounded repair loop?	Agent Loop Stop Conditions
Is repository context fresh enough for this PR?	Repository Freshness Check
How do we hand off an AI-assisted test change?	Test-Change Handoff
How do we validate a shared QA Agent Skill?	QA Agent Skill Validation
How can a practitioner demonstrate AI testing judgment?	AI Testing Portfolio Lab

Continue to implementation

• New users: Getting Started
• Existing-suite owners: Migration Overview
• Pilot owners: Evaluation & Governance
• AI-agent integrators: MCP Server Overview
• Technical operators: Browse by Role

Add future website companions without duplication

When a website article is added later:

1. Give it a distinct buyer question and narrative rather than copying this guide.
2. Summarize the decision and link to the exact GitBook worksheet, checklist, or protocol.
3. Keep product setup and version-sensitive instructions in GitBook.
4. Link back from the GitBook guide only when the public website article adds unique comparison, customer, or market context.
5. Use a self-referencing canonical for each genuinely distinct page; consolidate pages that answer the same intent.

This lets the website attract and qualify demand while the documentation carries the detailed proof path.

Frequently asked questions

Should a team use every decision guide?

No. Start with the decision currently blocking adoption, renewal, architecture, or release confidence. Complete its evidence artifact, name an owner, and move to another guide only when it addresses a separate unresolved decision.

Are these pages ContextQA vendor rankings?

No. They are buyer-owned evaluation methods. Use the same representative workflow, evidence requirements, constraints, and stop conditions for ContextQA and every alternative so the result remains explainable to engineering, security, procurement, and finance.

How should these guides be kept current?

Revalidate a guide when a product capability, integration, provider policy, framework version, or operating assumption materially changes. Update the existing authoritative page when the search intent is unchanged; create a new page only for a genuinely different decision.

Bring the decision, not a generic feature list. Book a scoped technical evaluation → with one representative workflow and the evidence your reviewers require.