Foundry Academy · Software QA · Lesson 4 of 6

Exploratory and edge-case testing

Run time-boxed exploratory sessions that pursue a clear risk mission, adapt from observations, and preserve useful coverage and evidence.

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

Exploratory and edge-case testing

Objective: Run time-boxed exploratory sessions that pursue a clear risk mission, adapt from observations, and preserve useful coverage and evidence.

Exploratory testing is not random clicking. Write a charter that names the target, risk, users, data, techniques, time box, and prohibited actions. Begin with a model of the feature and vary one dimension at a time: sequence, timing, role, state, device, locale, network, data size, interruption, concurrency, or dependency behavior. Follow surprising observations while recording what was tried. Heuristics can broaden thinking, but they do not replace requirements or specialist methods. Stop when the charter is exhausted, the time box ends, or risk requires escalation.

Edge cases matter when they represent real boundaries or harmful failure, not merely unusual values. Test state transitions such as draft-to-submit, active-to-expired, authenticated-to-session-timeout, online-to-offline, and retry-after-partial-success. Consider daylight-saving changes, Unicode, long names, right-to-left text, zoom, assistive technology, duplicate requests, and permissions where relevant. Do not conduct denial-of-service, credential attack, injection, or unauthorized security testing under a general exploratory charter. Preserve notes, data, screenshots, and coverage so another tester can understand the path. Convert stable discoveries into repeatable regression tests and record untested questions.

Before you begin

  • Confirm F03-F10; record that session duration, tester, approved oracle, browser/device allocation, data-reset method, log access, and actual observations beyond the supplied facts are absent.
  • STOP. If the session scope, tester, oracle, environment allocation, data reset, or log access is missing or conflicts across F03–F10, route the charter to the authorized QA, product, and accessibility reviewers; do not claim charter approval, execute exploration, or report a finding or severity.

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

Section
Mission and risk focus
Supported statement
Explore how build 4.8.17 handles money boundaries, focus/announcement, timeout refresh, and repeated idempotency using safe staging data.
Source input ID
F03, F07, F08, F09, F10
Assumption or gap
Exact timebox, environments, safe account, and approved expected results are not supplied.
Decision requested
Approve charter scope and evidence method before a session.
Reviewer
QA lead with product, payments, and accessibility reviewers
Status
Draft - session not run

A well-handled evidence gap

Section
Oracle and stopping conditions
Supported statement
Product/development disagree and the requirement does not define calculation order.
Source input ID
F05, F06
Assumption or gap
A pass oracle cannot be created for the credit calculation.
Decision requested
Obtain an authorized product/finance decision; explore only observable differences meanwhile.
Reviewer
Product and finance/payments owners
Status
Blocked for pass/fail conclusion

Flawed approach — do not copy

Marking this exploratory test charter “approved and complete” without the required evidence or reviewer is a flawed submission. Pause for unsafe payment side effects, sensitive data, environment drift, or an absent oracle required for a conclusion.

Repair: Rework the exploratory test charter as an evidence-backed draft, not an approved result. State one bounded mission around checkout money, accessibility, and duplicate-order risk. List supplied starting observations separately from learner-designed hypotheses. Choose tours for boundary arithmetic, modal focus, announced errors, timeout refresh, and repeated idempotency. Check the revision against this requirement: Mission, tours, variables, evidence, timebox gap, and stop conditions are explicit. 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 exploratory test charter.

Charter an authorized exploration of retries, boundaries, navigation, interruption, and recovery.

Deliverable: A sixty-minute exploratory charter, pre-session coverage map, note template, and new-risk hypothesis list; no exploratory session or finding is represented as completed.

Complete a bounded starter and gap analysis using only CB01, F03, F04, F05, F06, F07, F08, F09, F10, 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
  • M04-I01 · F03 — The sample account has a $10,000 limit and a $9,600 open balance.
  • M04-I02 · F04 — The cart includes a $700 item, ten-percent discount, $55 shipping, and 8.25-percent tax rule.
  • M04-I03 · F05 — Product and development owners disagree about the credit-check calculation order.
  • M04-I04 · F06 — The approved requirement does not define the calculation order.
  • M04-I05 · F07 — Keyboard focus disappears after the shipping modal closes.
  • M04-I06 · F08 — The error summary is not announced by the screen reader.
  • M04-I07 · F09 — Refreshing after payment timeout can create a second pending order.
  • M04-I08 · F10 — Duplicate requests share an idempotency key but receive different sandbox response identifiers.
  • M04-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.
  • M04-S01 · F03, F04, F05, F06, F07, F08, F09, F10 — Build a starter version of “A sixty-minute exploratory charter, pre-session coverage map, note template, and new-risk hypothesis list; no exploratory session or finding is represented as completed.” 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. State one bounded mission around checkout money, accessibility, and duplicate-order risk.
  2. List supplied starting observations separately from learner-designed hypotheses.
  3. Choose tours for boundary arithmetic, modal focus, announced errors, timeout refresh, and repeated idempotency.
  4. Define what to vary and what to hold constant for each tour.
  5. Specify notes, timestamps, screenshots, accessibility output, request IDs, and state transitions to capture.
  6. Add pause and escalation rules for unsafe payment behavior, sensitive data, environment drift, and ambiguous requirements.
  7. Final-QC mission, scope, exclusions, timebox, oracle gaps, evidence plan, owner, and unexecuted status.
Field-by-field guidance
Section
Name the brief section or decision topic this row resolves. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence.
Supported statement
Write a bounded statement supported by cited packet facts. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence.
Source input ID
Cite the exact Fxx or module input ID supporting the entry. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence.
Assumption or gap
Separate a provisional assumption from evidence that is absent. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence.
Decision requested
Frame the exact approval, clarification, or risk decision needed. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence.
Reviewer
Name the qualified review role and leave approval pending. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence.
Status
Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the charter to explore bounded checkout risks without substituting exploration for approved requirements or reproducible evidence.
Exploratory test charter · learning draft
SectionSupported statementSource input IDAssumption or gapDecision requestedReviewerStatus

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

Exploratory and edge-case testing

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 4 · knowledgeWhich description defines a disciplined exploratory testing charter?
Question 2 of 2 · MODULE 4 · scenarioThe module confirms boundary values and accessibility observations in F03, F04, F07, F08, and F09; F05 is conflicting; F10 is conflicting; F06 is unknown. Which charter finding is actionable without claiming execution?

Answer either question to review its reasoning.

Inspect the artifact, not just your quiz answers

  • Mission, tours, variables, evidence, timebox gap, and stop conditions are explicit.
  • Known observations are separated from hypotheses.
  • No exploratory session or finding is fabricated.

Stop: Pause for unsafe payment side effects, sensitive data, environment drift, or an absent oracle required for a conclusion.

Go: Proceed only with approved safe data, bounded scope, evidence capture, and explicit unknowns.

Escalate: Escalate new severe risks immediately and requirement ambiguity before assigning severity or pass/fail.

04 · Evidence to keep

Leave with usable work.

Submit the charter, session timeline, coverage map, findings, converted regression cases, and open questions with owners.

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.

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.