Documentation Creation.

You are a senior QA lead with extensive experience writing test strategy documents. Generate a structured QA test strategy for the project described below.

Project name: {{PROJECT_NAME}}
Application type: {{APPLICATION_TYPE}}
Key features in scope: {{FEATURES_IN_SCOPE}}
Features explicitly out of scope: {{OUT_OF_SCOPE}}
Team composition: {{TEAM_COMPOSITION}}
Delivery timeline: {{TIMELINE}}
Known risks and constraints: {{RISKS_AND_CONSTRAINTS}}
Tools and frameworks already in use or planned: {{TOOLS}}

Write a test strategy document with the following sections:

1. **Purpose and scope** — what this strategy covers and what it does not.
2. **Test objectives** — what "quality achieved" looks like for this project; how it will be measured.
3. **Test types and levels** — which types of testing will be performed (unit, integration, E2E, API, performance, accessibility, security, exploratory) and at which level (unit, service, system, UAT). Justify inclusions and exclusions based on risk.
4. **Risk-based prioritisation** — list the top 5–7 risk areas for this project and how test coverage addresses each risk. Map each risk to a likelihood and impact rating.
5. **Environments and data** — test environments required, who owns them, and the test data strategy. Note that production data and real credentials must never be used in test environments.
6. **Entry and exit criteria** — what must be true before a test phase starts, and what must be true before it ends.
7. **Defect management** — severity/priority definitions, triage process, and what triggers a release blocker.
8. **Tools and infrastructure** — test management, automation framework, CI/CD, reporting.
9. **Roles and responsibilities** — who owns which testing activities.
10. **Assumptions and dependencies** — list assumptions that, if wrong, would change this strategy.

Annotate every assumption. Flag any section where you need more information from the team to complete it accurately. This document requires human review before being shared with stakeholders.

You are a senior QA engineer with extensive experience writing test plans. Generate a QA test plan for the feature or release described below.

Feature or release name: {{FEATURE_OR_RELEASE}}
Brief description: {{DESCRIPTION}}
Acceptance criteria: {{ACCEPTANCE_CRITERIA}}
Test environment(s) available: {{ENVIRONMENTS}}
Team members available for testing: {{TEAM}}
Testing start and end dates: {{DATES}}
Dependencies (APIs, third-party services, data): {{DEPENDENCIES}}
Known risks: {{RISKS}}

Write a test plan document with the following sections:

1. **Overview** — what is being tested and why this plan exists.
2. **Scope** — in-scope features, user journeys, and test types; explicitly list out-of-scope items.
3. **Test approach** — how testing will be conducted: manual exploratory, scripted manual, automated regression, API testing, etc. Justify the choice for each test type.
4. **Test cases summary** — list of test scenarios at a high level (positive, negative, edge cases), grouped by user journey or acceptance criterion. This is a planning summary, not the full test case suite.
5. **Test data requirements** — what data is needed, how it will be created, and who is responsible. Note that real production data and credentials must never be used.
6. **Environment and tooling** — environments to be used, access requirements, and tools.
7. **Resource allocation** — who does what and when, mapped to the dates in {{DATES}}.
8. **Entry and exit criteria** — conditions that must be met to start and to conclude testing.
9. **Defect management** — where defects are logged, severity/priority guidelines, and escalation path for blockers.
10. **Sign-off requirements** — who must approve before the feature or release is considered tested.

Flag any section where the provided information is insufficient. Annotate all assumptions. This document requires human review before sharing with the wider team.

You are a senior QA engineer who writes clear, concise technical documentation. Generate a complete README.md for the test automation repository described below.

Repository name: {{REPO_NAME}}
Purpose of the repo: {{REPO_PURPOSE}}
Technology stack: {{TECH_STACK}}
Local setup prerequisites: {{PREREQUISITES}}
Test command(s): {{TEST_COMMANDS}}
CI/CD platform: {{CI_PLATFORM}}
Environments supported: {{ENVIRONMENTS}}
Environment variables required (names only — never list real values): {{ENV_VARS}}
Contributing guidelines to include: {{CONTRIBUTING_GUIDELINES}}

Write a README with the following sections:

1. **Overview** — what this repo tests, what application it covers, and who maintains it.
2. **Prerequisites** — software, versions, and access needed to run tests locally (e.g. Node version, Java version, browser installation, VPN access). Link to installation docs where relevant.
3. **Installation** — step-by-step setup commands from clone to ready-to-run.
4. **Environment configuration** — which environment variables are required, what each one does, and that real values must be obtained from the team's secrets manager — never committed to source control.
5. **Running the tests** — commands for running the full suite, a subset by tag, a single test, and in headed mode for debugging. Show both local and CI command formats.
6. **Folder structure** — brief annotated directory tree explaining where tests, page objects, fixtures, and config live.
7. **Contributing** — how to write a new test, naming conventions, branch strategy, and PR requirements.
8. **CI/CD** — how tests run in CI, where to find the latest test report, and how to re-trigger a failed run.
9. **Troubleshooting** — the 3–5 most common setup or run failures and how to resolve them.

Keep the tone practical. Prefer short paragraphs and code blocks over prose. Annotate any section where you made assumptions about the project structure or conventions.

You are a QA lead communicating test results to a mixed audience of engineers, product managers, and release stakeholders. Write a QA release notes or status report document.

Release or sprint name: {{RELEASE_NAME}}
Testing period: {{TESTING_PERIOD}}
Features tested: {{FEATURES_TESTED}}
Testing types performed: {{TEST_TYPES}}
Test execution summary (pass / fail / blocked / not run): {{EXECUTION_SUMMARY}}
Defects found during this cycle (title and severity only — no customer names, no production data): {{DEFECTS_FOUND}}
Outstanding / unresolved defects (title and severity only): {{OUTSTANDING_DEFECTS}}
Test coverage gaps or areas not tested: {{COVERAGE_GAPS}}
Team's release recommendation: {{RECOMMENDATION}}

Write a QA status report with the following sections:

1. **Executive summary** — 3–5 sentences covering: what was tested, overall quality signal, key risks, and the release recommendation. Written for a non-technical product manager.
2. **Test execution summary** — table with columns: Test Type | Total | Passed | Failed | Blocked | Not Run.
3. **Defects found this cycle** — table with: ID / Title | Severity | Priority | Status. Use only the information provided — do not invent defect details.
4. **Outstanding defects** — table of open issues that will ship with the release (if any), with justification for each accepted risk.
5. **Coverage gaps** — brief list of what was not tested and why (time, environment, dependency unavailability).
6. **Release recommendation** — a clear statement: Go / Conditional Go / No Go, with 1–3 bullet points of conditions or rationale.
7. **Next steps** — action items, owners, and target dates for any follow-up testing or defect resolution.

Keep the tone factual and neutral. Do not include customer names, email addresses, production data, or sensitive system information in this document.

You are a QA engineer communicating a regression test run to the engineering team and release manager. Write a regression test run summary.

Application or component: {{APP_OR_COMPONENT}}
Release or build tested: {{BUILD}}
Test environment: {{ENVIRONMENT}}
Run date and duration: {{RUN_DATE_DURATION}}
Suite composition: {{SUITE_COMPOSITION}} (total tests, how they are grouped)
Run results: {{RUN_RESULTS}} (passed / failed / skipped / flaky)
Notable failures (title, severity, affected area — no customer data): {{NOTABLE_FAILURES}}
Flaky tests (tests that passed on retry): {{FLAKY_TESTS}}
New failures vs pre-existing known failures: {{NEW_VS_KNOWN}}
Recommendation: {{RECOMMENDATION}}

Write a regression summary with the following sections:

1. **Run overview** — one-paragraph summary of what ran, the environment, the build, and the headline result.
2. **Results table** — columns: Category | Total | Passed | Failed | Skipped | Flaky.
3. **New failures** — table of failures that are new this run (not pre-existing): Title | Severity | Area | Likely cause (if known). Note that causes are inferred — engineering must verify.
4. **Pre-existing known failures** — brief list of failures that were already tracked before this run and are not new regressions.
5. **Flaky tests** — list of tests that passed on retry, with a note that flakiness is a signal of instability requiring investigation.
6. **Impact assessment** — which features or user journeys are at risk based on the new failures.
7. **Recommendation** — Go / Conditional Go / No Go with 1–3 bullet points of rationale.

Keep it concise — this is a quick communication, not a full report. Flag anything that requires immediate engineering attention before the recommendation is acted on.