hiccupps-f-heuristic
Pure-reference catalog of Michael Bolton's HICCUPPS-F oracle heuristic - the reference points a tester consults to decide 'is this a bug?': History, Image, Comparable products, Claims, Users' desires, Product (internal consistency), Purpose, Standards/statutes, plus Familiar problems. Use mid-session to test an observation against each oracle. For what to VARY use sfdpot-exploratory-heuristic, for touring an unfamiliar product use fcc-cuts-vids-heuristic, for quality criteria use crusspic-stmpl-heuristic.
Install with skills.sh (any agent)
npx skills add testland/qa --skill hiccupps-f-heuristichiccupps-f-heuristic
Overview
HICCUPPS-F is Michael Bolton's oracle heuristic - a mnemonic for the kinds of references a tester consults to decide whether an observation is a problem. It's published at developsense.com/blog/2012/07/few-hiccupps (opens in new window).
The point: a "bug" is a relationship between an observation and some expectation. Different expectations come from different oracles. HICCUPPS-F gives the tester a checklist of oracle types to consult before deciding "no oracle ⇒ probably not a bug" or "oracle says X ⇒ behaviour Y is wrong."
This skill is a pure reference consumed by individual testers during sessions (session-based-test-management-reference).
When to use
The nine oracles
Per Bolton's published catalog:
H - History
Does the system's current behaviour match what it did before?
Behaviour regressed from a known prior version = bug. Sources:
I - Image
Does the behaviour match the company's brand and reputation?
The product's overall feel: error messages should not be hostile, loading states should look professional, copy should be on-brand. Sources:
C - Comparable products
Does the behaviour match what competitors / peers do?
Industry conventions. A login form that lacks "forgot password" when every competitor has one. Sources:
C - Claims
Does the behaviour match what stakeholders said it would do?
The spec, the requirements document, the customer-promise email, the sales-deck slide. Sources:
U - Users' desires
Does the behaviour match what users actually want / need?
Users may want something different than what the spec says. Sources:
P - Product (internal consistency)
Does the behaviour match other behaviours in the same product?
The settings page uses a save button; the profile page does auto-save. The same data field is formatted differently across two screens. Sources:
P - Purpose
Does the behaviour match the actual reason the feature exists?
The feature exists to help X do Y; the behaviour doesn't help X do Y. Sources:
S - Standards / statutes
Does the behaviour comply with relevant standards + regulations?
WCAG accessibility, GDPR data handling, ISO 25010 quality characteristics, PCI-DSS for payments, HIPAA for health, RFC for network protocols. Sources:
F - Familiar problems
Have we seen this kind of bug before, in this or other systems?
Pattern-matching against known bug classes:
Sources:
Worked example - applying HICCUPPS-F mid-session
Observation: Cart total shows $24.99 when promo "TAX10" applied,
but receipt PDF shows $25.49.
Walk HICCUPPS-F:
- H (History): Old screenshots from v1.4 show consistent totals.
→ This is a regression. **BUG.**
- I (Image): Inconsistent values reflect badly on the brand. Even
if there's no other oracle, this fails Image.
- C (Comparable): Stripe / PayPal flows always show consistent
totals across cart + receipt. **Industry convention violated.**
- C (Claims): Promo code spec says "TAX10 applies 10% before tax."
Cart applies it before tax (correct); receipt applies it after
tax (incorrect). **Spec violated.**
- U (Users' desires): Users will dispute the $0.50 difference
with support. **Visible to customer.**
- P (Product): Cart and receipt should be consistent at minimum.
**Internal consistency broken.**
- Purpose: Promo feature exists to encourage purchase; mismatched
totals erode trust. **Purpose undermined.**
- S (Standards): Statutory? Possibly - depends on locale (some
jurisdictions require receipts to match displayed totals).
- F (Familiar problems): Rounding-order bug; classic off-by-cent
pattern. **Known bug class.**
Conclusion: Multiple oracles agree this is a bug. File
high-priority.Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Consulting only one oracle | Misses bugs visible from other angles | Walk all 9; even briefly |
| "I don't see an oracle ⇒ probably fine" | Some bugs only one oracle catches (F - familiar problem patterns from elsewhere) | Look at F (familiar problems) before concluding "no oracle" |
| Charter doesn't pre-state expected oracles | Session aimless | Charter should hint at applicable oracles ("explore X with HICCUPPS-F focusing on Claims + Users + Standards") |
| Bug report without HICCUPPS-F citation | Report's "why is this a bug?" weak | Every bug report should cite at least one oracle from HICCUPPS-F |
| Treating Standards as final authority | Standards lag; users / purpose may indicate the real bug | Use all 9 as inputs, not as final-word hierarchy |
| Skipping F (familiar problems) for new product | Most "new" bugs are familiar patterns from other systems | Always check F |
Limitations
References
Related skills
bug-bash-facilitator
Builds a structured bug-bash session - pre-bash kit (charter, test-data prep, environment setup, sign-up sheet), in-bash structure (role rotation across cohorts, shared backlog board, real-time triage), scoring rubric (severity weighting, novelty bonus), and a post-bash same-day wrap-up authored by the facilitator (not a standalone debrief: for post-session writeups without a live bash, use manual-test-debrief). Use when a team needs a coordinated multi-tester sweep before a release or after a major change - converts an ad-hoc "everyone test for an hour" into a recorded, comparable session with deliverables.
crusspic-stmpl-heuristic
Pure-reference catalog of James Bach's CRUSSPIC STMPL heuristic - thirteen quality criteria (quality attributes / non-functional requirements) a tester can evaluate a system against. CRUSSPIC: Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility. STMPL: Supportability, Testability, Maintainability, Portability, Localizability. Use when checking a product's quality attributes or non-functional requirements, or picking which quality characteristics a test session evaluates - a checklist for judging product quality holistically; complementary to the ISO/IEC 25010 software product-quality model.
decision-table-test-design
Derives human-readable manual test cases from a business-rule spec via a decision table: identify conditions and actions, build the full 2^n-column matrix, collapse columns with irrelevant entries, strike infeasible combinations, then emit one test case per remaining column (each feasible column is one coverage item per ISTQB CTFL v4.0 section 4.2.3). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use when a spec's outcome depends on interacting conditions (pricing, eligibility, discounts, routing rules) rather than the boundaries of a single input.
exploratory-tours-reference
Pure-reference catalog of the seven exploratory testing tours from Whittaker's Exploratory Software Testing (2009): Feature, Money, Landmark, Intellectual, Bad-data, Configuration, and Garbage-collector's, each a themed mission with the signal it surfaces and a worked example. Use as the menu a charter author picks session themes from. Distinct from the mnemonic catalogs sfdpot-exploratory-heuristic (what to vary) and hiccupps-f-heuristic (oracles), and from session-based-test-management-reference, which manages the sessions.
fcc-cuts-vids-heuristic
Pure-reference catalog of Michael Kelly's FCC CUTS VIDS touring heuristic (2005): eleven tours - Feature, Complexity, Claims, Configuration, User, Testability, Scenario, Variability, Interoperability, Data, Structure - each a reconnaissance sweep that builds familiarity with an unfamiliar application. Use when onboarding onto a product or opening a first session on an unknown area, before a charter is scoped. Distinct from exploratory-tours-reference (Whittaker's seven tours, which frame a bug-hunting mission on a product the tester already knows), sfdpot-exploratory-heuristic (what to vary), hiccupps-f-heuristic (oracles), and crusspic-stmpl-heuristic (quality criteria).
manual-test-debrief
Session debrief template + tour-coverage tracker - captures the SBTM PROOF format (Past, Results, Obstacles, Outlook, Feelings) plus three-bucket time accounting (test design / setup / bug investigation), the tours applied + areas covered + areas skipped, and the per-session quality-of-attention signal. Output is the artifact a charter delivers into; the team aggregates debriefs across sessions to track what's been explored vs what's still uncharted. Use after every exploratory session - without the debrief, the session's findings disappear.
manual-test-script-author
Builds stakeholder-readable scripted manual test cases from a feature spec - emits either a step-table format (preconditions / steps / expected result / actual / pass-fail / notes) for spreadsheet review or a Gherkin Given/When/Then format for BDD-aware teams. Each script is self-contained (no implicit team knowledge), single-scenario (one happy + N edge per script), and includes the data setup the tester needs without being a developer. Use when a feature can't be (or shouldn't be) fully automated and a human tester needs an executable script - UAT, regression baselines, certification testing, exploratory follow-up scripts.
manual-testing-overview
Teaches human-driven testing end to end: when a predefined scripted test case is the right instrument versus a time-boxed exploratory session, how session-based test management works (charter with a stated mission, time box, session notes, debrief) with a worked charter and a filled-in session sheet, a decision rule for what to automate versus what to keep human, and what makes a manual bug report actionable (exact reproduction steps, observed versus expected, build and environment, evidence). Use when planning or running testing a person performs by hand, writing a charter for an exploratory session, deciding whether a check belongs in an automated suite or in a human session, or fixing bug reports that developers keep returning as not reproducible.
session-based-test-management-reference
Pure-reference catalog of Session-Based Test Management (SBTM) - the Bachs' framework for running exploratory testing as time-boxed sessions: the session (60-90 min), the charter (Explore X with Y to discover Z), the session-sheet structure, the TBS metrics, the cross-session dashboard, and the PROOF debrief. Use when authoring exploratory-testing charters, reviewing session sheets, or setting up time-boxed test sessions. Distinct from manual-test-debrief (the PROOF debrief template), exploratory-tours-reference (the session themes), and the heuristic catalog hiccupps-f-heuristic.
sfdpot-exploratory-heuristic
Pure-reference catalog of James Bach's SFDPOT heuristic - 'San Francisco Depot' - a 'you are here' framework that catalogues what a tester can vary in a system to find bugs. Six dimensions: Structure, Function, Data, Platform, Operations, Time. Use as a what-to-vary checklist during an exploratory session, complementing HICCUPPS-F (which catalogues what to compare against).
state-transition-test-design
Derives human-readable manual test cases from stateful behavior: identify states, events, transitions, and guard conditions, draw the state table including invalid (empty-cell) transitions, choose a coverage level (all states, valid transitions / 0-switch, transition pairs / 1-switch per Chow, all transitions including invalid ones), then derive one test case per coverage item as an event sequence with per-step expected states (ISTQB CTFL v4.0 section 4.2.4). A deep single-technique walkthrough rather than a broad multi-lens case matrix; the output is manual step/expected cases rather than parameterized test code, and it covers how cases are derived rather than how a case record is structured. Use for lifecycle entities (accounts, orders, subscriptions), workflows, and UI wizards where the response to an event depends on the current state.
test-execution-checklist
Converts a regression suite (or test plan) into an executable manual checklist for cases when automation isn't viable - a release-day smoke checklist, a post-incident verification list, or a periodic compliance check. Outputs a per-TC checkbox list with the minimal preconditions, the action, and a one-line "what to look for" - short enough to fit on one page per major flow. Use when the team needs a focused human-runnable list (not full step-tables), e.g., for production smoke after deploy or for the on-call rotation's quick verification.
uat-script-author
Emits User Acceptance Testing scripts in stakeholder-readable format - pre-conditions / business-language steps / expected business outcome / pass-fail / sign-off. Tailored for non-developer testers (end users, SMEs, solution owners) per the UAT canonical definition. Output is one TC per stakeholder-meaningful scenario with explicit sign-off, suitable for compliance / contract / audit records. Use when a release requires formal UAT before sign-off - typical for B2B contracts, regulated industries, or any delivery where the customer's acceptance is the contractual gate.