- Use end-to-end release test scenarios.
- Test all aspects of the imported solution.
- User testing for business data issues.
- Burn-in testing.
Use numeric tests to find omissions based on unexpected causes. There should be 28 files in the A folder, 61 in the K folder, 4 in the Z folder. Write scenarios for both happy-path and exception. Check for things that are too long.
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 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.
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.
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.