> 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/business-use-cases/connected-delivery-workflows.md).

# Connected Delivery Workflows

## Quick answer

Connect ContextQA requirements, tests, CI/CD execution, notifications, defects, reports, and AI agents across the delivery lifecycle. Use this page to connect the business problem to a supported ContextQA workflow, its expected value, and its operating considerations.

## What this page covers

{% hint style="info" %}
**Business problem:** Test automation creates less value when requirements, build gates, failures, and owners remain disconnected across product and engineering tools.
{% endhint %}

ContextQA can connect authoring and execution to issue trackers, source workflows, CI/CD, notifications, and MCP-compatible agents. Choose integrations by the decision they support, then keep the detailed execution evidence in ContextQA as the source of truth.

## Reference flow

1. A product story or requirement becomes the traceable source for generated test cases.
2. QA reviews and approves the positive, negative, boundary, and end-to-end coverage.
3. The cases are organized into suites and a release plan.
4. CI/CD triggers the appropriate plan for a pull request, deployment, or release candidate.
5. ContextQA executes and returns status to the pipeline.
6. A concise result is sent to the team channel; the full report retains step, screenshot, video, console, network, and trace evidence.
7. A confirmed product defect becomes a linked work item with the relevant reproduction context.
8. Trend, flakiness, root-cause, and coverage views guide the next release decision.

## Integration patterns

| Need                      | Pattern                                                                | Design note                                                              |
| ------------------------- | ---------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Requirements traceability | Generate from Jira or another supported source and preserve links/tags | Keep one owner for ambiguous acceptance criteria                         |
| Pull-request feedback     | Trigger a smoke or impacted-test plan from CI/CD                       | Set a timeout and an explicit policy for infrastructure failures         |
| Release regression        | Schedule or manually start a broader plan                              | Freeze environment and test-data assumptions for the run                 |
| Team awareness            | Send a summary to Slack or another approved channel                    | Include status, scope, failure count, owner, and report link—not secrets |
| Defect handoff            | Create a ticket after evidence review                                  | Avoid filing duplicate tickets for test-data or environment failures     |
| Agent-assisted QA         | Use MCP tools to create, execute, and analyze tests                    | Restrict credentials and permissions to the minimum required scope       |

## Build-gate policy

Define how the pipeline handles each result:

* **Passed:** continue when the required scope completed and all blocking assertions passed.
* **Product failure:** block or require an explicit release exception.
* **Test failure or flake:** quarantine only with an owner, evidence, and review date.
* **Environment or infrastructure failure:** do not label the product as defective; retry or escalate according to the service policy.
* **Timed out or incomplete:** treat as unknown, not passed.

Keep smoke gates fast and deterministic. Run deeper, longer, or integration-heavy coverage at the appropriate release stage.

## Cross-channel and agentic workflows

Applications may span chat, email, Slack, WhatsApp, voice, or third-party agents. Coverage is integration-dependent. Define a proof-of-concept contract for each channel: input, identity, expected action, observable outcome, timeout, fallback, and human-escalation behavior.

For an agent workflow, verify both the user-facing response and the action trail: tools invoked, API or record result, authorization boundary, refusal behavior, and audit history. Do not assume that a passing conversational response proves the downstream action occurred.

## Success measures

* Stories or acceptance criteria linked to approved automated tests
* Deployments evaluated by an appropriate automated plan
* Failed gates assigned to the correct owner from available evidence
* Time from confirmed failure to a reproducible defect ticket
* Duplicate or low-quality automated defects
* Test and result access granted with least privilege
* Agent actions with a verifiable downstream outcome and audit trail

## Related documentation

* [Integrations overview](/integrations/integrations.md)
* [GitHub Actions](/integrations/github-actions.md)
* [Jira integration](/integrations/jira.md)
* [Slack integration](/integrations/slack.md)
* [MCP Server overview](/mcp-server/overview.md)
* [Reporting overview](/reporting/reporting.md)


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learning.contextqa.com/business-use-cases/connected-delivery-workflows.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
