Foundry Academy · Software QA · Lesson 2 of 6

Test planning and environments

Create a proportionate test plan with controlled scope, representative environments, safe data, ownership, entry and exit criteria, and known limitations.

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 planning and environments

Objective: Create a proportionate test plan with controlled scope, representative environments, safe data, ownership, entry and exit criteria, and known limitations.

A test plan explains what evidence will support a release decision. Define scope, excluded areas, risks, test types, environments, devices, browsers, roles, data, dependencies, responsibilities, schedule, entry criteria, exit criteria, defect rules, evidence storage, and reporting cadence. Map the plan to acceptance criteria and recent changes. Include recovery and negative paths, not only successful completion. Estimate based on risk and available capacity, then state what reduced scope means. A plan that promises complete coverage is not credible; software has too many states and interactions for exhaustive testing in ordinary projects.

The environment record is part of every result. Capture build or commit, configuration, operating system, browser or client, device, locale, time zone, account role, feature flags, integrations, and relevant data state. Use synthetic or authorized data and keep production credentials out of test artifacts. Confirm that test actions cannot notify real customers, charge real accounts, corrupt records, or overload systems. Differences between test and production must be documented because they limit inference. Security, performance, resilience, and destructive testing require approved methods and specialists where appropriate. If the environment changes during a run, record the change and reassess affected evidence.

Before you begin

  • Confirm F01, F02, and F11; record that browser/device versions, operating systems, assistive-technology combinations, test accounts, data reset method, and approved coverage priority are not supplied.
  • STOP. If environment versions, assistive-technology coverage, test accounts, data reset, or coverage priority is missing or conflicts with F01/F02/F11, route the matrix to authorized QA, product, and accessibility owners; do not claim coverage approval or execute testing.

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

Environment ID
ENV-01
Build
4.8.17 staging — M02-I01 (F01)
Browser/version
Not supplied
OS/device
Desktop combination not supplied
Viewport/input
Keyboard coverage proposed; viewport not supplied
Assistive technology
Not supplied
Locale/network
Not supplied
Dependency version
Tax service changed after the prior baseline — M02-I03 (F11)
Risk coverage
One of at least eight planned slots; exact six-browser/two-mobile combinations remain unspecified — M02-I02 (F02).
Evidence location
Pending — test execution is outside this exercise
Owner
QA lead
Status
Draft — environment details not supplied

A well-handled evidence gap

Environment ID
ENV-02
Build
4.8.17 staging — M02-I01 (F01)
Browser/version
Not supplied
OS/device
Mobile device model and OS not supplied
Viewport/input
Touch and responsive viewport details not supplied
Assistive technology
Not supplied
Locale/network
Not supplied
Dependency version
Current tax-service version not supplied
Risk coverage
Mobile scope exists, but the approved pairing and expected results are not supplied — M02-I02 (F02).
Evidence location
Not supplied
Owner
QA lead and accessibility reviewer
Status
Blocked — environment definition pending

Flawed approach — do not copy

Marking this cross-environment test-plan matrix “approved and complete” without the required evidence or reviewer is a flawed submission. Stop execution or coverage claims when build, environment, dependency, test data, or evidence-capture state is unknown.

Repair: Rework the cross-environment test-plan matrix as an evidence-backed draft, not an approved result. Freeze build 4.8.17 as the version under design review. Enumerate all six browser and two mobile-device slots instead of collapsing them into one desktop row. Add operating system, viewport/input method, assistive technology, locale, and network-state fields as not supplied where absent. Check the revision against this requirement: Six browser and two mobile-device slots are explicitly represented. 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 cross-environment test-plan matrix.

Design an environment and data matrix that represents the approved scope and dependencies.

Deliverable: A test-plan matrix with builds, devices, browsers, roles, data, services, and reset method.

Complete a bounded starter and gap analysis using only CB01, F01, F02, F11, 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
  • M02-I01 · F01 — The release candidate is build 4.8.17 in staging.
  • M02-I02 · F02 — Six browsers and two mobile devices are in scope, while the plan covers one desktop browser.
  • M02-I03 · F11 — The tax service changed after the prior regression baseline.
  • M02-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.
  • M02-S01 · F01, F02, F11 — Build a starter version of “A test-plan matrix with builds, devices, browsers, roles, data, services, and reset method.” 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. Freeze build 4.8.17 as the version under design review.
  2. Enumerate all six browser and two mobile-device slots instead of collapsing them into one desktop row.
  3. Add operating system, viewport/input method, assistive technology, locale, and network-state fields as not supplied where absent.
  4. Map checkout risks to each proposed environment using a risk-based rationale.
  5. Include the changed tax service as a dependency and baseline-reset trigger.
  6. Define setup, data reset, evidence capture, and blocked-environment handling.
  7. Final-QC coverage counts, version traceability, dependency state, owners, and pending execution.
Field-by-field guidance
Environment ID
Assign one stable row ID per planned environment slot.
Build
Record the supplied build identifier and source ID or Not supplied.
Browser/version
Record the approved browser/version or Not supplied; do not invent scope values.
OS/device
Record the approved OS/device combination or Not supplied.
Viewport/input
Record viewport and keyboard/touch/pointer coverage or Not supplied.
Assistive technology
Record the approved assistive-technology/version pairing or Not supplied.
Locale/network
Record locale and network condition or Not supplied.
Dependency version
Record material dependency/baseline versions, including tax-service status, or Not supplied.
Risk coverage
Map the row to a cited scope/risk and state what remains uncovered.
Evidence location
Name the planned evidence location; leave it pending because tests were not run.
Owner
Name the authorized QA or specialist-review role.
Status
Use Planned — approval pending, Blocked, or Not supplied; never claim execution.
Cross-environment test-plan matrix · learning draft
Environment IDBuildBrowser/versionOS/deviceViewport/inputAssistive technologyLocale/networkDependency versionRisk coverageEvidence locationOwnerStatus

Start with 6 rows; the complete workbook specifies 8 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 2 · 2-item formative check

Test planning and environments

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 2 · knowledgeWhy must a software test result identify the environment in which it was observed?
Question 2 of 2 · MODULE 2 · scenarioF01 confirms build 4.8.17 in staging, F02 confirms six browsers and two mobile devices in scope while the plan covers one desktop browser, and F11 confirms the tax service changed after the prior baseline. Which planning sequence is supported?

Answer either question to review its reasoning.

Inspect the artifact, not just your quiz answers

  • Six browser and two mobile-device slots are explicitly represented.
  • Build and tax-service versions are controlled.
  • No environment is represented as executed.

Stop: Stop execution or coverage claims when build, environment, dependency, test data, or evidence-capture state is unknown.

Go: Proceed when every in-scope slot has a reproducible setup and risk rationale.

Escalate: Escalate inaccessible environments, dependency drift, and scope reductions to QA/product/accessibility owners.

04 · Evidence to keep

Leave with usable work.

Submit the plan, environment matrix, data strategy, traceability map, entry and exit criteria, and residual-risk statement.

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 ↗

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.