Commercial bank relationship manager portal testing verifies that bank staff can safely access and manage business customer information and complete assigned servicing workflows through the portal. It covers role permissions, customer and facility data, workflow states, integrations, security controls and the accuracy of information displayed to relationship managers.
Define the portal’s scope and users
Start by mapping the portal’s users, records and connected systems. A relationship manager may view customer profiles, account relationships, credit facilities, documents, service requests or covenant information. The portal may also support approvals, task assignment or customer communications. Confirm which functions are in scope, since implementations differ.
List each user role and the actions it is permitted to perform. Include relevant variations such as a manager overseeing a team, a colleague covering an absent relationship manager, or a user with access to several legal entities. Build a permission matrix that covers viewing, editing, downloading, submitting and approving records. Check access at the interface and, where available, through the application programming interface (API).
Test customer access and workflow rules
Verify that each user sees the correct customers and entities. Test normal access, revoked access, expired assignments and attempts to open another customer’s record by changing a URL or request identifier. Confirm that denied access does not expose customer details in the page, API response, browser storage or downloadable files.
Exercise workflows from start to finish. For example, test creating a service request, saving a draft, submitting it, assigning it for review, returning it for changes and completing it. At each transition, check the permitted actor, required fields, status, timestamps, notifications and resulting task ownership. Test invalid transitions, duplicate submissions, abandoned drafts and simultaneous edits. Expected behaviour should come from approved business rules, including who can override or reassign work.
Check integrations and data consistency
Identify the systems that supply or receive portal data. Depending on the design, these may include customer relationship management, core banking, lending, document management or identity services. Verify field mappings, identifiers, status updates and refresh behaviour across system boundaries. A displayed facility limit, for example, should reflect the defined source and update rules.
Exercise dependency failures as well as successful responses. Test delayed, unavailable and malformed responses, then check that the portal gives a useful status, avoids presenting stale data as current, and allows safe recovery. Where an action can be retried, verify that retries do not create duplicate requests or records. Use API contract checks or service simulation where suitable, and reserve tests against connected systems for the integration behaviours that require them.
Verify security and audit evidence
Check authentication and session behaviour alongside authorisation. Cover session expiry, logout, password or identity-provider changes where relevant, and access from a second session. Review handling of sensitive fields in pages, logs, exports and error messages. Confirm that masking, download restrictions and retention behaviour match the bank’s requirements.
For significant actions, verify that the audit record identifies the actor, action, affected record, time and outcome where those fields are required. Check that failed access attempts and changes to permissions are recorded according to the system’s design. An audit entry should not expose unnecessary sensitive data.
Use controlled data and verify outcomes
Prepare synthetic or appropriately anonymised test records with known relationships, permissions and workflow states. Include customers with multiple entities, different facility states and incomplete documentation. Keep test data separate from production data, and check that environment configuration does not point a test run at live services. Differences in identity roles, reference data or integration versions can cause environment drift and misleading results.
A practical access test is: sign in as a relationship manager assigned to Company A, open Company A’s facility, then attempt to load Company B’s facility by replacing the record identifier in the page request. Pass the test only if the portal follows its specified denial behaviour, returns no Company B data, and creates any required security audit event. Verify the outcome in the interface and, where possible, the API and audit store.
Keep evidence tied to requirements or risks: user role, test record, environment, action, expected result and observed result. In continuous integration (CI), run fast permission and critical workflow checks on relevant changes, then include broader integration and regression coverage before release. Investigate failures by separating application defects from test-data, environment and dependency issues.
Frequently asked questions
How should automated tests handle changing portal layouts?
Use stable selectors based on accessible names, labels or agreed test attributes, and avoid selectors tied to page position or styling. Keep assertions on business outcomes, such as the saved workflow status, alongside checks that the relevant control is available.
What should a test cover when one employee holds several portal roles?
Define the expected effective permissions for each role combination, then test allowed and denied actions against that combination. Repeat the checks after a role is added or removed to confirm that access changes take effect without leaving permissions behind.
How can teams test integrations when a connected system is unavailable?
Use a controlled simulator or service stub to exercise timeouts, errors and recovery paths, and keep separate integration tests for behaviours that need the real connected system. Record which dependencies were simulated so the test result has clear limits.
What evidence is useful when reviewing a portal access-control defect?
Capture the test user’s effective role, the customer record involved, the attempted action, the expected permission, the observed response and any relevant audit event. Remove or mask sensitive customer information from screenshots and logs.