> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/planning-and-decision-guides/qa-skills-for-agent-assisted-teams.md). # QA Skills for Agent-Assisted Teams Assess requirements judgment, test oracles, evidence, diagnosis, prompt design, tool permissions, and workflow ownership before scaling AI-assisted testing. > **Editorial owner:** ContextQA Documentation · **Last updated:** September 12, 2026 ## Quick answer When coding agents generate more test code, QA capability shifts toward specifying risk, designing trustworthy oracles, controlling data and permissions, validating failures, and reviewing evidence. Automation skill still matters, but “can generate a test” is not the same as “can prove a release decision.” Assess people on a representative task, not self-rated AI fluency. ## Use a capability matrix | Capability | Observable behavior | Risk when missing | | --------------------------- | ---------------------------------------------------------------- | -------------------------------- | | Requirement analysis | Separates decided, proposed, and unresolved behavior | Tests automate assumptions | | Risk selection | Prioritizes business and boundary failures | High test count, weak coverage | | Test oracle design | States precise visible and persisted outcomes | False passes | | Data and environment design | Creates isolated, resettable fixtures | Flaky or destructive tests | | Prompt/context design | Supplies scope, constraints, and evidence needs | Generic or unsafe generation | | Automation literacy | Reviews selectors, waits, fixtures, APIs, and CI behavior | Fragile generated implementation | | Tool and permission control | Separates read, run, change, delete, and release authority | Excessive agent action | | Failure diagnosis | Tests AI hypotheses against screenshots, logs, traces, and state | Misclassified defects | | Evidence review | Reconciles runs, skips, retries, and build identity | Misleading green gates | | Maintenance judgment | Distinguishes locator recovery from changed business intent | Weakened tests | ## Run an observed team exercise Use one user-owned non-production workflow with normal behavior and a reversible seeded defect. Ask each participant or pair to: 1. clarify the requirement and risks; 2. define explicit positive and negative assertions; 3. design isolated data and cleanup; 4. give an agent the bounded task; 5. review the generated test before execution; 6. verify the normal run and seeded failure; 7. diagnose the failure from evidence; 8. produce a release note with unresolved coverage. Score the produced artifacts, decisions, and explanations—not typing speed or prompt vocabulary. ## Choose train, hire, or tool support | Gap | Train when | Hire/contract when | Add tooling when | | --------------------------- | -------------------------------------------------- | ------------------------------------------------ | ---------------------------------------------------------- | | Requirement/oracle judgment | Domain knowledge exists but method is inconsistent | No one owns critical product-risk interpretation | Traceability and review need operational support | | Automation implementation | Team needs focused framework practice | Specialist depth is persistently required | Repetitive maintenance or infrastructure is the constraint | | Data/environment | Ownership exists but reset design is weak | Complex specialist infrastructure is missing | Provisioning and reset can be standardized | | Evidence/triage | Artifacts exist but review is inconsistent | Reliability/observability expertise is absent | Collection and comparison are fragmented | | Agent governance | Team understands risk but lacks policy | Security/AI governance ownership is absent | Permissions and audit controls can enforce decisions | The options can combine. A platform cannot replace missing requirement ownership; a hire cannot fix an inaccessible environment alone. ## Define human review responsibilities Humans should approve: * business-critical assertions and changes to them; * role and tenant expectations; * production-like data access; * acceptance of self-healing or generated repairs; * release-risk exceptions; and * any expansion of agent permissions. Agents can assist with drafts, mapping, execution, and evidence collection within those boundaries. ## Build a 30-day practice plan Choose one capability gap, one weekly fixture, one reviewer, and one observable artifact. Reassess on the same task family after four weeks. Do not promise staffing reduction, salary outcomes, or universal productivity gains from the exercise. ## Frequently asked questions ### Does AI-assisted testing remove the need for QA fundamentals? No. It makes requirement clarity, risk selection, oracle design, test data, permissions, and evidence review more important because weak assumptions can be generated and executed faster. ### How should we assess an agent-assisted QA skill? Use one representative workflow with a reversible seeded failure. Score the requirement interpretation, assertions, data isolation, generated change review, failure detection, diagnosis, and final evidence—not prompt fluency or test count. ### Does every capability gap require hiring? No. Train when domain ownership exists but the method is inconsistent, add tooling when repetitive infrastructure or evidence collection is the constraint, and hire or contract when sustained specialist judgment or ownership is missing. ## Related documentation * [AI Testing Portfolio Lab](/getting-started/ai-testing-portfolio-lab.md) * [Validate a QA Agent Skill](/evaluation-and-governance/qa-agent-skill-validation.md) * [Playwright Test Agents](https://playwright.dev/docs/test-agents) * [Anthropic: Building Effective Agents](https://www.anthropic.com/engineering/building-effective-agents) {% hint style="info" %} [**Assess one team workflow with ContextQA →**](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=qa_skills_agent_assisted) using the same requirements, failure, and evidence rubric for people and tools. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://learning.contextqa.com/planning-and-decision-guides/qa-skills-for-agent-assisted-teams.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.