• Use end-to-end release test scenarios.
• Test all aspects of the imported solution.
• User testing for business data issues.
• Burn-in testing.

End to End

Use end-to-end release test scenarios. Definitely use end-to-end testing, because you can’t be sure that a link to an imported file is valid, until you’ve actually launched the thing. Launch from links, navigate DM and launch from DM.

Test everything

Test all aspects of the imported solution. Metadata creation, network cleanup, metadata cleanup. Application integration

Write tests for the metadata import – same principles.

Write tests that look for the problem scenarios on the network you think you’ve eliminated (i.e. with a network cleanup sub-project)

Write tests that look for the pre-existing files (in the DMS) you think you’ve migrated. (i.e. with a DMS cleanup sub-project)

Define a functional smoke test, beyond the scope of the actual file import. Create, update, search, launch. Exercise the security.  Make sure that applications are correctly integrated.

Involve the User

If you have a very tolerant user DMS champion, involve her in verifying the requirements against the first representative imported set of files. This may help eliminate any expectation mismatches regarding what is to be delivered. A real user will also detect problems in metadata assignment that were invisible to IT or consultants.

Burn-in testing

Leave time after the formal release testing for users (or user representative like the director of IT) to kick around the system and find unforeseen problems. This might have helped uncover the .HTM error, or the folder permissions error.

Reading more

This article is part of a series discussing many aspects of content migration from an unstructured storage system to a document management system. The overview page is here: Content Migration to a DMS – Articles.