April 10, 2011

Got a query today concerning User Acceptancy Testing (UAT) on SharePoint. As a SharePoint implementator, we know that the client needs to test the provision (your deliverables) of the SharePoint environment, based on exactly what they requested (the scope).

However, some may think that simply carrying out testing on just what the scope entails covers a full UAT.

Take this scenerio – the client is brand new to SharePoint, wants the product and needs to make sure that the team sites can store compliance data.

Do you UAT just the team site in terms of storing compliance data? No – the client doesn’t know SharePoint!

Another scenerio – the client is upgrading from SharePoint 2007 to 2010, wants the product and needs to make sure the team sites can store compliance data.

Do you UAT just the team site in terms of storing compliance data? No – the client needs to understand the nature of SharePoint 2010 against 2007 – they are not the same beast!

Of course, it all depends on whether the UAT is solely technical, or business oriented; for example, the UAT may simply be part of handing over support of the product into Business As Usual (BAU).

In anycase, UAT is perceived as something that guarantees the using the product of the product – the client is comfortable and convinced that the product does what it says on the tin. When implementing SharePoint you push the features of SharePoint; hence, you have documented standard sharepoint functionality. That must be conveyed that it works from a demonstratable perspective. Therefore UAT is required for standard SharePoint functionality.

That said, some clients might steer you away from this because in their view all they are interested in is the bits they asked for from SharePoint beyond what they ‘know’ / what they ‘think’ it does out-of-the-box. Beware of this approach since they may be assuming too little, too late.

In my experience I always UAT standard sharepoint since remember the element of training locks into this and it gives you invaluable insight into what the client expects to do with the product in their workplace. You should remind your client of this as it will instill in them the importance of understanding the nature of the beast!

You May Also Like…

SharePoint Copilot Governance and Beekeeping: A Buzz-Worthy Comparison

SharePoint Copilot Governance and Beekeeping: A Buzz-Worthy Comparison

🐝 SharePoint CoPilot Governance and Beekeeping: A Buzz-Worthy Comparison. In the world of digital collaboration, SharePoint is the hive—teeming with activity, rich with resources, and vital to organizational productivity. But just like a real hive, it doesn’t thrive on chaos. That’s where governance comes in. And oddly enough, the best way to understand SharePoint governance might just be… beekeeping.

Thoughtless SharePoint Site Provisioning: The Hidden Cost of Convenience

Thoughtless SharePoint Site Provisioning: The Hidden Cost of Convenience

In the age of rapid collaboration and cloud-first strategies, provisioning SharePoint sites has never been easier. But with great power comes great potential for chaos. When sites are created without proper analysis, planning, or governance, organizations often find themselves buried under a mountain of sprawl, broken workflows, and compliance nightmares.