There are a number of aspects to consider when performing UAT of a migrated WCM environment. This document outlines these areas and provides guidelines for customers to design their own checklist of items for UAT of their migrated WCM environment.
Portal Migration
Ensure you have verified the Portal migration as described in the Information Centre
Rendering
In validating the rendering of content in the new environment, the best check to perform is a visual check of the rendered pages, and a comparison with the v5.1 website.
The actual pages that are checked will depend on the requirements of each site and client. However, the following is a guide to consider when deciding what to be checked.
a) Include high-traffic pages and make sure they are rendering as expected. This includes the home page, any landing pages, and other pages that receive a large amount of activity, such as launch pages for main site areas.
b) Include some low-traffic pages and make sure they are rendering as expected. This may be any selection of other pages within the site, not necessarily the most obscure pages.
c) Include pages that will render some of the more used menu and navigator components. Validate that the contents rendered by the menus/navigators are the same as those when rendered in the 5.1 environment.
d) Include pages or areas that have anonymous access and make sure they are rendering as expected, both when logged in as a user and when browsing anonymously.
e) Include any pages that may render custom JSPs through a JSP component to ensure the JSPs have been put in the correct place on the new environment and are working correctly.
f) Include any pages (JSPs etc.) which make use of the WCM API and ensure that they are working correctly.
g) Test any integration with Portal Personalization, PDM and search.
These tests should be done as various users, not simply an administrator user. This allows checking of access to items and making sure that security of the items is the same as in 5.1.
If possible, it is best to compare these pages between the 5.1 environment and the 6.0 environment. That way a quick visual check can be done to compare the two environments side by side.
The ‘live’ access setting has been removed in WCM 6.0. If this was used in WCM 5.1 for determining who had access to the live pages, it should be determined what impact this will have, and testing should ensure that the correct access is granted for rendering pages. After granting the new access levels check that web-only users can not access the authoring portlet as a result of the changes.
These tests should also be performed with any caching enabled to ensure that the correct results are obtained.
Authoring
The authoring environment is another key area to test from an end users point of view. Some general tests should be performed to ensure that the content can progress through the normal authoring cycle. These tests should include, but not necessarily be limited to, the following.
a) Document creation
Test that a content item can be created as expected. Select an existing authoring template, create a test content item, and publish it to a site area and check that is appears. This ensures that access to basic operations using existing data are working correctly. Is a third party text editor used? Check that this is working as expected.
b) Test the repository views
Make sure that, as a user, you can see the items you expect to see by browsing through various repository views. Note that the All Items -> Published view is the slowest view. Its general use should be limited, and it should not be used for gauging performance of the authoring system.
c) Test workflows
Create test documents and move through workflows to ensure that th ey are working as expected. Actions include:
-
Moving to the next stage
-
Publishing
-
Creating a draft of a published item
-
Reject
-
Restarting the workflow
-
Any email actions that are used
-
Scheduled publishing/expiration, if used
As with rendering tests, these tests should not only be performed as an administrator user, but as various users with different access levels. The particular users to be used should be determined by considering a customer’s particular authoring process, groups involved, and security used (eg. workflow security as a document progresses through its workflow).
For example, if certain groups have access only to certain types of items (eg. only presentation templates and components) then users of these groups should be used, and their normal actions performed. If all users have access to all types of items, then this is not necessary.
Syndication
Syndication is a large part of any system, and so should be tested to ensure that documents are moving between the various environments correctly.
Tests should be run which confirm that the following types of items are correctly syndicated between systems:
-
New items (non-workflowed)
-
New published items
-
New draft items (new draft, or draft created from published)
-
Updated items (changes are syndicated)
-
Deleted items
-
Versions of items (where used and appropriate)
-
Moved items (item syndicated is in new location)
Some of these tests will not apply, depending on versioning settings and the item gatherer used (all items or all live items).
Data Migration
Checking that the data has migrated correctly and fully is not an easy task when migrating from WCM 5.1 to WCM 6.0. With the item count being different between the two versions because of changes to the data model used, this task is quite difficult.
Spot checks can be performed on various types of content to ensure that all items have been imported. For example, counting the number of menu components, presentation templates etc. However there are drawbacks with this method, since orphaned site areas (those with no parent in the 5.1 environment) are not imported into WCM 6.0.
Tools can be written to try to validate item counts using the WCM API, but as with the above method, concessions need to be made for various types.
Configuration
Since WCM configuration changes are not automatically migrated and entered manually these should be tested to ensure they have all been changed correctly.
These changes can include configuration of version control, caching properties and which item types have a workflow and profile information.
Post-migration changes
If Connect tags were removed, check the new implementation works
If a new search was written to replace the WCM search, this will need to be tested
If multiple libraries were introduced these will need to be tested along with any api code referencing the libraries
If anchor tags and urls were replaced with link elements, test these
If document manager was used for the storage of content, test the content can still be found in the new implementation
Other
If there was dual content entry during the migration, check that all the content added/updated in the old site since migration began has in fact been added a second time to the migrated site
If other websites link to pages within the migrated site, test the new urls (which the other websites will change to after the site launches) to ensure they will work
Run performance testing
Related Content
Maintaining content releases - Scenario 3: Upgrading WCM from 5.1 to 6.x
IBM Workplace Web Content Management V2.x to V6.x Migration Guide
Migration Central
Step by step migration guide - Migrating IBM Workplace Web Content Management (WCM) version 5.1.0.4 to v6.1