> 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/requirements-to-release.md).

# Requirements to Release

## Quick answer

Turn requirements, tickets, spreadsheets, designs, videos, and natural-language workflows into reviewed, traceable ContextQA tests. 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:** Product intent lives in tickets, documents, spreadsheets, designs, and demo recordings. QA must translate it into test coverage quickly without losing traceability or skipping negative scenarios.
{% endhint %}

ContextQA can use several forms of source material to create a test baseline. The workflow is most effective when the source remains linked to the generated cases, the AI can ask clarifying questions, and a human approves the result before it becomes a release gate.

![ContextQA Requirements Library showing uploaded requirements, generation status, and linked test-case counts](/files/MibWbCUx4YRxVaw25l0g)

## Supported starting points

| Source                                        | Typical business use                                            | Review focus                                                                    |
| --------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------- |
| Plain-English description                     | A known user journey or a newly discovered regression           | URLs, setup state, user role, and explicit expected results                     |
| PRD, BRD, FRD, PDF, DOCX, TXT, or spreadsheet | Formal requirements and legacy manual test libraries            | Requirement boundaries, field rules, omitted error states, and duplicated cases |
| Jira or another connected work item           | Sprint stories, acceptance criteria, and bug reproduction       | Ticket scope, linked work, priority, and traceability                           |
| Image, wireframe, or Figma design             | UI behavior that is designed before implementation              | Intended navigation, state changes, accessibility, and responsive behavior      |
| Video walkthrough                             | A complex workflow best demonstrated by a subject-matter expert | Hidden prerequisites, pauses, data dependencies, and implied assertions         |
| OpenAPI or API definition                     | Contract and integration coverage                               | Authentication, status codes, schema, boundary values, and chaining             |

## Recommended workflow

### 1. Define the release question

Write the business outcome before uploading the source. For example: “A returning customer can renew a subscription using a saved payment method, and a declined payment leaves the original subscription unchanged.” This gives the generated tests a clear end state and includes a meaningful failure case.

### 2. Add context

Upload the primary requirement and any useful visual context. Select the target platform—web, mobile, or API—and choose the test types you need: positive, negative, edge, field validation, boundary, functional, or end-to-end.

For large legacy libraries, import a representative spreadsheet first. Verify the column mapping, parameterization, tags, and expected results before processing the rest of the library.

### 3. Resolve ambiguity

Answer AI clarification questions with concrete rules. Confirm user roles, environment, starting state, acceptable values, integrations, cleanup behavior, and what should happen when a dependency fails. If the answer is not yet known, record the gap with the product owner rather than allowing the test to invent policy.

### 4. Generate and review

Use **Required Approval** when a QA owner must review generated coverage. Check that each test has:

* one clear business purpose;
* the correct prerequisite and starting URL;
* explicit assertions, not only navigation steps;
* safe parameters instead of embedded credentials or personal data;
* tags or links that preserve feature, ticket, and release traceability;
* negative and edge cases that reflect the real cost of failure.

### 5. Organize and execute

Place approved cases in a feature suite and a test plan. Run a focused smoke set first, then the broader regression plan. Use the first execution to identify missing data, unstable environments, or requirements that cannot yet be verified.

### 6. Keep the source and coverage current

When requirements or code change, review linked tests and impacted areas. AI Insights can crawl an authorized application on a schedule to maintain application context and reveal new pages or flows that may need coverage.

See [AI Insights](/ai-features/ai-insights.md) for the current setup screen, scheduling fields, and journey-report workflow.

## Example: subscription renewal

**Inputs:** a Jira story, checkout wireframes, payment API specification, and a short product walkthrough.

**Generated coverage to expect:**

* successful renewal with a saved payment method;
* declined card and expired card behavior;
* displayed price, taxes, term, and confirmation details;
* API response and persisted subscription state;
* duplicate-submit protection;
* email confirmation, when the test environment exposes a safe way to verify it.

**Business value:** Product, QA, and engineering share the same release contract. Reviewers can see which acceptance criteria are automated, which gaps remain, and which evidence supports the release decision.

## Success measures

* Lead time from requirement approval to reviewed automated cases
* Acceptance criteria with at least one linked test
* Generated cases accepted, edited, or rejected during review
* Escaped defects caused by a missing requirement or missing negative case
* Reuse of imported test data, prerequisites, and steps across later features

## Related documentation

* [Creating test cases](/web-testing/creating-test-cases.md)
* [AI test generation](/ai-features/ai-test-generation.md)
* [Requirements management](/web-testing/requirements-management.md)
* [Generate tests from requirements tutorial](/ai-features/generate-tests-from-requirements-tutorial.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/requirements-to-release.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.