# For Engineering Managers {% hint style="info" %} **Who is this for?** Engineering Managers, Dev Leads, and Technical Leads responsible for engineering productivity, CI/CD pipelines, and the balance between velocity and quality. {% endhint %} Your team ships fast. The question is whether quality keeps up. Every escaped regression costs more to fix than it would have taken to catch — and every slow CI pipeline taxes developer productivity. ContextQA gives you AI-powered quality gates that run in parallel, heal themselves, and integrate with the toolchain your engineers already use. *** ## The Engineering Manager Dashboard Key metrics available in ContextQA: | Metric | Why It Matters | | ------------------------------ | ----------------------------------------------------- | | **Test execution time** | Is your CI pipeline fast enough to run on every PR? | | **Pass rate by feature team** | Which team is shipping the most regressions? | | **Self-healing rate** | How much manual maintenance would AI have required? | | **MTTD (Mean Time to Detect)** | How quickly are failures caught after a commit? | | **Flaky test count** | Flakiness = false CI failures = developer frustration | | **Coverage gaps** | Untested code paths that are risk vectors | *** ## CI/CD Integration ContextQA plugs into any CI/CD system as a quality gate. The pattern is consistent across all platforms: 1. **Trigger** — `GET /api/test-plans/{id}/execute` (returns a `testPlanResultId`) 2. **Poll** — `GET /api/test-plan-results/{id}` every 15s until `STATUS_COMPLETED` 3. **Gate** — check `failedCount == 0` before proceeding to deploy **Execution performance with parallelism:** * 50 test cases: \~4 minutes with `parallelNode: 5` * 200 test cases: \~8 minutes with `parallelNode: 10` * Per-browser multiplication: Chrome + Firefox + Safari = 3× coverage, same wall time CI/CD integrations available: | Platform | Guide | | -------------- | ---------------------------------------------------- | | GitHub Actions | [Integration Guide](/integrations/github-actions.md) | | Jenkins | [Integration Guide](/integrations/jenkins.md) | | GitLab CI | [Integration Guide](/integrations/gitlab-ci.md) | | CircleCI | [Integration Guide](/integrations/circleci.md) | | Azure DevOps | [Integration Guide](/integrations/azure-devops.md) | *** ## Team Scalability ### Multi-Team Workspace Organization Organize test suites by team or feature area: * `team-payments/` — owned by the payments team * `team-auth/` — owned by the auth team * `team-mobile/` — owned by the mobile team Each team maintains their own suite. The Release Gate Test Plan aggregates them for release qualification. ### Role-Based Access | Role | Typical Assignment | | ------- | ----------------------------------------- | | Admin | EM, QA Lead | | Manager | Senior QA, Tech Lead | | Tester | QA Engineers, developers with test duties | | Viewer | Product, stakeholders | → [Roles & Permissions](/administration/roles-and-permissions.md) ### SSO Integration Connect to your company's identity provider for centralized access management: * **SAML 2.0** — Okta, Azure AD, Google Workspace, OneLogin * **OAuth 2.0** — GitHub, Google Engineer onboarding and offboarding handled through your existing IdP — no separate ContextQA account management. → [SSO & Authentication](/administration/sso-and-authentication.md) *** ## Reducing Engineering Toil ### AI Self-Healing: Quantified Every time a UI element changes and the AI heals a test automatically: * **Without ContextQA**: An engineer spends 20–60 minutes investigating the failure, updating the selector, re-running the test * **With ContextQA**: Zero engineer time for heals with confidence ≥ 90% At scale across a large test suite, self-healing represents hundreds of engineer-hours saved per quarter. → [AI Self-Healing](/web-testing/self-healing.md) ### MCP Server: Testing Infrastructure as Code Give your engineers an AI-native testing interface. Any AI coding assistant (Claude, Cursor, GPT-4 with MCP plugin) can: * Generate test cases from requirements or Jira tickets * Execute test plans and retrieve results * Get AI root cause analysis for failures * Create defect tickets in Jira This means testing becomes a native part of the AI-assisted development workflow — not a separate tool context switch. → [MCP Server Overview](/mcp-server/overview.md) *** ## Quality Gates: Recommended Configuration ### For Every Commit (PR Check) * **Suite**: Smoke Tests (10–20 critical path tests) * **Parallel**: `parallelNode: 5` * **Target time**: < 3 minutes * **Gate**: Block merge if any smoke test fails ### For Every Merge to Main (Pre-Deploy) * **Suite**: Feature regression (tests for everything changed this sprint) * **Parallel**: `parallelNode: 10` * **Target time**: 8–12 minutes * **Gate**: Block deploy if > 2 failures ### Nightly Regression * **Suite**: Full regression * **Environments**: staging + production-replica * **Notification**: Slack channel `#qa-alerts` * **Review**: QA Manager reviews failures before standup *** ## Incident Response and Debugging When a production incident occurs, use ContextQA to: 1. **Run a targeted test plan** against the affected feature area immediately 2. **Review evidence** — screenshots, HAR logs, console errors per test step 3. **Get AI root cause** — classify the failure: application regression, infrastructure issue, or environment problem 4. **Compare with last green run** — did this test pass before the latest deploy? The full evidence package (video, HAR, trace) accelerates post-incident analysis and reduces MTTR. → [Failure Analysis](/reporting/failure-analysis.md) *** ## Onboarding Engineers to ContextQA Estimated onboarding time by role: | Engineer Type | Onboarding Path | Time | | ---------------------- | --------------------------------------------------------------------------------------------------------- | ------ | | New to automation | [Quickstart](/getting-started/quickstart.md) + [Creating Test Cases](/web-testing/creating-test-cases.md) | 1 hour | | Experienced tester | [Test Plans](/execution/running-tests.md) + [Environments](/execution/environments.md) | 30 min | | SDET / API integration | [MCP Server](/mcp-server/installation-and-setup.md) + [Tool Reference](/mcp-server/tool-reference.md) | 1 hour | | CI/CD owner | [GitHub Actions](/integrations/github-actions.md) or [Jenkins](/integrations/jenkins.md) | 30 min | *** {% hint style="success" %} **Recommended path for Engineering Managers:** 1. [Parallel Execution](/execution/parallel-execution.md) — configure CI speed 2. [Environments](/execution/environments.md) — set up staging/production configurations 3. [Roles & Permissions](/administration/roles-and-permissions.md) — configure team access 4. [SSO & Authentication](/administration/sso-and-authentication.md) — connect your IdP 5. [Analytics Dashboard](/reporting/analytics-dashboard.md) — measure quality metrics {% endhint %} *** {% hint style="info" %} **See how ContextQA fits into your engineering stack.** [**Book an Engineering Demo →**](https://contextqa.com/book-a-demo/) — A technical walkthrough covering CI/CD integration, parallelism configuration, and MCP tooling for your team. *Engineering teams using ContextQA ship 3× more releases per quarter without increasing QA headcount.* {% endhint %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://learning.contextqa.com/documentation-by-role/by-role/for-engineering-managers.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.