Test design · Manual investigation, cases and defects

The 60-second definition#

Test design turns requirements and risks into conditions, data and expected observations. Automation executes selected checks; manual exploration finds questions and behaviors that the scripted model may miss. OMNO explicitly asks for both, alongside defect management and collaboration.

A useful test case states preconditions, owned data, action, observable expected result and cleanup. A useful suite has a purpose and risk coverage, not simply a large number of cases.

Clarify the requirement before writing tests#

Suppose the request says “fall back when the PSP fails.” Ask: Which failure reasons? Was the payment already submitted? Is fallback allowed after a decline? How many attempts? What happens to late callbacks? Which merchant/currency rules apply? What should the UI and API show while outcome is unknown? Which audit/financial evidence proves one operation?

Turn answers into examples shared with product/developers during refinement. Record unresolved contract points explicitly. Do not invent expected status codes or infer business approval solely from a successful HTTP response.

Core design techniques#

Refund decision table#

Add concurrent valid-looking requests: separate individually valid inputs may violate a shared cumulative invariant. A table is a model, not proof that concurrency is covered.

Concrete test cases#

Case: repeated payment submission — Preconditions: isolated merchant, synthetic payment method, idempotency contract enabled, known sandbox balance/ledger view. Action: send the same request with the same supported key twice. Expected: documented response semantics, same logical payment identity and exactly one intended effect. Cleanup: authorized test-support reset or fixture expiry; preserve payment evidence if the test fails. Add changed payload/same key and concurrent replay variants.

Case: merchant ownership — Create a payment for merchant A through an approved factory. Read/refund it as B. Expected: documented deny/conceal behavior with no state change or private fields. Also test permitted read-only versus write roles within the same merchant. This is more useful than merely checking that a token exists.

Feature: Safe handling of an uncertain provider outcome
  Scenario: Provider result arrives after the initial timeout
    Given an isolated sandbox payment whose provider outcome is unknown
    When a valid late success callback is received for the original attempt
    Then the payment reflects the documented final success state
    And one logical financial effect is recorded
    And an unrelated merchant cannot read that payment

BDD is valuable when these examples drive shared understanding. It is not useful to translate every click into Gherkin solely for ceremony. Your Space Next Door BDD collaboration is a grounded example; credit actual teammates' automation contributions.

Exploratory charter and manual API/UI checks#

Charter, 25-minute hypothetical exercise: explore user recovery after an interrupted checkout while protecting against duplicate payment. Vary browser refresh/back, a slow/failed network response, double-click, stale tab, canceled challenge and a later provider callback. Observe browser network, payment/attempt references and user-visible state. Use synthetic sandbox data and approved simulator controls.

Before the session, state risks and environment. During it, note exact data, actions, times and observations; do not alter unrelated shared routing. After it, produce reproducible findings, unanswered questions, risks covered and next automated regressions. “Clicked around and found nothing” is not an evidence-rich result.

Manual API work in Postman/Swagger can validate request shape, auth, negative behavior and headers quickly. Browser developer tools help connect displayed status to the actual request and correlation ID. SQL/log access is optional and authorized; don't present private database access as universally available.

A reproducible defect report#

Severity describes impact; priority describes scheduling. A low-frequency financial integrity problem may be critical. Reopen with evidence if the observed behavior still violates the agreed contract; avoid arguing solely from “QA says so.”

Agile delivery and review#

During refinement, clarify examples and acceptance rules; during implementation, review testability/contracts and pair on uncertain failures. In sprint testing, combine focused regression, automation and exploration. Before release, communicate tested build, known issues, missing coverage and business risk. After release, use actual defect/incident evidence to improve regression and monitoring.

Definition of done can include reviewed acceptance examples, passing required tests/static checks, negative/security cases where relevant, readable diagnostics and owned residual risks. Automation ROI depends on business impact, repeat frequency, stability and maintenance cost. Not every exploratory question deserves a permanent UI test.

Interview answer and references#

30 seconds: “I clarify ambiguous payment rules, partition inputs and model state transitions before automating. I combine boundaries, permissions, retries and concurrency risks, then write reproducible cases with clear expected effects. Manual exploration helps expose missing requirements; failures become evidence-rich defects and targeted automated regressions.”

Memory hook: a case needs an oracle, not just steps. Further reading: Playwright best practices. Next: API/webhook tests.

Quick practice#