Client Portal Acceptance Test (QA)

Client Portal Acceptance Test (QA)

1. 01

   Freeze the build and tag a release candidate before any tester touches it

   Record the platform version and app snapshot so defects can be traced to a specific build rather than a moving target.

2. 02

   Write acceptance criteria from the signed scope, not from what got built

   Each criterion should name the user, the action, and the expected result so a client reviewer can mark pass or fail without interpretation.

3. 03

   Run permission tests with real client roles, including the read-only and external guest accounts

   Portal work fails most often at the boundary between internal staff and client users. Test every role against every screen, not just the admin view.

4. 04

   Load the largest realistic dataset the client expects in year one and time the slowest three screens

   A portal that responds in 400ms on 50 records can stall on 5,000. Capture timings and attach them to the acceptance record.

5. 05

   Verify every integration against live endpoints and log the failure behavior when a source goes down

   Confirm what the user sees when Airtable, HubSpot, or a payment API returns an error, and whether the app degrades gracefully or shows a blank screen.

6. 06

   Check accessibility on the primary client-facing flows: keyboard navigation, contrast, and form labels

   Client portals carry the agency's brand, so a portal that fails basic accessibility becomes the client's problem and then yours.

7. 07

   Confirm data ownership and export paths before sign-off, including who holds the platform account

   Document which entity owns the workspace, what a full export contains, and how long restoration would take if the relationship ends.

8. 08

   Get written client sign-off against the criteria list and file it with the delivery record

   Sign-off against named criteria converts an open-ended expectation into a bounded acceptance, which protects the retainer when change requests arrive.