Minorbug Logo

Test Case Categories

Test Cases for IBAN Field (With Examples & Expected Results)

This guide lists practical test cases for IBAN field implementations, including validation rules, formatting and normalization, country coverage, checksum behavior, accessibility, and negative tests. Use these scenarios when building or testing payment forms, onboarding flows, payouts, and internal banking tools.

Need sample data for QA? Try our free IBAN generator to produce valid, random IBANs for testing.

1) Basic Validation Test Cases

  • Accept valid IBAN
    Input: A known valid IBAN for a supported country (e.g., NL86ABNA5048946594)
    Steps: Paste or type the IBAN and submit.
    Expected: Field passes validation; form submission succeeds.
  • Reject invalid IBAN (checksum)
    Input: Alter 1–2 digits in a valid IBAN to break MOD 97-10.
    Expected: Clear error message (no banking jargon), no submission.
  • Reject invalid length for country
    Input: Shorten or extend by 1–2 characters.
    Expected: Error states the IBAN is the wrong length for the selected/detected country.
  • Reject disallowed country (if your product limits countries)
    Expected: Error explains unsupported country; offer help or documentation.

2) Formatting & Normalization

  • Case normalization
    Input: fi 8239390026518936
    Expected: Auto-normalizes to FI8239390026518936 (uppercase, trimmed).
  • Whitespace & separators
    Input: IBAN with spaces or dashes (e.g., NL86 ABNA 5048 9465 94)
    Expected: Accepts and normalizes; stored value is a canonical unspaced IBAN.
  • Leading/trailing spaces
    Expected: Trims before validation; no false negatives.

3) Country Coverage & Detection

Verify that the IBAN field either detects the country from the IBAN prefix or validates against a configured list of allowed countries.

  • Allowed countries
    Expected: IBANs from allowed countries pass; others fail with clear messaging.
  • Country-specific rules
    Expected: The field enforces length and pattern per country (e.g., EE, NL, BE). For sample test data, use the IBAN generator.

4) Checksum & Account-Part Logic

  • Checksum (MOD 97-10)
    Expected: Only IBANs with a correct checksum are accepted.
  • Account-part constraints
    Expected: If your business logic validates the domestic account segment (BBAN) beyond checksum, supply invalid BBAN samples and confirm rejection with actionable error messages.

5) User Experience & Accessibility

  • Labels & descriptions
    Expected: Clear field label (e.g., “IBAN”), optional help text with examples.
  • Error messages
    Expected: Specific (e.g., “IBAN is the wrong length for NL”) and announced via ARIA (aria-live) for screen readers.
  • Paste behavior
    Expected: Pasting with spaces/dashes works; input is normalized automatically.
  • Mobile keyboards
    Expected: Alphanumeric keyboard; input doesn’t force numeric keyboard only.

6) Negative, Security & Edge Cases

  • Invalid characters (e.g., emojis, symbols)
    Expected: Rejected with a clear error.
  • SQL/HTML injection attempts
    Expected: Neutralized and rejected; no server logs or UI leak sensitive info.
  • Very long input (e.g., 10× max length)
    Expected: Graceful error; no performance or memory issues.
  • Empty/placeholder input
    Expected: Required validation triggers with helpful guidance.

7) Storage & Audit

  • Canonical storage
    Expected: Persist IBANs in a canonical uppercase, no-space format.
  • Logging
    Expected: No full IBANs in plain logs; use masking where appropriate.

8) Sample Valid IBANs for Testing

Use these examples as a starting point (always validate in your own environment). For more, generate fresh samples with the IBAN generator.

BE54363463151697
CY92009039841817354209277428
DK2840011510824084
EE270000001086160701
LU770013281985014235
LT057010692680275267
LV22PARX3889421835219
NL86ABNA5048946594
CH0800765400104344516

Related Resources

Note: IBANs shown here are examples for QA and sandbox environments only. Do not use for real transactions.