# Qualiow Exploratory Testing Skills — Knowledge Base Changelog
# Tracks what changed in each release so /qa-knowledge-list can show history.

releases:
  - version: "0.6.0"
    date: "2026-09-03"
    summary: "Asynchronous money movement — verifying that a payment credited a ledger exactly once, and what a callback endpoint owes the caller it cannot control."
    entries_added:
      - id: technique-exactly-once-verification
        type: technique
        name: "Exactly-Once Verification — Proving a Payment Moved Money Once"
        description: "Assert the balance delta, never the status field, then attack the flow with the five cases that break it: an identity collision between records created in the same instant, the same event redelivered simultaneously rather than sequentially, a contradicting event, an event arriving after a timeout closed the record, and a settlement amount that does not match the request. Includes what to do when the defect corrupts your own parallel test run."
      - id: technique-async-callback-contracts
        type: technique
        name: "Asynchronous Callback Contracts — What a Webhook Endpoint Owes Its Caller"
        description: "Is the endpoint authenticated, which field does it actually deduplicate on rather than which one is documented, what does it do with an event matching no record, and can the caller distinguish applied from duplicate from discarded. The unmatched-event case is where collected money goes uncredited with nothing to show for it."
    entries_modified: []
    entries_removed: []
    origin: "A black-box assessment of an asynchronous mobile-money top-up service. Every sequential path through it was correct and every concurrent one was not, so the existing request-and-response techniques reported it as healthy while two independent defects were crediting wallets with money no provider had collected."

  - version: "0.5.0"
    date: "2026-09-03"
    summary: "Payload correctness and release-level verification — what to do with the answer once you have it, and how to report a set of tickets rather than one."
    entries_added:
      - id: technique-derived-value-verification
        type: technique
        name: "Derived Value Verification — Recomputing the Number and Naming What It Does Not Prove"
        description: "Recompute every percentage, total, ratio and aggregate from the raw figures in the same response, using the formula from the spec rather than the code. Choose cases that stress sign, zero, scale and cardinality, add the structural invariants, then state explicitly that internal consistency is not correctness and name the independent oracle that would close the gap."
      - id: technique-presentation-integrity
        type: technique
        name: "Presentation Integrity — Does the Screen Show What the Service Sent?"
        description: "A correct payload can still reach the user as a wrong number. Formatting helpers that guess what a value is, units applied twice, rounding across a threshold, truncation shown as a total. Invisible from either surface alone, and routinely attributed to the wrong change."
      - id: technique-expected-behaviour-specification
        type: technique
        name: "Expected Behaviour Specification — Writing the Spec That Should Have Existed"
        description: "Observed against expected, per area rather than per case, with the reject-or-clamp and error-or-empty decisions made explicit, ranked by what users can reach today, and closed with a plain-English reply for whoever decides to fund the fix."
      - id: technique-config-surface-verification
        type: technique
        name: "Config & Feature-Flag Surface Verification"
        description: "When the configuration mechanism is itself the change: values matching the deployed config rather than the source default, nothing leaking alongside them, the runtime genuinely reading through the surface rather than around it, and the route existing in every environment the change will be promoted to."
      - id: technique-release-readiness-verification
        type: technique
        name: "Release Readiness Verification — Many Tickets, One Build"
        description: "Establish what is deployed before testing anything, give every ticket a result from a fixed vocabulary that keeps not-testable and not-tested visible, mark code-verified-only as UNVERIFIABLE rather than green, separate carry-overs, and end with a disposition and the condition that would reverse it."
    entries_modified: []
    entries_removed: []
    origin: "Sessions that verified calculated values, multi-ticket releases and a feature-flag surface exposed the gaps: derived values signed off from a single payload, screens signed off without the payload beside them, findings with no acceptance criterion to file them against, and release reports where a code reading looked the same colour as an observation."

  - version: "0.4.0"
    date: "2026-09-03"
    summary: "The HTTP/API verification lane — how to probe a service's own endpoints with real credentials, and how to know the environment is running the code you are judging."
    entries_added:
      - id: technique-environment-fingerprinting
        type: technique
        name: "Environment Fingerprinting — Proving What Is Actually Running"
        description: "Before the first probe: which build is deployed in every component of the path, whether the changed code path is SELECTED here, and whether the commit under test is an ancestor of what is running. Same build plus different behaviour means configuration, not deploy lag. Adds NOT-REACHABLE as the honest verdict when the change is not live in the environment being measured."
      - id: technique-authenticated-api-probing
        type: technique
        name: "Authenticated API Probing — Calling the Endpoint Behind the Screen"
        description: "Get a real authenticated request context without handling a token by running fetch inside the already-logged-in page, then drive a written case matrix through it. Ten case families, how to read each signal, and the evidence and safety rules that keep credentials and response bodies off disk."
      - id: technique-ui-api-differential
        type: technique
        name: "UI-vs-API Differential — Running the Same Matrix at Both Surfaces"
        description: "Sort every finding into reproducible-at-both, API-only, UI-only and neither. Corrects the most common false PASS in exploratory testing: a client-side guard recorded as the endpoint's behaviour."
      - id: technique-silent-failure-audit
        type: technique
        name: "Silent Failure Audit — Failures That Render as Ordinary Results"
        description: "Seven shapes of failure that look like a legitimate empty or zero answer, how to force each one, and why they recur as a class rather than as individual bugs."
    entries_modified: []
    entries_removed: []
    origin: "Paired UI and API sessions on the same features showed three gaps: the endpoint was never called directly, so client-side guards were being recorded as endpoint behaviour; environments were compared without checking which implementation each one ran; and the same silent-failure defect kept being filed as unrelated one-off bugs."

  - version: "0.3.0"
    date: "2026-08-21"
    summary: "The BE/API verification layer — how to actually observe a backend, API or LLM change, and how to say so when you cannot."
    entries_added:
      - id: technique-verification-mode-selection
        type: technique
        name: "Verification Mode Selection — Choosing How to Observe a Backend Change"
        description: "Route each AC to the observation channel that can falsify it: API-behind-the-screen, direct request to a no-UI endpoint, LLM output judgement, or needs-a-human. Makes UNVERIFIABLE a first-class verdict instead of a PASS inferred from source."
      - id: technique-functional-diff-analysis
        type: technique
        name: "Functional Diff Analysis — Reading a Backend Change for Behaviour, Not Style"
        description: "Eight passes over a BE/API/LLM diff that produce falsifiable hypotheses rather than code comments: spec drift, value tracing to the service boundary, failure paths, identity propagation, producer/consumer contract, scope, and the tests that shipped with it."
      - id: technique-llm-output-verification
        type: technique
        name: "LLM & Agent Output Verification — Running It and Judging the Result"
        description: "Fixed input set, written rubric, before-and-after on the same inputs, N runs to expose variance, assertions on properties and tool trajectory rather than on generated text. Includes what not to claim from a passing run."
    entries_modified: []
    entries_removed: []
    origin: "Built after two backend ticket verifications showed the gap: deep judgement and real test execution existed for the UI, but backend, API and LLM changes were being signed off by reading the diff."

  - version: "0.2.0"
    date: "2026-08-20"
    summary: "Backend AC-verification techniques derived from real /qa-verify-backend sessions — both aimed at changes that fail silently by construction."
    entries_added:
      - id: technique-contract-narrowing
        type: technique
        name: "Contract Narrowing — Verifying a Swapped Data Source"
        description: "When a full-record read is replaced by a projection, the request's field-selection list becomes the payload specification. Trace every consumed field to a selection token; unrequested fields vanish with no error, no DLQ, and a green suite."
      - id: technique-test-suite-audit
        type: technique
        name: "Auditing the Branch's Own Tests"
        description: "When a change rewrites the tests that are meant to prove it works, those tests become part of the change. Check that each assertion still falsifies what its name claims, and that artefacts named by an AC actually exist."
    entries_modified: []
    entries_removed: []
    origin: "A read-path swap on an event-processing service — a full-record read replaced by a projection read. The contract-narrowing audit found a dropped webhook field that 175 green unit tests could not see; the test audit found an e2e negative scenario that could only pass when the system was broken."

  - version: "0.1.0"
    date: "2026-03-28"
    summary: "Initial knowledge base — core heuristics, techniques, checklists, and references for exploratory testing."
    entries_added:
      - id: heuristic-sfdipot
        type: heuristic
        name: "SFDIPOT - Product Elements"
        description: "James Bach's mnemonic for systematically identifying what to test in any product."

      - id: heuristic-few-hiccupps
        type: heuristic
        name: "FEW HICCUPPS - Consistency Oracles"
        description: "Bach & Bolton's oracle heuristic for recognizing problems through consistency violations."

      - id: heuristic-test-tours
        type: heuristic
        name: "Whittaker's Test Tours"
        description: "12 exploration strategies modeled as city tours for structured yet creative testing."

      - id: heuristic-goldilocks
        type: heuristic
        name: "Goldilocks Heuristic"
        description: "Elisabeth Hendrickson's 'too big, too small, just right' heuristic for testing with extremes and typical values across all input types."

      - id: heuristic-rcrcrc
        type: heuristic
        name: "RCRCRC(R) — Regression Testing Focus Areas"
        description: "Karen N. Johnson's mnemonic for regression test prioritization: Recent, Core, Risky, Configuration, Repaired, Chronic, plus Revenue."

      - id: technique-boundary-testing
        type: technique
        name: "Boundary Value Analysis"
        description: "Systematic boundary testing across types — numbers, strings, dates, collections, and more."

      - id: technique-error-guessing
        type: technique
        name: "Error Guessing"
        description: "Experience-based negative testing — null inputs, injection, Unicode, concurrency, and network failures."

      - id: technique-business-logic-race-conditions
        type: technique
        name: "Business Logic Flaws & Race Condition Testing"
        description: "Advanced technique for hidden endpoints, state transition attacks, parameter tampering, and race conditions."

      - id: technique-risk-based-testing
        type: technique
        name: "Risk-Based Testing"
        description: "Strategic testing prioritization using Risk = Probability x Impact, risk matrices, RPN scoring, and Nightmare Headlines."

      - id: technique-data-integrity-testing
        type: technique
        name: "Data Integrity & Cross-Feature Verification"
        description: "Verify data correctness across all related pages after every state-changing action — calculations, persistence, audit trails, uniqueness, and temporal consistency."

      - id: checklist-accessibility-wcag
        type: checklist
        name: "WCAG 2.1 Level AA Checklist"
        description: "Accessibility checklist organized by POUR principles with Playwright CLI verification commands."

      - id: reference-exploratory-testing-types
        type: reference
        name: "Exploratory Testing Types & Approach"
        description: "Three types of exploratory testing and the learn-test-adapt loop for AI agents."

      - id: reference-heuristic-praxis
        type: reference
        name: "Heuristic Praxis — Theory Meets Practice"
        description: "Understanding when and how to apply heuristics thoughtfully, bridging the praxis gap for AI agents."

    entries_modified: []
    entries_removed: []
