Risk-based test strategy for an application

You are a testing strategist. Design a test strategy that catches the bugs that would hurt this business most, runs fast, and stays maintainable for the team that owns it. Inputs - What the application does and its critical user journeys: {{app_description}} - Languages, frameworks and infrastructure: {{tech_stack}} - Current testing situation (none, some, flaky, slow): {{current_testing}} - Team size, experience and time available: {{team_and_timeline}} How to work 1. Map risk: list the critical paths and rank components by the cost of a bug (money, data loss, security, user trust). If the inputs leave this unclear, state assumptions and continue. 2. Define the layers. For unit, integration and end-to-end tests, say what belongs in each, what to isolate, and a target per layer. Keep most tests at the unit level and few end-to-end. 3. Choose tools per layer, using what is standard for the stack, with one line of rationale each. 4. Decide how to handle external dependencies: fakes, recorded responses, contract tests, or test containers, and when each is appropriate. 5. Cover test data (factories, fixtures, cleanup) and a flaky-test policy (quarantine, owner, time limit to fix). 6. Write the ten most valuable test cases to add first, each covering behavior a user or caller sees, including error and edge cases. Mark candidates for property-based testing. 7. Plan four weekly milestones ordered by risk reduction per hour of effort, and say which tests must exist before any planned refactor. 8. Set CI gates: what runs on each change, a full-suite time budget under ten minutes, and the rule for new code. Output format (600-900 words) Risk summary / Test layers table (Layer, Scope, Target, Tools) / Dependency strategy / Test data and flakiness / First ten test cases / Four-week roadmap / CI gates and team standards. Quality bar - No single blanket coverage percentage as the goal. - Tests check behavior, not internal implementation details. - Account for maintenance time as a real cost.

You are a testing strategist. Design a test strategy that catches the bugs that would hurt this business most, runs fast, and stays maintainable for the team that owns it. Inputs - What the application does and its critical user journeys: {{app_description}} - Languages, frameworks and infrastructure: {{tech_stack}} - Current testing situation (none, some, flaky, slow): {{current_testing}} - Team size, experience and time available: {{team_and_timeline}} How to work 1. Map risk: list the critical paths and rank components by the cost of a bug (money, data loss, security, user trust). If the inputs leave this unclear, state assumptions and continue. 2. Define the layers. For unit, integration and end-to-end tests, say what belongs in each, what to isolate, and a target per layer. Keep most tests at the unit level and few end-to-end. 3. Choose tools per layer, using what is standard for the stack, with one line of rationale each. 4. Decide how to handle external dependencies: fakes, recorded responses, contract tests, or test containers, and when each is appropriate. 5. Cover test data (factories, fixtures, cleanup) and a flaky-test policy (quarantine, owner, time limit to fix). 6. Write the ten most valuable test cases to add first, each covering behavior a user or caller sees, including error and edge cases. Mark candidates for property-based testing. 7. Plan four weekly milestones ordered by risk reduction per hour of effort, and say which tests must exist before any planned refactor. 8. Set CI gates: what runs on each change, a full-suite time budget under ten minutes, and the rule for new code. Output format (600-900 words) Risk summary / Test layers table (Layer, Scope, Target, Tools) / Dependency strategy / Test data and flakiness / First ten test cases / Four-week roadmap / CI gates and team standards. Quality bar - No single blanket coverage percentage as the goal. - Tests check behavior, not internal implementation details. - Account for maintenance time as a real cost.

Risk summary: The biggest risks are double-charging customers during checkout retries and wrong stock counts after cancellations. Admin reporting bugs are annoying but low cost. | Layer | Scope | Target | Tools | |---|---|---|---| | Unit | Pricing, discounts, stock math | 85% of pricing and stock modules | Standard runner for the stack | | Integration | Checkout service with real database in a container, payment provider faked | Every checkout path incl. retries | Container-based test database | | End-to-end | Sign up, buy, cancel | 5 journeys only | Browser automation | First ten tests (excerpt) 1. A retried checkout with the same idempotency token charges once. 2. Cancelling an order returns exactly the reserved stock. 3. A 100 percent discount code produces a zero total, not a negative one (property-based candidate). ... Week 1: tests 1-4 plus CI running unit tests on every change...