Hands-on: Full test strategy for a feature

How to Turn a User Story into a Complete AI-Generated Test Strategy?

This is the hands-on session where everything from Module 3 comes together. You will take a single, realistic user story and walk through the full test strategy generation process using AI — from the raw story to a complete, team-ready strategy document.

The goal is not to produce a perfect document on the first pass. The goal is to develop a repeatable workflow you can apply to every significant feature you test. By the end of this session, you should be able to generate a draft test strategy for a sprint feature in under 45 minutes, with a quality level that matches what previously took several hours of manual analysis.

The Practice Feature: User Account Subscription Management

Throughout this hands-on topic, we'll use a single realistic feature as our working example. This feature is complex enough to demonstrate all the strategy components without being so large it obscures the process.

User Story:

As a registered user, I want to upgrade my subscription tier from Basic to Pro, 
so that I can access premium features including advanced analytics, priority support, 
and increased API rate limits.

Acceptance Criteria:
1. Users on the Basic tier can initiate an upgrade from their Account Settings page
2. The upgrade flow displays the Pro tier features and the price difference before confirmation
3. Users must provide or confirm a valid payment method before completing the upgrade
4. Upon successful payment, the user's tier is immediately updated to Pro and premium features become accessible
5. The user receives a confirmation email with the upgrade details and new billing date
6. If payment fails, the user's tier remains Basic and an appropriate error message is displayed
7. Users can cancel the upgrade flow at any point before final confirmation without being charged

Tech context: React frontend, Node.js/Express backend, PostgreSQL database, Stripe for payments, SendGrid for email, Redis for session/caching, REST API.

Step 1: Initial Story Assessment

Before generating any strategy, spend 60 seconds reading the story and noting your instincts: what concerns you, what's missing, what's likely to be complicated. This mental priming helps you evaluate whether the AI output aligns with your professional judgment.

Your initial instincts on this story might be:
- Payment processing is always high risk
- The Stripe webhook for payment confirmation creates timing sensitivity
- "Immediately updated" — how is this guaranteed if there's network latency?
- What happens to in-progress sessions when the tier changes?
- The confirmation email mentions a "new billing date" — how is this calculated?

Now generate the strategy with these concerns in mind.

The Master Test Strategy Generation Prompt

This is the core prompt that initializes the full strategy generation. It's intentionally comprehensive — you are asking AI to draft the entire strategy in one pass, which you will then refine section by section.

Prompt:

You are a senior QA engineer generating a complete test strategy for a feature going into sprint testing.

USER STORY:
As a registered user, I want to upgrade my subscription tier from Basic to Pro, so that I can access premium features including advanced analytics, priority support, and increased API rate limits.

ACCEPTANCE CRITERIA:
1. Users on the Basic tier can initiate an upgrade from their Account Settings page
2. The upgrade flow displays the Pro tier features and the price difference before confirmation
3. Users must provide or confirm a valid payment method before completing the upgrade
4. Upon successful payment, the user's tier is immediately updated to Pro and premium features become accessible
5. The user receives a confirmation email with the upgrade details and new billing date
6. If payment fails, the user's tier remains Basic and an appropriate error message is displayed
7. Users can cancel the upgrade flow at any point before final confirmation without being charged

TECH STACK: React frontend, Node.js/Express backend, PostgreSQL database, Stripe for payments, SendGrid for email, Redis for session/caching, REST API.

SPRINT CONTEXT: 2-week sprint, 1 QA engineer (me), approximately 20 hours of QA capacity.

Generate a complete test strategy covering:

SECTION 1 — RISK ASSESSMENT
- List the top 7 risk areas for this feature
- For each: risk description, likelihood (H/M/L), impact (H/M/L), risk score (likelihood × impact, scale 1-9)
- Sort by risk score descending

SECTION 2 — TEST SCOPE
- In-scope: new feature coverage, regression areas affected by this change
- Out-of-scope: what we're explicitly not testing this sprint
- Accepted risks: what we're knowingly not covering and why

SECTION 3 — COVERAGE GOALS
- Functional coverage: list every behavior that must have test coverage
- Path coverage: key execution paths and state transitions
- Boundary coverage: input constraints requiring boundary testing
- Non-functional coverage: performance, security, accessibility, error handling

SECTION 4 — TEST LEVEL MAPPING
- For each coverage goal area, specify: Unit / API / E2E / Manual / Exploratory (or combination)
- Rationale for each level selection

SECTION 5 — ENTRY AND EXIT CRITERIA
- Entry criteria: what must be true before QA begins
- Exit criteria: what must be true before QA sign-off
- Critical path scenarios that must pass without exception

SECTION 6 — TEST SCENARIO CATALOG
- Happy path scenarios (numbered)
- Negative path and error scenarios (numbered)
- Edge cases and boundary conditions (numbered)
- Security-relevant scenarios (numbered)
- Total count by category

Be specific and technical. Reference the tech stack where relevant (e.g., "Stripe webhook delivery failure", "Redis session state during tier upgrade").

This single prompt, applied to the practice feature, typically produces a 1,500-2,500 word strategy draft. The next step is reviewing and refining each section.

Learning Tip: The master prompt is designed to generate a complete first draft, not a final document. Expect 70-80% of the output to be directly usable, with 20-30% requiring refinement based on your domain knowledge. The goal is to avoid starting from a blank page — starting from a comprehensive draft cuts strategy time by 60-70% even accounting for the review work.

How to Generate Risk Assessment, Coverage Goals, and Test Level Mapping in One Session?

With the master strategy draft in hand, you now have a conversation thread you can use to deepen any section. This section walks through the refinement workflow for the three most analytically intensive parts of the strategy: risk assessment, coverage goals, and test level mapping.

Deepening the Risk Assessment

The master prompt generates a risk assessment list. Now probe the high-risk areas for specific test scenarios.

Prompt:

From the risk assessment above, the top 3 risks are:
1. Payment processing failure and partial state
2. Stripe webhook delivery timing and idempotency
3. Tier-based access control enforcement after upgrade

For each of these risks, generate:
- The specific defect scenario this risk describes (what would actually go wrong?)
- Three test scenarios that would expose this defect if it existed
- The test level at which each scenario should be executed (unit, API, E2E, manual)
- What test data or system state is required to execute each scenario

Be specific to our tech stack: Stripe for payments, PostgreSQL for tier data, Redis for session state, React for the frontend upgrade flow.

For the subscription upgrade example, a well-executed version of this prompt produces concrete, immediately actionable test scenarios like:

• "When Stripe's webhook for payment_intent.succeeded is delayed by more than 10 seconds, does the user's session see their old tier or new tier when they navigate to the analytics page immediately after confirmation?"
• "When the PostgreSQL UPDATE to the user's tier_id commits but the Redis session cache is not invalidated, what tier does the API return for subsequent requests within the same session?"

These are the kinds of scenarios that come directly from implementation knowledge — and they're the scenarios most likely to cause production incidents.

Expanding Coverage Goals with Boundary Analysis

The master prompt provides coverage goal categories. Expand the boundary coverage section specifically, as this is most often underspecified.

Prompt:

For the subscription upgrade feature, generate comprehensive boundary value coverage goals:

1. For each input field in the upgrade flow (payment form, any quantity fields, promo/discount codes if applicable), specify:
   - The valid range or constraint
   - The specific boundary test values (at-boundary, just-outside-boundary)
   - The expected behavior at each boundary

2. For the tier transition itself:
   - What if a user on Basic initiates upgrade but is already mid-billing-cycle? (billing date calculation boundary)
   - What if the price difference calculation results in a zero or negative charge? (amount boundary)
   - What if the user has an existing failed payment in their Stripe account? (payment state boundary)

3. For time-sensitive operations:
   - What is the expected behavior if the upgrade is initiated within the last hour of the billing cycle?
   - What is the session timeout behavior during a long upgrade flow?

For each boundary, provide: boundary description, specific test value(s), expected system behavior, and recommended test level.

Generating the Test Level Mapping Table

Extract the test level mapping into a clean, reviewable table.

Prompt:

Based on the coverage goals and risk assessment above, generate a test level mapping table for the subscription upgrade feature.

Format as a markdown table with columns:
| Scenario Area | Specific Behavior | Unit | API | E2E | Manual | Exploratory | Priority |

Fill in each cell with: Y (should cover), N (not appropriate), or OPTIONAL (good to have).

Rationale rules to apply:
- Unit: pure logic, calculations, validation functions — no external dependencies
- API: service-to-service behavior, database state changes, authentication/authorization, Stripe integration
- E2E: complete user journeys requiring browser interaction and multiple system components
- Manual: new UI flows, UX assessment, complex test data setup, high-maintenance automation scenarios
- Exploratory: new feature areas, implicit requirements, unknown unknowns

Include a totals row at the bottom showing the count of scenarios per test level.

Iterative Refinement: Probing for What AI Missed

After the first full draft, probe for the scenarios that are hardest to think of — concurrent actions, webhook race conditions, and cross-system state inconsistencies.

Prompt:

Review the test strategy we've built so far. What scenarios are we most likely to regret not testing?

Specifically, probe for:
1. Concurrency: what happens if two upgrade requests are submitted simultaneously for the same user? (double-charging risk)
2. Partial failure states: what database and cache states would be left if the upgrade process fails at each step — after payment succeeds but before database update, after database update but before cache invalidation, after cache invalidation but before email send?
3. Rollback and idempotency: if the user refreshes mid-flow, or presses back after payment authorization, what state does the system enter?
4. Downstream impact: what parts of the product consume the user's tier level? Are there services or features that cache tier data and won't immediately reflect the upgrade?

For each scenario you identify, add it to the test scenario catalog with its risk level and recommended test level.

Learning Tip: The most valuable refinement prompt is always "what are we most likely to regret not testing?" This question directs AI toward production-incident-type scenarios — the ones that feel obvious in hindsight but aren't listed in any requirements document. Ask this question after every major strategy generation session. The scenarios it surfaces are typically the highest-value additions to your test catalog.

How to Review and Refine AI-Generated Test Strategy for Team Sign-Off?

A test strategy is only valuable if the team commits to it. Getting team sign-off requires the strategy to pass a review process that validates it against technical reality, business priorities, and capacity constraints.

The Self-Review Checklist

Before sharing the strategy with the team, run a self-review pass:

For each risk area:
- Does this risk match my understanding of the implementation? (If the developer took a different approach than the spec implied, some risks may be incorrect)
- Is the risk score calibrated correctly, or was AI overly conservative or optimistic?
- Are the specific test scenarios technically accurate for our stack?

For coverage goals:
- Does the functional coverage list include everything in the AC? (Cross-reference manually)
- Are the boundary conditions specific to our actual constraints, not generic examples?
- Is the non-functional coverage aligned with our team's actual standards?

For test level mapping:
- Are there E2E tests on this list that could be API tests? (Check for over-testing at the E2E level)
- Are there API tests that need unit test coverage first? (Check for layer gaps)
- Is the manual test list realistic for our capacity?

Use AI to run this review:

Prompt:

Review this test strategy for quality issues:

[Paste the full generated test strategy]

Check for:
1. Risk assessment quality: Are any risk scores obviously miscalibrated? Are there risk areas that seem generic (not specific to this feature)?
2. Coverage goal completeness: Does the functional coverage list include all 7 acceptance criteria explicitly? Are any AC items missing from the coverage map?
3. Test level appropriateness: Are any scenarios assigned to E2E that could be handled by API tests? Are there gaps at the unit or API layer that would be caught before an E2E test fails?
4. Capacity realism: Given 20 hours of QA time, is this strategy achievable? What should be cut if capacity is tight?
5. Missing scenarios: Based on the risk assessment, are there notable scenarios absent from the test scenario catalog?

Produce a review report with specific improvements for each issue found.

Preparing the Strategy for Team Review

The full strategy document is appropriate for a QA peer or engineering lead. For a product owner or sprint review, a condensed version is more effective.

Prompt:

Condense this full test strategy into a 1-page team review summary:

[Paste full strategy]

The summary should include:
1. Feature: name and one-sentence description
2. Risk level: overall rating (Critical/High/Medium) with one-sentence rationale
3. Key risk areas: top 3, named plainly
4. What we will test (bulleted, non-technical language)
5. What we will not test (with brief risk rationale — important for product owner awareness)
6. Test types planned (simple list: manual exploration, API testing, E2E automation)
7. Entry/exit criteria summary: 2-3 key gates per phase
8. Open questions: anything requiring product owner or developer decision before testing can proceed

Format as a document I can paste into Confluence or a Jira story comment.

Facilitating a Strategy Review Meeting

For high-stakes features, a synchronous strategy review meeting is worth the time. AI can help you prepare the right questions and discussion points.

Prompt:

Prepare a 30-minute test strategy review meeting agenda for this feature.

STRATEGY DOCUMENT:
[Paste the strategy]

ATTENDEES: QA engineer (me), feature developer, product owner, engineering lead

Create a meeting agenda that:
1. Opens with a 5-minute strategy overview (key risk areas, what's in/out of scope)
2. Includes 3-4 specific discussion questions where team input changes the strategy — don't waste meeting time on settled decisions
3. Includes a "developer check" section: questions only the feature developer can answer (implementation details that affect test design)
4. Includes a "product owner check" section: questions only the product owner can answer (business rule clarifications, priority trade-offs)
5. Ends with a sign-off checklist: specific items each person is confirming by approving the strategy

The goal is a 30-minute meeting that produces a signed-off strategy, not an open-ended discussion.

Handling Feedback and Updating the Strategy

After the review meeting, incorporate feedback and produce a final version.

Prompt:

I received the following feedback on my test strategy in the team review:

FEEDBACK ITEMS:
1. [Developer]: "The Stripe webhook timing issue you identified is handled by our idempotency key implementation — the risk is lower than scored. See this function: [function name]"
2. [Product owner]: "AC #4 says 'immediately updated' but the business requirement is 'updated within 30 seconds' — the wording was imprecise."
3. [Engineering lead]: "We should include a smoke test for the downgrade path as well, because the upgrade code shares the same service layer."

Update the test strategy to incorporate this feedback:
1. Adjust the Stripe webhook risk score based on the idempotency key information
2. Update AC #4 to reflect the correct "within 30 seconds" requirement, and add the corresponding test scenario
3. Add the downgrade smoke test to the in-scope regression section
4. Produce a change log: original decision | feedback received | change made

Output the updated strategy with the change log appended.

Learning Tip: Track every piece of feedback that changes the strategy — who provided it, what they changed, and why. This creates two valuable artifacts: a learning record for improving your prompts (if the AI consistently misses domain-specific implementation patterns, that's a prompt improvement opportunity), and a decision log that protects you if quality questions arise after release. "We knew about this risk, the developer confirmed it was mitigated, and we accepted the residual risk" is a defensible position. "We didn't think about this" is not.

How to Save Your Test Strategy as a Reusable Template?

A test strategy generated from scratch for every feature is wasteful when features share common patterns. Subscription management, user authentication, checkout flows, role-based access control, file upload and processing — these patterns appear repeatedly across products and teams. Capturing the strategy structure as a reusable template means next time, you're starting from 60% done.

What Makes a Good Strategy Template?

A reusable template is not a filled-in strategy — it's a parameterized structure. Instead of "payment processing risk is HIGH due to Stripe webhook delivery," a template says "[Integration risk area] is [RISK LEVEL] due to [specific technical factor]." The structure is fixed; the content is variable.

Good templates capture:
- The risk category framework for this type of feature (payment features have specific risk categories; authentication features have different ones)
- The coverage goal structure (what types of functional, boundary, and non-functional coverage are always relevant)
- The test level mapping heuristics (for this feature type, API tests are always primary for X; E2E tests are always primary for Y)
- The entry/exit criteria framework (what conditions are always relevant for this type of feature)
- The most common edge cases and negative scenarios for this feature pattern

Extracting a Template from a Completed Strategy

Prompt:

I have completed a test strategy for a subscription tier upgrade feature. I want to extract a reusable template for "payment and subscription management features" that I can use for future stories.

COMPLETED STRATEGY:
[Paste the final, approved test strategy]

Extract a reusable template by:
1. Identifying which elements are specific to this feature instance (replace with [PLACEHOLDER] variables)
2. Identifying which elements are generalizable to any payment/subscription feature (keep as structural elements)
3. Creating a parameterized template structure where variables are clearly marked

Variables to parameterize:
- Feature name and specific AC
- Specific third-party services (Stripe → [PAYMENT_PROVIDER])
- Specific risk scores (keep as guidelines, mark as "default starting score — validate against implementation")
- Specific test data values (replace with descriptions of test data characteristics)

Output:
1. The template document with [PLACEHOLDER] variables and [DEFAULT: value] suggestions
2. A "how to use this template" section listing the questions to answer when instantiating it for a new feature
3. A list of the edge cases and negative scenarios that are common to all payment/subscription features and should appear in every instance of this template

Building a Strategy Template Library

Over time, you should accumulate templates for your most common feature types. A practical library for a typical SaaS product might include:

Prompt:

I want to build a test strategy template library for our product. Based on the list of feature patterns below, help me:

FEATURE PATTERNS:
[List of feature patterns you commonly work with]

For each pattern, generate:
1. Template name and description (one sentence)
2. Core risk categories specific to this feature type (5-7 risk categories that always apply)
3. Required coverage goal areas (functional, non-functional, and edge case categories)
4. Default test level distribution (what percentage of scenarios typically fall at each level)
5. 5 common edge cases that every strategy for this feature type should include
6. Template skeleton in markdown format

Generate the full template library as a single document I can save to our QA repository.

Versioning and Maintaining Templates Over Time

Templates need maintenance as your tech stack, team practices, and product domain evolve. Establish a template review cadence — quarterly is usually sufficient — and use AI to help update templates based on what you've learned.

Prompt:

TEMPLATE (current version):
[Paste the current template]

LEARNING LOG (things we've discovered since the last template version):
- [Date]: Found that [specific pattern] — template should add [specific scenario or risk]
- [Date]: Discovered that [third-party service] has [behavior] that wasn't in the template
- [Date]: Identified that [risk category] is overweighted — we've tested it 5 times and never found an issue

Update the template based on this learning log:
1. Add new risk areas or scenarios based on discoveries
2. Downweight or remove risk areas that have proven lower-risk than assumed
3. Update any third-party service references if our stack has changed
4. Add a "lesson learned" annotation to each significant change explaining why it was made

Output the updated template with a change log at the bottom.

Sharing Templates Across the QA Team

A template that lives on one engineer's machine doesn't multiply. Templates become team assets when they're stored in a shared location, documented clearly, and adopted as the standard starting point for strategy work.

Prompt:

I want to document a test strategy template for team use. The template is for [feature type].

TEMPLATE CONTENT:
[Paste the template]

Create team documentation for this template that includes:
1. When to use this template (specific feature types and signals that suggest this template applies)
2. How to instantiate it (step-by-step: what questions to answer, what context to gather, what to fill in)
3. What experience level is needed to use this template effectively (can a junior QA use it independently, or does it need senior review?)
4. Known limitations: what kinds of features in this category are NOT well-served by this template?
5. Example instantiation: a brief example showing the template applied to a specific feature

Format for a QA team wiki or internal documentation system.

Learning Tip: Templates are only as good as the discipline to actually use them. The biggest adoption failure is when templates are built and then forgotten because it's "faster to start fresh." Build your templates directly into your sprint initiation workflow: when a story of type X appears in the sprint, the first step in QA preparation is opening the template for type X. The 10-minute setup is always faster than rebuilding from scratch, and the template's embedded edge cases will catch something you'd otherwise miss under sprint pressure.