For the complete documentation index, see llms.txt. This page is also available as Markdown.

Specialized Quality Gates

Add performance, accessibility, visual, security, compatibility, and export checks to a functional ContextQA release workflow.

Business problem: A functionally correct release can still be too slow, inaccessible, visually broken, insecure, or incompatible with the environments customers use.

Start with a stable functional journey, then add the quality gate that represents a real service objective or customer risk. Availability and execution infrastructure can vary by plan, deployment, and integration; confirm the required capability in the target workspace before making it release-blocking.

Performance and load

Use a representative test flow or API target as the scenario for a controlled performance run. The MCP execute_performance_test capability accepts a virtual-user count, duration, and ramp-up and returns a live result reference with response-time percentiles, error rate, and throughput.

Define the pass criteria before running:

  • target environment and approved load window;

  • representative data and authentication behavior;

  • concurrency and ramp profile;

  • response-time percentile objectives;

  • maximum error rate;

  • backend or third-party rate limits;

  • abort criteria and an owner monitoring the environment.

Do not aim production-scale traffic at an environment without authorization. A load result is meaningful only when environment capacity, data, caches, and dependent services resemble the decision being made.

Accessibility

Combine explicit keyboard, focus, label, role, contrast, error-message, and screen-reader expectations with an accessibility-oriented custom agent where appropriate. Automated observations help find repeatable issues, but they do not replace assistive-technology testing or expert review for high-impact journeys.

Use the applicable organizational standard—such as a specified WCAG conformance target—and preserve the violated expectation, page state, element context, and evidence with each finding.

Visual and responsive behavior

Capture consistent screenshots at named checkpoints across the supported browser and viewport matrix. Compare the current result with an approved baseline when a comparison workflow is enabled, and review differences caused by content, fonts, animation, test data, or rendering before filing a defect.

Useful visual gates include:

  • clipped or overlapping content;

  • missing controls, icons, or images;

  • responsive navigation and breakpoint behavior;

  • Salesforce or other dynamic-layout regressions;

  • generated document previews;

  • critical brand, legal, or localization content.

Keep data, locale, viewport, browser version, and animation state stable so the comparison measures the product rather than test noise.

Security scanning

The MCP execute_security_dast_scan capability can launch a configured dynamic scan against flows exercised by a test case. Use a standard profile in an approved CI or test environment and reserve more aggressive scans for a dedicated window.

Treat scanner results as findings to validate. Record the affected flow, evidence, severity, owner, and remediation status. Do not scan an application or third-party system without explicit authorization.

Browser, device, and environment compatibility

Build the matrix from supported-user and risk data. Run the same suite across required browsers, responsive viewports, mobile devices, and environment profiles, while isolating data that cannot safely execute in parallel.

For every difference, determine whether it is a product issue, browser or device limitation, provider dependency, environment configuration, or unstable test data.

Export and portability

Where teams need code ownership or a transition path, export supported cases to an approved automation framework and store the generated output with its dependencies and execution instructions. Validate the exported test in the target runner; platform evidence, self-healing, variables, and integrations may not map one-for-one to standalone code.

Success measures

  • Releases evaluated against explicit functional and non-functional objectives

  • Performance results tied to an authorized, representative environment

  • Accessibility defects found before release and verified after remediation

  • Visual differences reviewed with stable baselines and low noise

  • Security findings validated and owned

  • Supported browser, device, and viewport coverage based on customer usage

  • Exported tests that run successfully in the intended target framework

Last updated

Was this helpful?