QA Terminology

Makes a ticket testable before any test case is written. Produces explicit and implied AC statements, a numbered ambiguity list with proposed resolutions, and a Requirement → Risk → Test-idea map. Does not write test cases — use “Test case writing” after clarifying the spec.

Turns a requirement into executable scenarios. Identifies decision points, boundary values, and business rules first, then generates tagged scenarios [P1/P2/P3] with automation candidacy flags [AUTO]. Defaults to Gherkin output; switch to Column-based suite for audit-grade work.

Root-causes an issue via the hypothesis-evidence ladder (ranking causes, citing specific log lines/status codes with confidence levels), then formats a reproducible bug report. Redact guard is on by default.

Produces a QA status update structured as GREEN/AMBER/RED + key numbers + open bugs + blockers + next steps. Under 150 words — written for a PM who scans and a dev who acts. No hedging language.

Produces synthetic, constraint-honouring test data files (CSV, JSON, SQL, XML, Faker.js factory). Locks the Test Data Engineer role and replaces the standard selector panel with a data spec panel: format, quantity, constant/varying fields, and optional edge-case and pairwise generation.

Generates a time-boxed charter applying SFDIPOT, CRUD, and RCRCRC heuristics adversarially. Output is a charter (Mission, Areas to explore, Risks, Test ideas) — not a step-by-step script. Best for new or changed features with unknown risk areas.

Analyses performance or data results against an SLO. Produces: VERDICT (Pass/Fail/Inconclusive), EVIDENCE TABLE (metric/baseline/measured/delta/vs SLO), ROOT CAUSE (citing specific data points), and a RECOMMENDATION. Grounds every claim in provided numbers — never guesses.

Converts a manual scenario to a runnable Playwright TypeScript spec. Uses Arrange-Act-Assert, role/test-id locators, API-seeded state, and web-first assertions. Never emits waitForTimeout calls. For framework-level design (POM, fixtures, config), switch Role → SDET Architect.

Audits a UI component or screen for WCAG 2.2 AA violations. Locks the Accessibility Test Engineer role and a11y coverage. Returns a findings table (WCAG criterion, severity, element, remediation) plus a pass/fail verdict. Paste HTML markup or a detailed component description for best results.

Writes test cases for REST API endpoints covering status codes, payload shape and types, auth, pagination, error envelopes, and idempotency. Validates responses against OpenAPI/JSON Schema. Defaults to column-based suite output.

Validates existing data (migration output, API response, ETL result) for type, range, format, nullability, uniqueness, referential integrity, and business invariants. Adversarial about silent corruption: rounding, timezone, encoding, truncation, duplicates.

Generates test cases for authentication, authorisation (IDOR, broken access control, privilege escalation), input validation (injection, XSS), and session handling against OWASP Top 10. Authorised scope only.

Decides what to automate from a batch of manual test cases. For each case: automate-now / automate-later / keep-manual, correct pyramid layer (unit/component/API/E2E), Rule of Three groupings for data-driven candidates, relative ROI estimate, and specific blockers.

Root-causes intermittent test or CI failures. Applies a hypothesis-evidence ladder over failure logs to identify races, timing issues, shared/leaked state, ordering dependencies, and time/locale sensitivity. Produces specific fixes and a quarantine policy recommendation.

Upstream persona. Extracts explicit and implicit acceptance criteria, converts vague statements into measurable oracles, and produces a numbered ambiguity list plus coverage map. Does not write test cases. Use at the start of any feature or with under-specified tickets.

Applies SFDIPOT, CRUD, boundary, and RCRCRC heuristics adversarially to find defects that scripted tests miss. Generates charters and test ideas, not step-by-step scripts. Best for new/changed features or areas with low automated coverage.

Produces structured, reproducible test cases using equivalence partitioning, BVA, and decision tables. Tags each case with priority [P1/P2/P3] and automation candidacy [AUTO]. Output is precise enough for any tester to execute identically.

The strategist who decides what to automate before code is written. Applies the Rule of Three, scores ROI by Frequency × Stability, assigns the correct pyramid layer per case, and flags blockers. Most under-used and highest-leverage role in the set.

Writes reliable E2E and integration tests in TypeScript. Uses role-based locators (getByRole, getByLabel), web-first auto-retrying assertions, API-seeded state, and Arrange-Act-Assert structure. Never emits waitForTimeout.

Designs the system the tests live in: Page Object Model, typed fixtures, playwright.config.ts (projects, sharding, retries, reporters), auth-state reuse (storageState), CI integration, and flake governance.

Adversarial about data values and structure. Validates type, range, format, nullability, uniqueness, referential integrity, cross-field consistency, and business invariants. Hunts silent corruption: rounding errors, timezone shifts, encoding issues, truncation, duplicates.

Produces synthetic, constraint-honouring, PII-safe, seed-reproducible test data. Builds typed Faker.js factories with override support and deliberately includes edge-case records. Auto-selected by the Data Generator purpose.

Tests the service layer: HTTP status codes, payload shapes, headers, auth, pagination, error envelopes, idempotency, rate limits, and backward compatibility. Enforces contracts via OpenAPI/JSON Schema or consumer-driven contracts (Pact).

Designs load, stress, soak, and spike scenarios with SLOs (p50/p95/p99 latency, throughput, error rate). Scripts in k6. Attributes differences to data volume, query plans, or environment — never guesses.

Tests authentication, authorisation (IDOR, privilege escalation), input validation (injection, XSS), and session handling against OWASP Top 10. Authorised scope only. Routes high-risk findings to the security team.

Evaluates against WCAG 2.2 AA: keyboard operability, visible focus, semantic structure, ARIA name/role/value, colour contrast, text resize and reflow, screen-reader output. Each finding cites the specific WCAG criterion number and remediation.

Root-causes non-deterministic test failures: race conditions, animation/network timing, shared or leaked state, ordering dependencies, time/locale sensitivity. Replaces hard waits with web-first assertions and recommends a quarantine policy.

Turns an observation into an actionable defect report: environment, exact repro steps, expected vs actual, severity/priority, evidence. Isolates a minimal repro, assesses regression scope. Output is something a developer can act on without follow-up questions.

Writes for a mixed audience — developers and a Product Manager. Leads with a release signal (GREEN/AMBER/RED). Precise about numbers, explicit about blockers, no hedging language. Written so the PM can decide and the dev can act immediately.

A numbered list of “Verify/Confirm/Ensure...” statements, each with a trailing [P1/P2/P3] priority tag. 12–18 items. No steps, no expected-result columns, no intro/summary. Lowest effort, lowest traceability. Best for smoke passes, sanity sweeps, and tight deadlines.

Well-formed Gherkin scenarios (Given/When/Then). Uses Scenario Outline + Examples table when the same flow needs multiple data variants. One behaviour per scenario. Readable by non-technical stakeholders and consumable by Cucumber/SpecFlow.

A Markdown table with columns: ID | Title | Requirement Ref | Priority | Preconditions | Steps | Test Data | Expected Result. IDs ascending as TC-<MODULE>-NNN. Expected Result must be observable — never “works correctly.” Imports to Xray/Zephyr/TestRail.

Structured template: Summary, Environment, Severity/Priority, Steps to Reproduce, Expected Result, Actual Result, Evidence, Root Cause Hypothesis table (cause/evidence/confidence), Regression Scope, and optional Fix Direction.

Findings table: ID | WCAG Criterion | Severity (Critical/Major/Minor/Advisory) | Element / Location | Description | Remediation. Followed by a verdict line: Pass / Fail / Needs Manual Verification with counts. Auto-selected by Accessibility Audit.

One column per condition, final columns = expected outcome. One row per unique condition combination. Exposes missing combinations and complex rule interactions. Best for pricing, eligibility, discount, and approval-rule testing.

Columns: Current State | Event | Next State | Expected Action. One row per valid transition. Invalid transitions listed in a separate flagged section. Best for order status machines, payment flows, subscription states.

A single charter: Mission (1 line), Areas to explore (bullets), Risks to watch (bullets), Test ideas (bullets). No step-by-step cases, no closing remarks. Directs a focused, time-boxed exploratory session. Auto-selected by Exploratory Testing.

Table: Requirement ID | Requirement | Test Case IDs | Coverage Status. One row per requirement; flags any requirement with no covering test. Pair with the Requirement IDs context field. Required for sign-off and compliance audit evidence.

A single runnable file — imports, describe/test blocks, setup/teardown, and assertions — in the target framework’s idioms. No prose outside code comments. Auto-selected by Automation (Playwright). Set the Framework context field for Cypress, pytest, k6, or other stacks.

Forces a fixed reasoning order before concluding: restate the problem → classify/isolate the key factors → find gaps → conclude last. Use on complex analytical tasks so you can spot a flawed reasoning step before acting on the answer.

Ranks likely root causes; for each, cites the specific log line, status code, or observed value with a confidence level (Confirmed / Likely / Unconfirmed). Concludes with a verdict, or states “Insufficient evidence.” Auto-selected by Bug Reporting and Flake Triage.

First lists equivalence classes and boundary values per field (min−1 / min / max / max+1 / empty / wrong-type), then generates data rows or test cases from those classes. Ensures coverage is derived from analysis, not intuition. Auto-selected by Data Validation.

Architecture Decision Record style: documents requirements → evaluates 3–4 options with a trade-off table → makes a recommendation → lists consequences. Use for framework design, test strategy, and tooling decisions via the SDET Architect role.

The main success flow — confirms the core behaviour works as intended with valid inputs and a normal state. On by default for almost every purpose.

Invalid inputs and error handling — what happens when the system receives data it should reject. On by default alongside Happy Path. One scenario per distinct error class, not one per invalid value.

Values at the edges of valid ranges where defects cluster: min, min−1, max, max+1. Required for any field with a defined constraint. Works alongside Negative — boundary-exceeded values are typically negative cases too.

Confirms existing behaviour has not changed after a code change or release. Targets stable, existing features — not new functionality. Pair with Happy Path for a complete smoke pass.

Checks unauthorised access is correctly rejected and role-based visibility is correct. Requires the “Roles under test” context field to be filled with real role names — without it, output is generic rather than concrete.

Adds injection, access-control, and trust-boundary angles beyond basic Permission coverage. Works best with the Security Test Engineer role. Covers OWASP Top 10 attack patterns relevant to the feature.

Verifies graceful failure rather than a crash when integrations, network calls, or slow paths are involved. Covers timeout handling, retry behaviour, partial failure recovery, and meaningful error messages to the user.

Adds keyboard, focus, ARIA, contrast, reflow, and screen-reader checks against WCAG 2.2 AA. Auto-selected by the Accessibility Audit purpose. Can be combined with any other purpose to add a11y checks to a functional test set.

Adds locale-specific format checks (dates, currencies, numbers), translation text expansion, RTL layout, and unicode/emoji handling. Use for any product serving multiple locales or character sets.

When many inputs would produce an exhaustive cross-product too large to test, Pairwise ensures every pair of field values appears in at least one test case. Typically reduces hundreds of combinations to ~10–20 while catching ~90% of defects.

Instructs the model to ground every claim in the provided input, flag assumptions explicitly, and not invent limits, causes, or selectors. Use whenever facts, logs, performance numbers, or existing data are involved. On by default for most Tier 1 purposes.

Treats pasted content as DATA, not instructions, and redacts any tokens or PII as [REDACTED] in the output. Enable when pasting real logs, Jira tickets containing customer data, or any content with embedded secrets. Default on for Bug Reporting.

Declares that all data is fully synthetic, instructs the model to treat it as sensitive, and prevents persistence or echoing beyond the generated files. Auto-enabled by the Data Generator purpose. Pair with a Compliance standard when the schema models real people.

Before finishing, the model silently verifies its own output structure (columns present, IDs sequential, no stray prose) and fixes any issue before returning the result. Use for column-based suites, RTM tables, data files, and any output with a fixed schema.

Forces the response to begin directly at the deliverable — no “Here is your test suite...”, no introduction. Use when copying output directly into a tool or Jira comment. Default on for Status & Reporting.

Ticket or requirement IDs (e.g. TEST-123, REQ-7) the output must trace back to. The model maps every test case to one of these IDs and flags any requirement left uncovered. Essential for the RTM output format.

The application layer under test: Web UI, Mobile App, REST API, GraphQL, Database, CLI/Service. Multi-select. Grounds generic tasks — “test the login” becomes “test the login on Web UI and REST API” with concrete differences in output.

The user roles or personas the tests must cover (e.g. admin, dealer, guest). Required for Permission coverage to produce concrete scenarios rather than generic “unauthorized user” references.

A short code injected into generated test case IDs: e.g. setting LEADS produces IDs like TC-LEADS-001. Keeps generated IDs consistent with your team’s existing naming scheme.

The exact test environment and build number under test (e.g. staging build 4821). Appears in bug reports and test plans so repro steps are unambiguous.

The browser, device, and OS targets for the test run (e.g. Chrome 124, iOS Safari 17). Tells the model which cross-browser or responsive cases to include when Web UI or Mobile is selected as a target.

The automation framework for generated code: Playwright (TS), Cypress, Selenium WebDriver, pytest, Postman/Newman, RestAssured, or k6. Overrides the role’s default stack. Required for Runnable spec file output to produce valid syntax.

The test management tool the output should import into cleanly: Xray, Zephyr, TestRail, qTest, or Azure DevOps Test Plans. Adjusts ID formats, column names, and export structure so the output pastes in without reformatting.

How many scenarios to generate (±2 is acceptable). Useful for scoping deliverables. Set to 0 for no constraint. The model prioritises coverage quality over hitting the exact number.

One complete example output in your team’s preferred format. The model mirrors its structure, columns, and tone exactly. The single highest-leverage way to enforce house style — sometimes called “few-shot” prompting.

Two optional fields below the main content textarea: Logs / evidence (stack traces, console output, failing run logs) and Schema / API spec / contract (OpenAPI, JSON Schema, DB schema). Kept in separate typed blocks so the model treats each as evidence rather than instructions.

A free-text field for one-off, situational steers appended to the end of the prompt — e.g. “Also focus on the payment gateway interaction.” Use instead of hand-editing the output panel. Does not affect saved selector state.

Output as comma-separated (CSV) or tab-separated (TSV) rows with a mandatory header row. Best for Excel/import tools. Set Encoding to UTF-8 with BOM for Microsoft Excel compatibility; UTF-8 without BOM otherwise.

Output as a JSON array of record objects, valid per RFC 8259. Best for API fixtures, frontend mocks, and any JavaScript/TypeScript consumer. Financial values emitted as strings to avoid floating-point precision loss.

Output as batched multi-row INSERT statements inside a single transaction. Set the SQL Dialect (PostgreSQL/MySQL/SQL Server/Oracle/SQLite) so escaping, boolean/date literals, and IDENTITY/SEQUENCE resets are dialect-correct.

Output as a well-formed XML 1.0 document with a UTF-8 declaration. Best for structured feeds, EDI documents, and legacy systems. Special characters are escaped; CDATA sections used for content with multiple special characters.

Output as a reusable TypeScript factory module using @faker-js/faker. Supports override parameters per record. Set a Seed value for deterministic, reproducible generation. Best for version-controlled data generation in TypeScript projects.

Fields that must be identical across every generated record (e.g. tenant_id=1001, region=EU). Provide as comma-separated key=value pairs.

Fields that must be unique per record. Add rows with a field name and a type. The type (Email, UUID, Decimal, Date, Boolean, Enum, etc.) injects a format constraint into the prompt so the model generates correctly-shaped values. At least one varying field is required.

An integer that initialises the Faker.js random number generator. Identical seed + identical context = byte-identical output every time. Mandatory for any dataset used in regression or migration testing where reproduced output is needed later.

Adds deliberately invalid and boundary-value records alongside normal records, clearly flagged for negative testing. Includes: MIN/MAX boundary values, empty strings, null variants, max-length overflow, and unicode/emoji/RTL characters.

When several varying fields would produce too many combinations, Pairwise requests all-pairs selection — every pair of field values appears in at least one record, without an exhaustive cross-product. Reduces dataset size while maintaining combination coverage.

Each generated record is linked to a test case: the case ref and intent are written into the record’s comments field. Use when you need traceability between test data and the specific case that consumes it.

An exploratory testing heuristic covering: Structure (what the system is made of), Function (what it does), Data (what it processes), Interfaces (how it communicates), Platform (what it depends on), Operations (how it’s used), Time (timing, sequence, load).

A regression testing heuristic for scoping a risk-based check: Recent (what changed), Core (critical paths), Risky (historically buggy areas), Configuration (settings/feature flags), Repaired (recently fixed bugs), Chronic (known intermittent issues).

A systematic way to ensure coverage of the four fundamental data operations: Create, Read, Update, Delete. Applied during exploratory charters to check that every entity has all four operations covered and their interactions work correctly.

A test design technique generating test cases at the exact edges of valid input ranges where defects cluster: min−1, min, mid-range, max, max+1. Required for every numeric or date/string field with defined constraints.

Divides input data into classes where all values in a class are expected to behave identically. Test one representative value per class rather than every value. Used alongside BVA — partitioning defines the classes, BVA ensures the edges are tested.

An architecture principle: most tests should be fast unit tests, fewer should be integration/API tests, fewest should be slow E2E tests. The Test Automation Analyst role assigns each case to the correct layer and pushes logic down to the cheapest layer that adequately covers it.

If the same sequence of steps appears in 3 or more test cases with only the data changing, it is a data-driven automation candidate — one parameterised test plus a data table, not three separate scripts. The Test Automation Analyst role applies this to identify groupings.

The standard structure for automated test cases: Arrange (set up preconditions via API/fixtures), Act (execute the specific action under test), Assert (verify the observable outcome). Each test must be independently runnable.

Playwright’s auto-retrying assertion API — e.g. expect(locator).toBeVisible(), toHaveText(). Wait and retry until the condition is true or a timeout is reached. The Playwright Automation Engineer role never uses waitForTimeout.

An automation design pattern that encapsulates the selectors and actions for each page or component in a class. Prevents locator duplication, makes tests more readable, and centralises selector maintenance. Owned by the SDET Framework Architect role.

A Playwright feature that saves a browser’s cookie and localStorage state to a JSON file after a one-time login. Subsequent tests load this file instead of repeating the login UI flow, dramatically reducing suite runtime.

Splitting the test suite across multiple parallel workers or CI machines. Configured via the --shard flag. Each shard runs a subset of tests independently, reducing total wall-clock time. Managed by the SDET Framework Architect role.

Behaviour-Driven Development (BDD): tests written as human-readable scenarios (Gherkin) before implementation, shared between dev, QA, and product. Acceptance Test-Driven Development (ATDD): the broader practice of writing acceptance tests first to drive development.

An API testing approach where the consumer service defines what it expects from the provider, and the provider runs those expectations as tests. Pact is the most common implementation. Referenced by the API/Contract Test Engineer role.

Web Content Accessibility Guidelines 2.2, Level AA — the international standard for digital accessibility. Key criteria: 1.3.1 Info and Relationships, 1.4.3 Contrast (Minimum), 2.1.1 Keyboard, 2.4.3 Focus Order, 4.1.2 Name, Role, Value. AA is the minimum legally required level in most jurisdictions.

The Open Web Application Security Project’s ranked list of the ten most critical web application security risks. Referenced by the Security Test Engineer role. Categories include: Injection (SQL, NoSQL, command), Broken Access Control, Broken Authentication, IDOR, XSS, and Security Misconfiguration.

General Data Protection Regulation. When selected as a compliance standard in the Data Generator, the model ensures synthetic data cannot re-identify any individual, consent fields have a realistic distribution, and right-to-erasure scenarios are represented.

California Consumer Privacy Act. Requires a do_not_sell flag independent of GDPR consent. When selected, the model includes California-resident records and realistic CA postal code distribution in generated datasets.

Health Insurance Portability and Accountability Act. When selected, applies Safe Harbor de-identification to all 18 PHI identifiers. Dates generalised to year only. Geographic data limited to 3-digit ZIP prefix. All diagnosis codes must be valid ICD-10 codes from the approved test codeset.

Payment Card Industry Data Security Standard. When selected, uses test BINs only: 4111111111111111 (Visa), 5500005555555559 (MC), 378282246310005 (Amex). CVV always null. Card expiry future-dated.

Service Organization Control 2 — an auditing standard for service providers storing customer data. When selected, the model emphasises access control, data integrity, availability, and confidentiality requirements in generated test cases and validation rules.

Microsoft’s end-to-end browser automation framework for Node.js/TypeScript. The default automation framework in the Composer. Uses role-based locators and web-first auto-retrying assertions. Supports cross-browser (Chrome/Firefox/WebKit), mobile viewports, API testing, and parallel sharding.

A JavaScript end-to-end testing framework that runs directly in the browser. Known for its real-time reload, time-travel debugging, and built-in screenshot/video capture. Select via the Framework context field when the team uses Cypress instead of Playwright.

An open-source load testing tool scripted in JavaScript. Used by the Performance Test Engineer role for load, stress, soak, and spike scenarios. Scripts define virtual users (VUs), ramp-up profiles, thresholds (SLOs), and exported metrics including p50/p95/p99 latency.

Test Management Systems (TMS). When selected via the TMS context field, the Composer adjusts generated output to import cleanly. Xray and Zephyr integrate with Jira; TestRail and qTest are standalone platforms; Azure DevOps Test Plans integrates with Microsoft’s DevOps pipeline.

A specification format for describing REST APIs (request/response schemas, authentication, parameters, status codes). Paste an OpenAPI snippet into the Schema / API spec field to ground API test case generation. The API/Contract Test Engineer role validates responses against the provided spec.