# Manual QA Plan — AI Startup Idea Validation Web App ## 1. Plan at a glance This is a proposed human-run plan for the supplied pre-release web app. It covers creating a validation report, checking its stated sections and claim labels, opening and copying a saved report, and starting a blank assessment. **No tests have been run; current planning status: RETEST—evidence incomplete.** ## 2. Input facts, assumptions, and unknowns **Input facts:** The founder enters an idea, target users, and primary concern. Generate report produces sections named Founder-provided claims, Hypotheses, and Next-step tests; founder-provided claims are labeled unverified. The app does not browse or verify claims. Saved reports appear in Reports, can be opened and copied with Copy report, and New report starts a blank assessment. Intended test target: pre-release responsive web app in desktop Chrome. Risks supplied: generated text may blur claim/hypothesis labels, generation may fail, and copied text may differ from the display. Test ideas must be synthetic. **Assumptions for this plan:** A pre-release environment and a way to create or seed a saved report are available. These are prerequisites, not confirmed product facts. For repeatability, use the synthetic sample idea below. No live customer or founder data is needed. **Unknowns / prerequisites:** Exact Chrome version, a controlled way to reproduce a generation failure, and the expected error/recovery behavior if generation fails are not supplied. Do not infer a failure message or recovery feature. If no controlled failure is available, record that risk as untested. The expected behavior when any input is blank is also unspecified and is not asserted here. ## 3. Scope and setup Plan for desktop Chrome only; mobile-specific behavior and accessibility/privacy checks are not in the supplied scope. Use a non-production pre-release build and the synthetic idea: `A weekend meal-planning app for solo campers; target users are first-time campers; primary concern is whether they can plan meals with limited cooking gear.` Before testing, confirm that report generation and a saved report are available in the test environment. The report's suggested tests are app-generated text, not verified findings. ## 4. Manual test cases Priority labels below are suggested planning labels, not an industry standard. Run the cases in order; record actual evidence rather than assuming a result. ### QA-01 — Start a new assessment (P1) - **Scenario:** Start the first core flow with the supplied synthetic inputs. - **Prerequisites / test data:** Pre-release app in desktop Chrome; synthetic idea, target users, and concern above. - **Exact human steps:** 1. Open the pre-release app. 2. Select **New validation**. 3. Enter the synthetic text in **Idea**, **Target users**, and **Primary concern**. 4. Pause before selecting **Generate report**. - **Expected result:** The three supplied values are present in the assessment ready to generate. The location or exact appearance of fields beyond these labels is not specified; if a label is absent, record it rather than guessing another control. - **Pass/fail evidence:** Pass if the entered values can be visually confirmed before generation; fail if any entered value is missing or visibly altered. Save a redacted screenshot or note of the fields; do not include sensitive data. ### QA-02 — Generate a report with the named sections (P1) - **Scenario:** Complete the happy path for a new validation. - **Prerequisites / test data:** QA-01 inputs; report-generation service available in the pre-release environment. - **Exact human steps:** 1. Complete QA-01. 2. Select **Generate report** once. 3. Wait for the app to finish or show an error. 4. If a report appears, inspect its section headings. - **Expected result:** A generated report appears and contains **Founder-provided claims**, **Hypotheses**, and **Next-step tests**. No result is presumed in advance. If generation fails, record the observed screen/message; the expected failure message and recovery behavior are unknown, so do not call that behavior a pass. - **Pass/fail evidence:** Pass if a report appears with all three named sections; fail if a report appears but a required section is missing, or generation cannot complete in the supplied test setup. Capture the displayed result/error and time. Mark failure handling **RETEST—expected behavior not supplied** until the app owner defines the expected failure behavior. ### QA-03 — Check claim and hypothesis separation (P1) - **Scenario:** Verify that a founder-provided statement is not silently presented as verified fact. - **Prerequisites / test data:** A generated report from QA-02; use this explicitly synthetic input statement: `I think weekend campers struggle to plan meals.` - **Exact human steps:** 1. In **New validation**, enter the synthetic statement in **Idea** and a suitable synthetic audience in **Target users**. 2. Enter `whether meal-planning is a real problem` in **Primary concern**. 3. Select **Generate report**. 4. Locate the statement and related uncertain claims in the report. 5. Check the labels around them. - **Expected result:** The report distinguishes statements supplied by the founder under **Founder-provided claims** from unverified inferences under **Hypotheses**. It must not imply that the app browsed or independently verified the statement. - **Pass/fail evidence:** Pass if the supplied statement is visibly treated as founder-provided/unverified and inferences are distinguished as hypotheses; fail if the report labels the supplied statement verified or claims external checking. Record the exact relevant excerpt and section heading. ### QA-04 — Open a saved report (P2) - **Scenario:** Reopen a saved result from Reports. - **Prerequisites / test data:** At least one saved report created using synthetic inputs; pre-release app in desktop Chrome. - **Exact human steps:** 1. Open **Reports**. 2. Find the synthetic saved report. 3. Select its list item. 4. Compare the opened report's visible title/content with the saved item you intended to open. - **Expected result:** The selected saved report opens. The input says saved reports appear in **Reports** and can be opened; no list sort or title format is specified. - **Pass/fail evidence:** Pass if the intended saved report opens and its content can be matched to the selected item; fail if it is absent or a different report opens. Record the item selected and the displayed report identifier/title if present. ### QA-05 — Copy report text (P2) - **Scenario:** Compare Copy report output with the displayed report. - **Prerequisites / test data:** A saved report opened via QA-04; a safe local text editor or blank note for temporary comparison. - **Exact human steps:** 1. Keep the saved report visible. 2. Select **Copy report**. 3. Paste into a blank local note. 4. Compare the copied text with the visible report, including the three section headings and their text. - **Expected result:** Copied text matches the displayed report's content. Formatting may differ only where the app's copy behavior is not specified; compare wording and section content, not styling. - **Pass/fail evidence:** Pass if the pasted content contains the same visible report text and no section/content is missing; fail if wording, section content, or report identity differs. Save a redacted comparison note or describe the mismatch. ### QA-06 — Start another blank assessment (P2) - **Scenario:** Confirm New report starts a blank assessment after a report exists. - **Prerequisites / test data:** A generated synthetic report; assessment state visible. - **Exact human steps:** 1. With a report open, select **New report**. 2. Inspect **Idea**, **Target users**, and **Primary concern** before entering anything. - **Expected result:** A blank assessment is ready; prior report text is not prefilled into those fields. This follows the supplied statement that New report starts a blank assessment. - **Pass/fail evidence:** Pass if the new assessment fields are blank; fail if previous input remains prefilled. Record the visible field contents without including private data. ### QA-07 — Reproduce the generation-failure risk only if a safe control exists (P2; conditional) - **Scenario:** Observe the supplied generation-failure risk without creating a failure artificially. - **Prerequisites / test data:** Only run if the app owner supplies a safe, documented test trigger or the pre-release environment naturally returns a generation error. Do not disrupt a service or change production settings. The expected failure/recovery behavior is an open prerequisite. - **Exact human steps:** 1. Confirm the test trigger and expected failure behavior with the app owner. 2. Use a synthetic assessment. 3. Follow the owner-provided test steps. 4. Record the visible app response and whether the entered values remain available. - **Expected result:** **Not yet defined by the supplied app facts.** The app owner must state the expected error message and recovery behavior before pass/fail can be assigned. - **Pass/fail evidence:** Record the trigger, screen/message, and input state. Until an expected behavior is supplied, mark **RETEST—evidence incomplete**; do not infer success from the mere presence of an error. ## 5. Defect log template | Defect ID | Linked test ID | Observed result and evidence | Expected result/source | Reproducible steps | Severity/priority (suggested) | Environment | Owner/status | Retest result | |---|---|---|---|---|---|---|---|---| | Not recorded—tests not run | | | | | | | | | ## 6. Small release gate These are suggested checks for this plan, not industry standards. The present plan-only status is **RETEST—evidence incomplete** because nobody has run the cases or supplied results. - **HOLD—fix blockers:** Use if a human-run check confirms that report generation or another stated core flow is blocked, or a material failure is confirmed. Record the evidence and owner decision. - **RETEST—evidence incomplete:** Use if a pre-release environment, expected result, test data, or evidence is missing; this includes QA-07 until the owner defines the expected failure behavior. - **READY FOR HUMAN RELEASE REVIEW:** Use only after the applicable checks have recorded evidence, no confirmed blocker remains, and unresolved limitations are visible to a human reviewer. This is not a release approval. ## 7. Human review checklist - [ ] Confirm every supplied core flow has an applicable test or a stated reason it could not be covered. - [ ] Confirm environment, saved-report setup, and any conditional failure trigger before testing. - [ ] Record actual results and evidence; do not treat this plan as an execution report. - [ ] Log failures with their expected-result source and retest them after a fix. - [ ] Review remaining limitations and decide the release status as a human. **Manual QA guidance only. This prompt does not execute or certify tests, inspect or fix the app, certify security, or approve a release. A human must review the plan and evidence.**