Foundry Academy · Software QA · Lesson 3 of 6

Test cases and evidence

Write repeatable test cases tied to acceptance criteria and capture evidence sufficient for another authorized tester to evaluate the result.

Start the lesson

Your learning work, on this device

No signup, cloud storage, cross-device sync or verified completion. Saving is optional. This browser profile is shared with anyone who can use it; private mode, browser cleanup or storage limits may remove work. Use only fictional or non-sensitive material. Export a copy before relying on this device.

Not saved. Worksheets, answers and practice notes currently last only in this tab.

Practice markers are self-reported, never credentials.

01 · Explanation

Test cases and evidence

Objective: Write repeatable test cases tied to acceptance criteria and capture evidence sufficient for another authorized tester to evaluate the result.

A structured test case records its identifier, objective, requirement, risk, preconditions, data, environment, steps, expected result, cleanup, and evidence. Keep steps precise enough to reproduce but focused on behavior rather than irrelevant clicks. The expected result must come from a test oracle, not from the current application's behavior. Include equivalence classes and meaningful boundaries: empty, minimum, maximum, just inside, just outside, invalid format, duplicate, expired, unauthorized, and interrupted states where applicable. Avoid using one enormous case for an entire customer journey because a failure becomes hard to diagnose and rerun.

Evidence should support the conclusion without collecting more data than necessary. Screenshots are useful when they show state, but text logs, network records, accessibility-tree output, database assertions, or system events may be stronger. Record timestamps and identifiers that connect evidence to the case and build. Redact secrets and personal data, and do not place credentials in videos or defect tickets. Mark pass, fail, blocked, not run, or inconclusive using defined meanings. A passed check means the observed result met the criterion in the recorded environment; it does not prove the feature works in every environment or is free of defects.

Before you begin

  • Confirm F03-F10 and F12; record that approved formula order, precise environments, complete steps, expected duplicate behavior, timestamps, screenshots/logs, and execution results are absent.
  • STOP. If formula order, environment, reproducible steps, expected duplicate behavior, or evidence method is missing or conflicts with F03–F10/F12, route the design to authorized product, payments, accessibility, and QA reviewers; do not claim test approval, execution, pass/fail, or a defect conclusion.

Original overview module anchor →

02 · Compare the artifacts

Supported work. Visible uncertainty.

This is a fictional, sanitized software-quality case. All systems, users, transactions, and records are fabricated; testing remains authorized and bounded and provides no security, legal, accessibility, or defect-free guarantee.

BlueMesa checkout release

BlueMesa is a fictional business-to-business storefront preparing release 4.8 of its checkout. The approved requirement says authenticated buyers may purchase approved catalog items up to their account credit limit, apply one active contract discount, choose an allowed shipping method, and receive an accessible confirmation. The release candidate is build 4.8.17 in staging. Six browsers and two mobile devices are in scope, but the test plan lists only the latest desktop Chrome. A sample account has a $10,000 credit limit and an existing $9,600 open balance. The cart contains a $700 item, a 10 percent contract discount, $55 shipping, and an 8.25 percent tax rule. The product owner expects the order to be blocked, while the developer says discounts should be considered before the credit check; the requirement does not state calculation order. In preliminary testing, the keyboard focus disappears after the shipping modal closes, the error summary is not announced by the screen reader, and refreshing after payment timeout sometimes creates a second pending order. Logs show the same idempotency key on both requests, but the payment sandbox returns different response identifiers. The tax service was upgraded after the last regression baseline. A defect titled checkout broken includes no build, data, steps, expected result, actual result, or evidence. Marketing already announced Friday availability, and the release manager proposes accepting all medium defects. Learners must define risk and acceptance, control environments, write reproducible tests, explore edge cases within authority, classify defects, and make an evidence-bounded release recommendation. They must not conduct unapproved security testing or claim exhaustive coverage.

Supported example — reference only

Test ID
TEST-01
Requirement/risk
Credit-decision arithmetic is disputed — M03-I03 (F05); approved order is absent — M03-I04 (F06).
Preconditions
Sample account has $10,000 limit and $9,600 open balance — M03-I01 (F03).
Test data
$700 item, ten-percent discount, $55 shipping, 8.25-percent tax rule — M03-I02 (F04).
Ordered steps
1) Load approved safe account; 2) enter supplied cart values; 3) submit only after the calculation rule is approved; 4) capture operands and decision trace.
Expected result or decision gap
Blocked — calculation order, rounding points, and expected credit decision are not supplied.
Environment
Not supplied
Evidence to capture
Calculation trace, displayed totals, decision message, request/response IDs, and timestamp.
Reviewer
Product owner, engineering owner, and QA lead
Result
Not run
Status
Draft — oracle decision pending

A well-handled evidence gap

Test ID
TEST-02
Requirement/risk
Refresh after payment timeout can create a second pending order — M03-I07 (F09); duplicate requests share a key but sandbox IDs differ — M03-I08 (F10).
Preconditions
Approved safe payment sandbox account and timeout setup are not supplied.
Test data
Payment payload, idempotency-key generation rule, and expected record state are not supplied.
Ordered steps
Learner-proposed sequence: submit, induce approved timeout, refresh once, and compare order/request records.
Expected result or decision gap
Expected duplicate-request and order-state behavior requires authorized product/payments decision.
Environment
Not supplied
Evidence to capture
Request IDs, key, response IDs, order IDs/statuses, timestamps, and logs.
Reviewer
Payments engineer, product owner, and QA lead
Result
Not run
Status
Blocked — safe setup and oracle not supplied

Flawed approach — do not copy

Marking this six test-case designs “approved and complete” without the required evidence or reviewer is a flawed submission. Stop execution or defect conclusions when expected behavior, environment, safe test data, or evidence method is missing.

Repair: Rework the six test-case designs as an evidence-backed draft, not an approved result. Create exactly six stable test-case IDs spanning money boundary, calculation ambiguity, keyboard focus, screen-reader summary, timeout refresh, and idempotency. Write preconditions and test data directly from supplied facts without inventing credentials or records. Express each action sequence as a learner-proposed reproducible method. Check the revision against this requirement: Exactly six distinct risk-based designs are present. If the required evidence is still absent, keep the decision blocked and identify the missing input or authorized reviewer.

Full case record, ambiguities and all assignments →

03 · Bounded practice

Build the six test-case designs.

Create tests for credit calculation, payment timeout, and accessible error handling.

Deliverable: Six test-case designs, two evidence starters for the observed accessibility and duplicate-order issues, and result-pending fields for every unexecuted case.

Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, F10, F12, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

Exact supplied inputs for this assignment
  • M03-I01 · F03 — The sample account has a $10,000 limit and a $9,600 open balance.
  • M03-I02 · F04 — The cart includes a $700 item, ten-percent discount, $55 shipping, and 8.25-percent tax rule.
  • M03-I03 · F05 — Product and development owners disagree about the credit-check calculation order.
  • M03-I04 · F06 — The approved requirement does not define the calculation order.
  • M03-I05 · F07 — Keyboard focus disappears after the shipping modal closes.
  • M03-I06 · F08 — The error summary is not announced by the screen reader.
  • M03-I07 · F09 — Refreshing after payment timeout can create a second pending order.
  • M03-I08 · F10 — Duplicate requests share an idempotency key but receive different sandbox response identifiers.
  • M03-I09 · F12 — The existing checkout-broken defect lacks reproducibility and expected-result evidence.
  • M03-B01 · CB01 — Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
  • M03-S01 · F03, F04, F05, F06, F07, F08, F09, F10, F12 — Build a starter version of “Six test-case designs, two evidence starters for the observed accessibility and duplicate-order issues, and result-pending fields for every unexecuted case.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

Operating procedure

  1. Create exactly six stable test-case IDs spanning money boundary, calculation ambiguity, keyboard focus, screen-reader summary, timeout refresh, and idempotency.
  2. Write preconditions and test data directly from supplied facts without inventing credentials or records.
  3. Express each action sequence as a learner-proposed reproducible method.
  4. State the expected result only where approved evidence exists; otherwise name the pending product decision.
  5. Specify environment and evidence capture, marking absent versions, timestamps, logs, and screenshots not supplied.
  6. Route requirement, accessibility, and payments questions to qualified reviewers before execution.
  7. Final-QC IDs, sources, preconditions, steps, expected results, negative paths, and pending status.
Field-by-field guidance
Test ID
Use one stable ID for each of the six designed cases.
Requirement/risk
Name the cited requirement, observation, or unresolved oracle addressed by the case.
Preconditions
State only supplied setup conditions; mark unavailable data Not supplied.
Test data
Use the exact supplied values or a clearly labeled learner-proposed safe value.
Ordered steps
Write reproducible numbered actions without claiming they were executed.
Expected result or decision gap
State the approved observable result or the precise missing decision that blocks it.
Environment
Name the supplied environment or Not supplied.
Evidence to capture
List the planned screenshots, logs, network records, accessibility tree, or identifiers; evidence remains pending.
Reviewer
Name the qualified product, engineering, accessibility, payments, or QA role.
Result
Use Not run or Blocked unless the packet supplies a result.
Status
Use Draft, Ready after approval, or Blocked.
Six test-case designs · learning draft
Test IDRequirement/riskPreconditionsTest dataOrdered stepsExpected result or decision gapEnvironmentEvidence to captureReviewerResultStatus

Start with 6 rows; the complete workbook specifies 6 stable rows for this artifact. Add rows here or use the full download. No action is saved until you explicitly choose saving above.

Download complete six-module workbook (.md) · Structured case packet (.json)

Keep private client data, unpublished inventions, personal identifiers and credentials out of these public learning tools.

Module 3 · 2-item formative check

Test cases and evidence

Choose an answer and request feedback. Read why each option does or does not fit the evidence. Answers stay in this tab unless you choose device-only saving; they are never submitted.

Question 1 of 2 · MODULE 3 · knowledgeWhich test record supports a reproducible pass-or-fail decision by another authorized tester?
Question 2 of 2 · MODULE 3 · scenarioF05 is conflicting and F06 is unknown for calculation order; F07 through F09 confirm accessibility and duplicate-order observations; F10 is conflicting for duplicate request identifiers; F12 confirms an incomplete defect record. Which evidence-design gate is appropriate?

Answer either question to review its reasoning.

Inspect the artifact, not just your quiz answers

  • Exactly six distinct risk-based designs are present.
  • Each case has traceable data, method, expected-state boundary, reviewer, and evidence plan.
  • No execution result is implied.

Stop: Stop execution or defect conclusions when expected behavior, environment, safe test data, or evidence method is missing.

Go: Proceed when all six designs are reproducible and unresolved expected outcomes are explicitly assigned.

Escalate: Escalate formula and duplicate-state ambiguity to product/payments; accessibility expectations to the accessibility owner.

04 · Evidence to keep

Leave with usable work.

Submit the cases, oracle references, environment, sanitized evidence, results, and limitations for each untested condition.

Download your artifact CSV and, if wanted, export the learning-work JSON above. Neither export is a reviewed submission or certificate. Device-only saving is optional; you must press Save my work now after edits.

When all six artifacts are ready, compare the full packet against the track rubric. Qualified human review is still required before real-world decisions.

Software developer reviewing code and test evidence on a tablet.
Learn the standard. Practice the work.
Developer testing and reviewing software code in a modern office.
Leave with evidence you can inspect.

Sources, scope and review boundaries

Curriculum 2026.10.08-learning-paths-1. External source dates below are record checks, not continuing guarantees. Verify current requirements before consequential use.

w3c-wcag-22 · Standards-body recommendation

Web Content Accessibility Guidelines (WCAG) 2.2

The W3C Recommendation defining testable success criteria for more accessible web content.

Open reviewed external source ↗

owasp-web-security-testing-guide · Official guidance

OWASP Web Security Testing Guide

The OWASP flagship testing resource; security techniques require explicit authorization and appropriate specialist competence.

Open reviewed external source ↗

ws-software-qa-operating-standard · Academy internal operating standard

Wealth Synergy software-QA internal operating standard

Academy-selected risk, test-case, defect, evidence, regression, and release-review controls. This is an internal operating standard selected by Foundry Academy; it is not law, accreditation, licensure, or an external-standard requirement.

Version 1.0 · reviewed 2026-09-01 · owner: Foundry Academy curriculum owner

A future Wealth Synergy private professional-development certificate would be issued only after its assessment, capstone, identity, reviewer, retention, access, deletion, appeal, and issuance controls pass quality review. No credential is currently issued. Any future certificate would not be an accredited academic qualification, professional license, or government certification.