Foundry Academy · Software QA · Lesson 1 of 6

Quality risk and acceptance criteria

Translate user and business outcomes into testable acceptance criteria prioritized by consequence, likelihood, exposure, and detectability.

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

Quality risk and acceptance criteria

Objective: Translate user and business outcomes into testable acceptance criteria prioritized by consequence, likelihood, exposure, and detectability.

Quality begins with a shared definition of acceptable behavior. Identify users, goals, environments, dependencies, data, and consequences before writing tests. A requirement such as 'the form is easy to use' is not directly testable; clarify the intended user, task, condition, and observable result. Acceptance criteria should cover the normal path, important alternatives, invalid input, permissions, failure messages, recovery, and relevant accessibility or security expectations. Each criterion needs an approved source. When the source is ambiguous or conflicting, QA should raise the decision rather than silently choose the expected behavior.

Prioritize testing using risk, not feature visibility alone. Consider impact on people, money, safety, privacy, security, compliance, reputation, and continuity; then assess likelihood, frequency, exposure, change size, complexity, and how easily failure would be detected. A rarely used administrative permission can deserve more attention than a popular color change. Record assumptions and residual gaps so decision-makers know what was not tested. QA provides evidence and risk analysis; product, engineering, security, legal, accessibility, or other authorized owners decide within their roles. Testers must not perform intrusive or destructive work without explicit scope and permission.

Before you begin

  • Confirm F03-F09; record that the approved credit-check order, expected duplicate-request behavior, complete accessibility acceptance standard, and release decision are not supplied.
  • STOP. If calculation order, duplicate-request behavior, accessibility acceptance, or the release decision is missing or conflicts across F03–F09, route the criterion to authorized product, payments/finance, engineering, accessibility, and QA owners; do not claim acceptance approval, test execution, pass/fail, or release.

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

Criterion ID
AC-CREDIT-01
Given state
$10,000 limit; $9,600 open balance; cart has a $700 item, ten-percent discount, $55 shipping, and an 8.25-percent tax rule.
Action
Learner-proposed check of the credit decision using an approved calculation sequence.
Expected observable result
Decision gap — expected approval/decline result cannot be fixed until the calculation order is approved.
Formula or rounding rule
Operands are supplied; calculation order and rounding points are not supplied because product/development disagree and the requirement is undefined.
Environment
Not supplied
Source IDs
M01-I01 (F03); M01-I02 (F04); M01-I03 (F05); M01-I04 (F06)
Requirement status
Conflicting / not supplied
Owner
Product owner with engineering and QA review
Test status
Blocked — requirement decision pending

A well-handled evidence gap

Criterion ID
AC-FOCUS-02
Given state
Keyboard focus disappears after the shipping modal closes.
Action
Close the shipping modal using a keyboard in an approved test environment.
Expected observable result
Approved focus-return target and observable focus state are not supplied.
Formula or rounding rule
Not applicable
Environment
Browser, OS/device, viewport, input method, and build evidence not supplied.
Source IDs
M01-I05 (F07)
Requirement status
Observed defect; acceptance target incomplete
Owner
Accessibility reviewer and frontend engineering owner
Test status
Not run — environment and expected target pending

Flawed approach — do not copy

Marking this acceptance-criteria table “approved and complete” without the required evidence or reviewer is a flawed submission. Stop pass/fail or release claims when the requirement, formula, environment, or expected state is disputed or absent.

Repair: Rework the acceptance-criteria table as an evidence-backed draft, not an approved result. Capture account, cart, tax, requirement-conflict, accessibility, and duplicate-order facts with source IDs. Separate supplied observations from proposed acceptance rules. Write each criterion as observable given/when/then behavior with a single pass condition. Check the revision against this requirement: Money, accessibility, duplicate, and recovery criteria are observable and traceable. 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 acceptance-criteria table.

Translate the requirement and known uncertainty into testable criteria and release risks.

Deliverable: An acceptance-criteria table and quality-risk register.

Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, 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
  • M01-I01 · F03 — The sample account has a $10,000 limit and a $9,600 open balance.
  • M01-I02 · F04 — The cart includes a $700 item, ten-percent discount, $55 shipping, and 8.25-percent tax rule.
  • M01-I03 · F05 — Product and development owners disagree about the credit-check calculation order.
  • M01-I04 · F06 — The approved requirement does not define the calculation order.
  • M01-I05 · F07 — Keyboard focus disappears after the shipping modal closes.
  • M01-I06 · F08 — The error summary is not announced by the screen reader.
  • M01-I07 · F09 — Refreshing after payment timeout can create a second pending order.
  • M01-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.
  • M01-S01 · F03, F04, F05, F06, F07, F08, F09 — Build a starter version of “An acceptance-criteria table and quality-risk register.” 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. Capture account, cart, tax, requirement-conflict, accessibility, and duplicate-order facts with source IDs.
  2. Separate supplied observations from proposed acceptance rules.
  3. Write each criterion as observable given/when/then behavior with a single pass condition.
  4. Show formula operands and rounding points, but keep the expected credit decision pending because calculation order is undefined.
  5. Add keyboard-focus, screen-reader-summary, and timeout-refresh criteria.
  6. Assign product, engineering, accessibility, payments, and QA reviewers to unresolved decisions.
  7. Final-QC for traceability, ambiguity, negative paths, environment assumptions, and no invented pass result.
Field-by-field guidance
Criterion ID
Assign a stable training criterion ID linked to one supplied requirement, observation, or decision gap.
Given state
State only packet-supplied preconditions and values.
Action
Describe one bounded user/system action to be tested; do not claim execution.
Expected observable result
State the observable pass condition or explicitly record a decision gap when the requirement is unresolved.
Formula or rounding rule
Show supplied operands and the approved rule; use Not supplied when order or rounding is undefined.
Environment
Record a supplied environment or Not supplied; do not invent browser, device, or build evidence.
Source IDs
Cite exact module input and fact IDs supporting the criterion.
Requirement status
Use Confirmed, Conflicting, Not supplied, or Proposed — review pending.
Owner
Name the authorized product, engineering, accessibility, payments, or QA role.
Test status
Use Not run, Blocked, Draft, or another evidence-backed state; never invent a pass.
Acceptance-criteria table · learning draft
Criterion IDGiven stateActionExpected observable resultFormula or rounding ruleEnvironmentSource IDsRequirement statusOwnerTest status

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 1 · 2-item formative check

Quality risk and acceptance criteria

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 1 · knowledgeWhich source provides the strongest independent basis for an expected test result?
Question 2 of 2 · MODULE 1 · scenarioBlueMesa confirms account and cart values in F03 and F04; F05 is conflicting on credit calculation order; F06 is unknown for the approved order; F07 through F09 confirm accessibility and duplicate-order risks. Which acceptance approach is defensible?

Answer either question to review its reasoning.

Inspect the artifact, not just your quiz answers

  • Money, accessibility, duplicate, and recovery criteria are observable and traceable.
  • Disputed calculation order remains an explicit blocker.
  • No test result or product approval is fabricated.

Stop: Stop pass/fail or release claims when the requirement, formula, environment, or expected state is disputed or absent.

Go: Proceed to test design when each criterion has cited inputs, observable behavior, and an authorized owner for gaps.

Escalate: Escalate money calculations, duplicate-order behavior, and accessibility acceptance to product, finance/payments, engineering, and accessibility owners.

04 · Evidence to keep

Leave with usable work.

Submit the clarified criteria, source links, risk scores, assumptions, open decisions, and rationale for the top five test priorities.

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.

nist-sp-800-218 · Official guidance

NIST SP 800-218 Secure Software Development Framework Version 1.1

Primary NIST guidance for integrating secure software practices across the development lifecycle.

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.