When a form is migrated from one environment to another, we need to run validation tests to ensure the migration was completed successfully so that we can release the environment to testers and make adjustments to the migration, if needed, to support a fast and clean migration to Production.
I recently wrote an overview for one of my projects and thought it might be interesting to share it here, slightly generalized.
Initial Validation Tests
Running some initial validation tests can help identify migration issues. I like to start with the initial tests because I’m usually impatient to see if the migration was successful, and the fastest way to get a broad sense of that is to just run a form. However, these could be run after the setup table validation if you prefer.
Form Setup Validation – a quick way to ensure the form setup values moved over correctly (at a high level) is to initiate a form. (This isn’t a test of every page and value, though I’ll generally click around a bit.) If the pages or fields aren’t behaving as expected, it’s likely there is a security or setup issue to be identified.
Routing Validation – if a form has routing in place, initiate a form and verify it routes to the expected user(s) to broadly validate the routing and roster setup moved over correctly. I also use this chance to log in as the approvers and validate they can access the form through any path they have. This is a good time to try recycling and resubmitting as well.
Emails and Links – if notifications and worklist items are set up for the eForms, verify these are working correctly. If emails are not triggering but the eForm setup looks correct, it could be that the User Profiles do not have valid email addresses (they are often masked in a test environment) or that the environment has some code or setup in place that is stopping the emails from firing. Ensure approvers can access the forms through email links, if appropriate, and ensure worklist items are appearing and disappearing off of worklists as expected.
Integration Broker (IB) Validation – if a form triggers an update to information in PeopleSoft, then the IB is generally involved. There are times that the IB in a new environment is not yet running; it may need to be configured or bounced.
To check this, process a form that will trigger an update to the database. Verify that the update happens and verify that the form was updated to an ‘Executed’ status, if appropriate.
If there is an IB error that was planned for, process a form that will trigger that error and verify the outcome (form status and any notifications that should fire.)
Verify Setup Table Values
Data Mover Scripts are generally involved in moving the setup table entries from one environment to another; this is where we verify the information made it over cleanly and completely. That means verifying all of the values exist and making sure they are populated correctly.
Queries are a great way to speed this up. If the tables are identified, queries could be written to pull the values from each environment so the data can be quickly compared on spreadsheets.
I’ve listed some examples, but the full list should include all PeopleSoft, GT, and custom tables that are used to create and drive the eForms being migrated. Most of the tables can be found under the Manage GT eForms menu, though there are a couple PeopleSoft tables that are generally used as well and should be noted for validation.
Framework setup tables are those tables that are delivered in our framework (or already exist in PeopleSoft) and are used to define and drive the eForms. Examples include:
- Defined Rosters
- Email Templates
- Attachment Administration
- Form Family
- Form Installation Table
- Create/Update an eForm
- AWE setup tables – existing PeopleSoft tables under Enterprise Components
- Message Catalog – existing PeopleSoft table
Custom tables should also be verified. Though they aren’t always necessary, custom tables are sometimes created to support a form. Those custom tables can generally be found under a menu heading like “eForm Solutions Setup”.
More complex forms may have additional functionality that I’ll test for at this point. Once that is done, we’re usually at a place where I’m comfortable with what was moved and happy to invite others into the environment to start testing!
