Client portal acceptance testing

Direct answer

Client portal acceptance testing starts with one question: can any client see, guess or reach another client's information? Answer it with deliberate tests using at least two test clients, then move on to roles, documents, notifications, devices, failure cases and data. Sign off only when each check has a recorded result. A portal that looks polished but leaks between accounts is worse than no portal.

This checklist is specific to portals. General acceptance practice, such as writing criteria first and triaging defects, is in the user acceptance testing checklist for custom software. How roles are modelled is covered in roles and permissions in a web application. What follows is practical functional checking by your team; it is not a penetration test and does not replace a specialist security assessment where you need one.

Isolation tests

Create at least two test client organisations, each with several users and different records. Log in as a user from the first and try to reach anything belonging to the second. Do it the ordinary way, by browsing lists, searching and filtering, and the awkward way, by editing the address in the browser to an identifier from the other client, opening a saved link while logged in as someone else, and using a document link after logging out.

Check every place data appears: lists, detail pages, search results, exports, downloaded files, notification emails and any counts or totals. A record hidden in the list but visible by direct link is a failed test. Record what you tried and what happened, so the result can be repeated after every later change.

• Two or more test clients with distinct data and several users each.
• Lists, search, filters, detail pages and exports all checked for cross-client content.
• Direct links and identifiers from another client rejected.
• Links to documents refuse access after logout and for the wrong client.
• Repeat the isolation tests after every release that touches access.

Roles

Test each role a client user can have, and each internal role your own staff use. For a client admin, check they can manage their own users and only their own. For a standard user, confirm they cannot see admin screens or change settings. For a read-only user, confirm every action that writes data is unavailable, not merely hidden from the menu.

Test internal staff separately: what can support see, can they act on behalf of a client, and is that action recorded? Test role changes too. Downgrade a user, then confirm the new limits apply on their next action, not only after they log in again.

Documents

Upload and download real file types your clients use, at the sizes they will use. Check that files are stored against the right client, that names with unusual characters survive, and that unsupported or oversized files produce a clear message. Confirm that a file removed by one user is removed for the intended audience and not for others.

Check the document flow end to end: who can upload, who is notified, who can see a new file, and whether an older version stays retrievable if that matters to your process. If clients can share documents inside their own organisation, test that sharing stays inside it.

Notifications

Every message the portal sends is a place where information can leak or mislead. Trigger each notification and read it as the recipient: does it go to the right person, does it reveal more than it should in the subject or preview, and does the link inside land on the right record after login? Test the link when the recipient is logged out and when logged in as a different user.

Test the opt-out or preference settings if they exist, and what happens when an address bounces or a user is removed. Notifications sent to former users are a common and avoidable problem.

Devices

Clients will use the portal on whatever they have. Test the main flows on a phone, a tablet and a desktop browser, in the browsers your clients actually use, and at least one older device if your audience is likely to have them. Check that login, document upload and download, and any forms work with touch, and that tables and long text remain readable.

Include the practical details: a password manager filling the login form, a session that expires while a form is open, and a slow connection. Record the devices you tested, since that list defines the support you are accepting.

Failure cases

Test what a client sees when things go wrong: a wrong password, a locked account, an expired reset link, a record that no longer exists, a service that is temporarily unavailable. Messages should tell the client what to do without revealing whether an account exists or exposing internal detail.

Also test what happens when a linked system is down, if the portal draws data from one. The portal should say that data is unavailable, not show stale or empty information as if it were correct.

Data

Load realistic records, not five tidy ones: long names, missing values, historical items and clients with very different volumes. Check that numbers, dates and statuses shown to clients match the source, and that anything not meant for clients, such as internal notes, is not displayed.

Before real clients are invited, remove test accounts and test data, and confirm which real records will be visible to whom on day one. Loading real data is a step that needs its own check, not an assumption.

Sign-off

Record every test with its result, the tester and the date. Agree which defects block launch; any failed isolation test should always be one. List accepted known issues with an owner. Keep the test list as a regression set, and repeat the isolation tests whenever access rules change.

If your context requires independent security testing or certification, that is a separate piece of work to arrange; this checklist supports it and does not stand in for it.