How to test a traditional bank branch teller application

Traditional bank branch teller application testing verifies that staff can complete branch transactions accurately, securely and consistently across the teller interface and connected banking systems. It covers transaction rules, customer and account data, cash controls, authorisation, receipts and audit records. Tests should confirm both the result shown to the teller and the resulting account, cash and ledger states.

Scope traditional bank branch teller application testing

Start with the branch workflows the application supports, such as cash deposits and withdrawals, cheque deposits, account transfers, balance enquiries, transaction reversals and end-of-shift cash balancing. Confirm the bank's configured rules before writing expected results. Limits, fees, available-balance treatment, identification checks and approval thresholds can vary by product, branch and jurisdiction.

Map each workflow across its dependencies. A teller transaction may use customer and account services, the core banking system, cash-drawer records, a general ledger, receipt or document services, and audit logging. Record which system owns each outcome and what evidence can be checked in the test environment. This supports functional testing and integration testing without treating a successful screen message as proof of a completed transaction.

Use synthetic or appropriately anonymised customer and account data. Set up account status, balances, holds, currency, permissions and cash-drawer opening balances as preconditions. Keep test data isolated from live customer records and establish how transactions and drawer totals will be reset between runs.

Test transaction rules and controls

For each transaction, check valid, invalid and boundary conditions. A withdrawal test, for example, should cover an eligible account with sufficient available funds, an amount at the configured limit, and an amount that exceeds either the available balance or the teller's permitted limit. Verify the displayed decision, any required approval, and whether an account or cash position changes.

Check role-based access and approval paths. A teller without the required permission should not complete a restricted action. Where a second approval is configured, verify that the transaction remains pending until the authorised person approves or rejects it. Check that the audit record identifies the relevant users and action without exposing credentials or unnecessary sensitive data.

Treat retries, timeouts and reversals as transaction scenarios in their own right. If the teller submits a withdrawal and the response times out, retrying must not create an unintended duplicate debit or cash movement. A reversal should create the outcome specified by the bank's rules, preserve a traceable link to the original transaction and update downstream records consistently. Verify account balances, transaction history, cash totals and ledger postings after each case.

Check integrations and transaction consistency

For integration checks, compare the teller application's transaction reference and status with the corresponding core banking result and any expected downstream posting. Confirm that amounts, account identifiers, currency, value date and status agree. Where the interface uses asynchronous messages, check that delayed delivery, rejection or retry does not leave the systems in conflicting states.

Test relevant failure paths, including an unavailable dependency, a rejected posting and a broken connection after submission. Expected behaviour depends on the system design: the application might keep a transaction pending, show a clear failure, or allow a controlled retry. In every case, establish whether the transaction committed before repeating an action. Verify that no incomplete transaction is presented as successful and that reconciliation or recovery procedures can identify outstanding work.

Practical test case: cash withdrawal

Precondition: use a synthetic customer account that is active, has enough available funds, and has no hold. Set the teller's cash drawer balance and permissions to known values.

1. Sign in as the authorised teller and select the customer and account.
2. Enter a withdrawal amount within the configured account and teller limits, then submit it.
3. Check that the application shows the accepted result and a unique transaction reference.
4. Verify the account debit, transaction history, receipt details, drawer movement and expected ledger posting.
5. Repeat the submission after a simulated timeout, where the test environment supports it. Confirm the original outcome and check that the retry has not caused a second debit or cash movement.

The expected results should state exact values for the selected test data and configuration. A pass requires agreement across the user interface and the systems that own the transaction outcome. A visible confirmation alone is insufficient if the core record or cash movement is missing.

Verify results and manage test risk

Run teller checks in an environment with representative integrations, permissions and configuration. Environment drift, such as a different limit or stale account status, can make results misleading, so record the relevant configuration and build for each run. Use manual exploratory checks for unusual branch workflows and automate stable, repeatable transaction paths where interfaces and test data support reliable assertions.

Review failures by tracing the transaction reference through application logs, audit records and permitted downstream evidence. Separate product defects from test-data, environment and dependency failures. Retest the affected workflow and related regression cases after a fix, including reversal and retry paths when transaction handling changes.