Skip to main content

Development

QA Solution for SharePoint Upgrade

1. Goals for testing upgrades

As SharePoint gets stronger and stronger, SharePoint Online and SharePoint 2016 have more new features and abilities. Enterprise can provide more functionality to business users with less customization and at a lower cost. According to the upgrading solutions, QA strategy needs to ensure that sites are upgraded seamlessly at first, then new OOTB features can leverage existing customizations in a more efficient way and satisfy new business requirements.

To reach this goal, you should find out:

  • Customizations that you keep in your new environment, so that you can plan for how to deal with them during upgrades.
  • Customizations that you plan to replace with new OOB features, so that you can plan for how to deal with risks of retirement and functionality differences.
  • Authentication applications that you plan to integrate with SharePoint, so that you can plan for user permission and user picker verification.
  • Site Collection lists that will be migrated to SharePoint 2016 or kept in existing environments, so that you can plan the schedule for different site tests.
  • Performance requirement of the whole SharePoint farm.
  • Integrated systems that affect the functionality of SharePoint.
  • SharePoint Upgrade/Migration tools that will be applied, so that you can plan how to use these tools for QA work, like Sharegate.
  • Team and related business owners that SharePoint upgrade will involve or effect, so that you can plan how to collaborate with them during the upgrade and final cutover.

2. Steps to verify upgrades

After you set up the new environment for SharePoint, you can transfer all the settings and install customizations. The main steps are:

  • Identify customizations and install them on the farm.
  • Verify upgraded and attached database if it is for the SharePoint Farm.
  • Verify customized features, which is often the most complicated part.
  • Verify upgraded site collections and sites with list/libraries, pages and so on.
  • Verify integrations with the third-party applications.

Before the formal site collections and sites upgrade, perform a trial upgrade on a test farm first. Examine the results to determine the following:

  • Whether the service application data was upgraded as expected
  • Servers, Web applications, Services, Service Applications which are configured correctly and up and running
  • The appearance of upgraded sites
  • The time to allow for post-upgrade troubleshooting

2.1. Identify and verify customizations

Export all the solution and customizations to a list and identify the source of the customizations, if possible. For example, are there third-party add-ins or features that were customized in-house? If you identify the source, you can check the upgraded version for SharePoint 2016.

For customized features, we need to identify following points so that you can plan to deal with them during the upgrade.

  • Solutions – by default legacy solutions are deployed, they will have less risk, as its assembly structure and resource dependencies are not changed. If the legacy solutions need to be reorganized, it is important to define the classification rules and identify all the dependencies.
  • Functionalities of customized features and dependencies among them.
  • Review what’s new and changed in new version of SharePoint too, and review the source code of customizations to adjust them accordingly if the change is major.
  • Usage of customized features – it helps you look into the behavior in SharePoint 2013 and their business importance. Sometimes, you could find specific features are never used.
  • Potential risks of upgrade or dismission.

The customized features need to be verified in different sites to cover business scenarios. Then it can be verified with a smoking test in other upgraded sites.

2.2. Upgrade database and verification

You cannot achieve your testing goals unless you use your actual data. However, this might not always be a realistic option for initial testing. You can assemble a subset of data from representative sites in your environment. If you want to first test by using a subset of your data, be sure that the subset has the following characteristics:

  • The data subset contains sites that are typical of the sites that you support in your environment.
  • The size and complexity of the data subset closely resembles the actual size and complexity of your environment.

Verify upgrade status for the database:

  • Use the upgrade status page in central admin
  • Review the log files to look for errors and warnings
  • Validate the upgraded environment, including service applications, site collections, search and so on

2.3. Upgrade and verify site collections and sites

The issues of site collections and sites must be identified before you upgrade your production environment. Review your upgraded sites to fix any issues with content, integration, styles, and features. The following checklist can be followed and can tell how to address verification.

  • Customized Features
  • Web Parts
  • Branding and styles
  • Timer jobs
  • PowerShell Scripts
  • Feature and Event Receivers
  • Logging and Analytics
  • User Permission Matrix
  • Key properties of Site Contents (Lists/Libraries)

To verify basic functionality before the site collection upgrade, you could create a new site collection by using a representative set of lists, libraries, Web Parts, and so on. Review the new site to make sure that the common, basic elements of your sites are working.

3. Testing Tools and Automated Testing

Commercial Tools

There are multiple commercial tools for SharePoint Migration. Take Sharegate as an example. It can provide a user permission matrix, list matrix and so on. Testers can develop some macro code in excel to finish the matrix comparison. However, the license of Sharegate is not free.

Automated Testing with Scripts

If you don’t have a budget for commercial tools, SharePoint also provides a client-side object model (CSOM) to retrieve user permissions, properties of lists and libraries. The script can be executed on .Net platform without the SharePoint environment. But if your SharePoint has been integrated with SSO application, like OKTA, you need to get authenticated context firstly, using PnP authentication Manager or Web Client Context.

Anyway, automated testing with scripts or commercial tools is recommended to verify user permission and properties of lists.

4. Conclusions

Generally, customized features are the most complex part, as they have special and complicated business requirements for different enterprises. Site content verification can refer to some automated testing tools or scripts with CSOM. OOB features are not the scope of verification, as it has been verified by Microsoft team.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Cathy Zhang

More from this Author

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram