Test Strategy for a Learning Application

1. Analyze the requirement

The scenario: "A discount code field accepts a 6-character alphanumeric code. Codes starting with 'SAVE' apply a 20% discount; codes starting with 'FREE' apply free shipping; any other valid-format code is rejected as unrecognized. Orders under $10 cannot use any discount code." Identify at least three ambiguities or missing details in this requirement, and rewrite it as a precise, testable specification.

• At least three real ambiguities or gaps are identified (e.g. case sensitivity, what happens with a code that's both a 'SAVE' prefix and under $10, expired-code handling)
• A rewritten, precise version of the requirement is produced that resolves each identified gap with an explicit decision
• The rewritten requirement is specific enough that a stranger could design test cases from it without asking follow-up questions

2. Design test cases with equivalence partitioning and boundary-value analysis

Using your precise requirement from Milestone 1, identify the equivalence classes for the discount-code field's length/format, and the boundary values for the $10 order-total threshold.

• At least four equivalence classes are identified for the code field (e.g. too short, too long, right length with invalid characters, valid SAVE code, valid FREE code, valid but unrecognized code)
• One representative test case is documented for each class, with expected result
• The three boundary values around the $10 threshold ($9, $10, $11) are tested with documented expected results

3. Build a decision table for the combined discount logic

The discount actually depends on two combined conditions: whether the code is a recognized SAVE/FREE prefix, and whether the order total is at least $10. Build a complete decision table covering all combinations and derive one test case per row.

• The decision table has all combinations of the two binary conditions (recognized-code: yes/no, order-total-at-least-10: yes/no)
• Each row has a documented, justified expected outcome
• Each row is translated into one specific, concrete test case (exact code value, exact order total, exact expected result)

4. Prioritize with risk, then report one defect

Score each test case group from Milestones 2 and 3 with a likelihood/impact risk score, rank them, and then write one complete, actionable defect report for a planted bug: a 'FREE10' code (a FREE-prefixed code that also happens to look like it references a threshold) incorrectly applies a 20% discount instead of free shipping.

• Every test case group has a documented likelihood and impact score (1-5 each) and a resulting risk score
• The groups are ranked, with a brief justification for the top-ranked group
• The defect report includes exact steps to reproduce, expected result, actual result, environment, and a severity/priority judgment with reasoning for each

5. Traceability matrix and final review

Build a small traceability matrix linking each part of the rewritten requirement (from Milestone 1) to the specific test cases that verify it (from Milestones 2-3), and identify any requirement with weak or missing coverage.

• Every distinct rule in the rewritten requirement has at least one linked test case in the matrix
• Any requirement with zero or only one linked test case is explicitly flagged as a coverage gap, with a proposed additional test case
• The finished strategy document (requirement analysis, test cases, risk ranking, defect report, traceability matrix) is organized so a new team member could follow it without additional context