A SharePoint launch test should prove that real people can find, read, edit and recover the content they need with the permissions they are meant to have. It should not be a tour performed only by the site owner.
The safest approach is a small test matrix: important journeys down the side, representative user roles across the top, and an expected result for every cell.
Start with a testable release
Record the site URL, owners, intended audience, supported devices, custom components, connected flows and the date of the test. Freeze non-essential changes while user acceptance testing is under way.
Use a non-production site where a test could send notifications, change permissions or alter business data. Production-only checks should be read-only unless the owner has approved a rollback plan.
Create representative accounts for:
- a site owner
- a member who creates or edits content
- a visitor who only reads
- an external guest, if guest access is part of the design
- a person who should have no access
Do not test everything as a Global Administrator. Elevated access hides the faults ordinary users will meet.
1. Test permissions, including denial
For each role, open the site in a separate private browser session and test the actual journey. Check the home page, navigation, libraries, lists, search results and shared links.
Microsoft explains that group-connected team sites normally map Microsoft 365 group owners to site owners and members to site members. Communication sites use SharePoint Owners, Members and Visitors groups. Read the current SharePoint sharing and permissions model before treating those patterns as interchangeable.
Test the negative cases too. A visitor should not gain edit controls. A former project member should lose access. Audience targeting is not permission enforcement, so verify the underlying item or page permissions.
2. Test content and everyday actions
Use a small set of disposable records to test:
- create, open, edit and delete a list item
- upload, edit, rename and restore a document version
- publish and revise a page
- filter and sort the views people rely on
- follow each navigation and Quick Links destination
If approval, retention, sensitivity labels or Power Automate are in scope, test each one separately. A successful flow run does not prove that retention or access control is correct.
3. Test search with known evidence
Choose documents with distinctive titles and contents. Record when they were added and the queries expected to find them.
Search can take time to reflect changes, so distinguish an indexing delay from a permission failure. Test as the intended reader, because search results are security trimmed. If a result is missing, confirm direct access to the item before changing the search schema.
4. Test pages and custom components
Open the key pages in the browsers and screen sizes your organisation supports. Check responsive layout, focus order, keyboard access, image alternative text, headings and colour contrast.
For SharePoint Framework components, test on a real SharePoint page. Microsoft's SPFx Debug Toolbar guidance explains why the workbench does not cover every page and extension scenario.
Run Microsoft's Page Diagnostics for SharePoint on important site pages. It compares a page with Microsoft's rules and surfaces likely performance problems. It is not a capacity test and it does not work on SharePoint system pages such as library views.
5. Test integrations and failure paths
For each flow, web part or external system, record its owner, connection, trigger and recovery action.
Then test missing input, a user without connector permission, a duplicate submission, an unavailable dependency and an expired connection. Check that a failure is visible to the person who can act on it.
6. Run user acceptance testing
Give users jobs, not instructions such as “click every link”. Ask them to find a policy, publish an update, collaborate on a document or request access.
Record the expected outcome, actual outcome, evidence and owner. Separate defects from enhancement requests so the launch decision stays clear.
7. Agree the launch and recovery decision
Before launch, name the person who can stop the release. Back up configuration or source packages that can be restored, and document how to disable a custom component or flow.
A completed checklist proves only what was tested with those roles, devices and data on that date. It does not prove future availability, regulatory compliance or safe access to content that was outside the sample.
If you look after SharePoint sites and want a practical second opinion on the test matrix, join the SharePoint & Teams Admins Space.