How to test a credit union member portal

Credit union member portal testing checks that members can securely access and use online services, and that the portal displays and processes information in line with the credit union's rules and connected systems. It covers member authentication, account information, transfers and other enabled services, as well as accessibility, error handling and the accuracy of data exchanged with the core platform.

Define scope and prepare test conditions

List the journeys the portal supports, such as sign-in, account and transaction viewing, transfers, loan payments, statements, profile changes and alerts. Include membership eligibility or account-opening journeys only if the portal provides them. Confirm which account types and services are in scope, since terminology and product rules vary between credit unions.

For each journey, identify the expected outcome and the systems involved. A transfer may involve the portal, an application programming interface (API), payment processing and the core platform. Agree how quickly status and balances should update, and which system is authoritative if a screen and an API response differ.

Use a controlled test environment with synthetic or appropriately protected member data. Prepare accounts with known statuses, balances, permissions and transaction histories. Check that the environment has the intended configuration and service versions: environment drift can make a test pass or fail for reasons unrelated to the portal change. Avoid tests that send real payments or change live member records unless a formally approved production check defines safe limits and controls.

Test member journeys and financial data

Exercise each journey with valid, invalid and boundary conditions. For account views, check that the signed-in member sees only authorised accounts and that displayed balances, dates, transaction descriptions and statement periods match the agreed source data. Where the portal distinguishes ledger and available balances, verify the intended treatment of holds and pending transactions.

For a transfer, check payee or destination selection, amount validation, confirmation, status and the resulting account data. Test insufficient funds, invalid amounts, unavailable services and interrupted submissions. A retry after a timeout should not create a duplicate transaction. Confirm that a completed or rejected request leaves the portal and connected systems in a consistent state, using API or backend evidence where available.

A practical test case could be:

• Given a member is authenticated and has two eligible accounts with known opening balances
• When the member submits a transfer between those accounts and receives confirmation
• Then the portal shows the expected status and updated balances within the agreed processing time
• And the transaction appears once in the relevant history, with the expected amount and reference

Repeat the scenario with a network interruption after submission. Check how the portal reports an uncertain outcome and whether refreshing or retrying preserves the original transaction state.

Verify authentication, authorisation and recovery

Test sign-in, multi-factor authentication (MFA) where enabled, password reset, session expiry and sign-out. Verify that expired or revoked sessions cannot continue to access member data, including through a previously opened page or a direct link. Check that a member cannot view or change another member's accounts by changing a URL parameter, request identifier or client-side value.

Exercise lockout, invalid credentials and recovery paths against the credit union's documented rules. Error messages should give members enough information to recover without disclosing whether another person's account exists or exposing sensitive details. Confirm that security events and significant member actions are recorded where the design requires an audit trail.

Check accessibility and web behaviour

Complete common tasks using keyboard navigation, visible focus, browser zoom and a screen reader. Check that form labels, validation errors, headings and status messages are understandable without relying on colour or visual position alone. Test pages at supported viewport sizes and verify that controls remain usable when content reflows.

Run the same high-risk journeys across the browsers and devices the credit union supports. Use stable selectors based on accessible names or application attributes in automation, and avoid selectors tied to changing layout or generated identifiers. Combine user-interface checks with API assertions when they provide clearer evidence of account state or transaction results.

Interpret failures and report evidence

A failed portal check may come from a defect in the interface, an API contract change, stale test data, a downstream service outage or configuration drift. Capture the member state, environment, request or correlation identifier, timestamps and relevant screenshots or responses. Separate a genuine product failure from a test setup problem before assigning severity.

Trace each high-risk journey to its expected result and retain enough evidence for another tester to reproduce it. Re-run affected regression tests after fixes, including connected journeys that depend on the same authentication, account or payment services.