> 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/enterprise-application-testing/ship/workflows.md).
# Run Ship Workflows
Run Ship workflows for live application crawling, code and pull-request analysis, bug reproduction, regression creation, CI/CD, and AI handoffs.
> **Documentation owner:** [Deep Barot](https://contextqa.com/academy/) · **Last updated:** November 11, 2026
## Quick answer
Ship starts from a signal—an application crawl, code change, reported bug, or observed anomaly—and turns it into a bounded quality workflow. The durable output is not only a pass or fail. It is the source signal, execution scope, evidence, likely cause, regression coverage, and reviewer decision.
## Key takeaways
* Ship starts from a signal—an application crawl, code change, reported bug, or observed anomaly—and turns it into a bounded quality workflow.
* Use a crawl to establish an initial product map when a reachable test application is available.
* Code analysis gives Ship approved repository context for test generation and later change-impact analysis.
{% hint style="info" %}
**Watch the workflow:** [See Ship catch a checkout regression before merge](https://www.youtube.com/watch?v=ZNkGHT1NHfI\&utm_source=learning.contextqa.com\&utm_medium=docs_referral\&utm_campaign=contextqa_product_education\&utm_content=ship_workflows_pr_regression), then use the evidence checklist below to evaluate the result.
{% endhint %}
## Start with an application crawl
Use a crawl to establish an initial product map when a reachable test application is available.
1. Open **Autonomous SDLC → Crawl**.
2. Confirm the target environment and test identity.
3. Start a new crawl or review the onboarding crawl.
4. Watch the AQE Terminal for current activity.
5. Review test candidates as they appear while generation continues.
6. Wait for a terminal result before evaluating coverage.
7. Review generated modules, journeys, requirements, priorities, and tests.
8. Strengthen assertions and add missing roles, states, and negative paths.
During an active crawl, generated candidates can appear in the requirement while the remaining work continues. Approval and rejection controls stay unavailable while generation is in progress, preventing an incomplete batch from being mistaken for a final result.
**Use case:** A team can establish a shared, reviewable starting point for a product whose coverage previously lived in manual knowledge or disconnected scripts.
## Analyze a repository
Code analysis gives Ship approved repository context for test generation and later change-impact analysis.
1. Authorize GitHub or GitLab with the narrowest suitable repository scope.
2. Confirm the repository, default branch, deployed application, and organization boundary.
3. Start code analysis and retain its analysis identity and status.
4. Compare discovered areas and flows with requirements and existing tests.
5. Add missing business context from tickets, designs, documentation, or recordings.
6. Review generated candidates before adding them to shared regression coverage.
Code analysis does not approve a pull request, merge code, or prove every behaviour in the application.
[Watch AI find broken tests in a repository](https://www.youtube.com/watch?v=LzeaPAg8e1U\&utm_source=learning.contextqa.com\&utm_medium=docs_referral\&utm_campaign=contextqa_product_education\&utm_content=ship_workflows_repository_analysis) for a visual example of this workflow.
## Carry a test plan into CI/CD
The test plan **CI / CD** view provides the plan ID, scoped token setup, and **Open setup guide** for provider-specific configuration. Follow the current [CI/CD release gate guide](/integrations-and-developer-tools/integrations/ci-cd-release-gates.md).
1. Open a test plan that has already passed a controlled manual execution.
2. Choose the target environment and, for mobile work, the approved build source.
3. Open **Open setup guide** and follow the current instructions for your pipeline provider.
4. Store the ContextQA credential in the provider's protected secret store; never paste it into the workflow file.
5. Validate trigger, polling, timeout, cancellation, and failing-test behaviour on a non-protected branch.
6. Add the verified check to branch or deployment protection.
Provider configuration is a starting point. A reviewer remains responsible for repository variables, protected environments, build paths, retry policy, and the exact release rule.
## Check a pull request against product behaviour
```mermaid
flowchart LR
A[Pull request] --> B[Map files and affected flows]
B --> C[Select relevant existing and candidate tests]
C --> D[Run targeted regressions]
D --> E[Preserve results, video, trace, and logs]
E --> F{Evidence complete?}
F -->|Yes| G[Reviewer records the decision]
F -->|No| H[Run broader coverage or investigate]
```
Before relying on the result, verify the target deployment, environment, data revision, selected tests, and run outcome. A partial analysis, zero-test result, failed analysis, or missing execution evidence is not a passing release signal.
## Reproduce and investigate a reported bug
When a connected Jira, Linear, Slack, or service-desk report is eligible:
1. Preserve the original report, environment, timestamp, and reporter-observed outcome.
2. Identify missing prerequisites, data, identity, and stopping conditions.
3. Reproduce the behaviour in an approved environment.
4. Capture steps, screenshots or video, console and network evidence, and trace when available.
5. Distinguish product behaviour from test, data, environment, dependency, or access failures.
6. Present the likely root cause and suggested next action as a reviewable hypothesis.
7. Create a regression case when the defect is confirmed and rerun it after the fix.
From a run result, use **Report issue** to create a tracker item or **Issues** to link an existing one. The issues view keeps the tracker status, linked tests, and run context together. Removing a link does not delete the external issue.
For short examples, watch Ship [reproduce a bug reported in Slack](https://www.youtube.com/watch?v=ZbSI9EtDi90\&utm_source=learning.contextqa.com\&utm_medium=docs_referral\&utm_campaign=contextqa_product_education\&utm_content=ship_workflows_slack_bug) or [investigate a bug from Linear](https://www.youtube.com/watch?v=2V3ptXa7qg8\&utm_source=learning.contextqa.com\&utm_medium=docs_referral\&utm_campaign=contextqa_product_education\&utm_content=ship_workflows_linear_bug).
Execution evidence connects a verdict to the steps, environment, video, trace, console, and network record that produced it.
## Validate API behaviour, not only status codes
For API steps, combine a status assertion with payload checks. Current match options include exact comparisons, **Contains**, and **Matches regex**; the available expected-value types change with the selected match type.
For a payment or order response, validate business-significant values such as amount precision, currency, identifier format, timestamp shape, and state. Then deliberately use a malformed or missing value and confirm the test fails for the intended reason.
See [Validating API responses](/enterprise-application-testing/api-testing/validating-responses.md) for the complete workflow.
## Use production signals safely
For eligible captured application activity, use the loop:
**Observe → identify an anomaly → reproduce in a controlled environment → review evidence → create a regression test → add it to the appropriate suite.**
Observed activity does not establish complete coverage across every user, role, browser, route, state, or business risk.
## Hand verified context to an AI coding agent
MCP lets an engineer ask Ship for focused quality context from an existing AI client. Keep the handoff small:
* Failed outcome and affected workflow
* Reproduction steps
* Relevant logs, trace, screenshots, or video reference
* Likely cause and its confidence or limitations
* Regression case and rerun status
Do not include secrets, unrelated source code, customer data, or unsupported conclusions in the prompt.
## Evidence checklist
* **Source:** change, defect report, session, requirement, crawl, or recording
* **Scope:** repository or application boundary, branch, environment, identity, and data revision
* **Analysis:** affected flows, selected tests, confidence, limitations, and fallback decision
* **Execution:** run identity, trigger, target, timestamps, status counts, and reruns
* **Investigation:** first meaningful failure, reproduction steps, logs, trace, screenshots, or video
* **Outcome:** confirmed defect, test or environment issue, suggested action, regression case, and verified rerun
* **Governance:** reviewer, approval, exception, release decision, and audit reference
For operating boundaries, see [Operate Ship safely](/enterprise-application-testing/ship/security-and-controls.md).
## Complete how-to guides
Use [the AI software factory guide](/enterprise-application-testing/ship/ai-software-factory.md) to connect these workflows. Follow [testing AI-generated code](/enterprise-application-testing/ship/testing-ai-generated-code.md) for commit-specific verification, [release readiness](/enterprise-application-testing/ship/release-readiness.md) for sign-off, and [quarterly release testing](/enterprise-application-testing/ship/quarterly-release-testing.md) for larger release windows. Configure [auth profiles](/enterprise-application-testing/ship/auth-profiles.md) to make the application identity explicit.
---
# 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/enterprise-application-testing/ship/workflows.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.
