This topic explains the importance of a test plan to validate your upgrade, what should be included in a test plan, and how to use the plan.

MOVEit Automation can do many things. The way your organization uses the system is specific to your use cases and configuration. Therefore, only you know what should be included in your test plan. Below are some test plan considerations for inclusion.

There are a couple of different ways to approach testing. The first is a high-level approach based on scenarios or use cases. This deals with how your organization uses MOVEit from a process and user standpoint. For example, what things does MOVEit do for you, and how can you test them? The second approach is at a lower level, examining various settings, task lists, host lists, etc. To be thorough, examine both levels with an understanding that no test plan will cover all cases.

Before you begin an upgrade, you should generate a list of things to test before and after the upgrade. You must execute this plan before and after the upgrade to ensure that you know your baseline before an upgrade and to confirm that all work flows are working as expected after the upgrade. Make sure to keep notes, sample data, sample report outputs, etc. during the testing phases for comparison.

Regular users must not have access to MOVEit during upgrade and testing. Access should be restricted until you are satisfied that the upgrade succeeded completely.

Ensure that you are aware of the state of the MOVEit scheduler during testing. To prevent tasks from running during testing, the scheduler should be disabled. In general, tasks should not run automatically until testing is satisfactorily complete and the server is ready to be promoted to production. This is particularly true if the older server is still in production.

While you can turn the scheduler off in the MOVEit Web Admin user interface, the scheduler always re-starts after a system reboot or MOVEit service restart. To prevent this, select the Start with scheduler disabled check box in the General Tab of the MOVEit Automation Configuration Utility, or disable tasks individually or as a bulk action.

As your tasks may have downstream effects on other systems that you do not control, you must ensure that your testing does not inadvertently impact production processes until you are ready to promote your new server into production.

Tests to consider

  • The primary function of MOVEit Automation is to run tasks that move files. Therefore, you should decide on a representative sample of tasks (or all) that will give you confidence that the system is working as expected before and after an upgrade. A major part of this is testing that MOVEit Automation connects to the required hosts with the correct protocols.
  • If a task cannot be run because of production implications, at a minimum, you should test the hosts associated with the task. Each host has a Test button on the host configuration dialog. For more information, see Tests Performed on Hosts. For a more real-world test of this host, It may be possible to run a similar task on the host using non-production data to or from temporary directories.
  • If your configuration includes sync tasks, test a representative sample of those tasks.
  • Verify that MOVEit Automation users can sign in to the product interface and that their permissions are correct.
  • If any task processes send emails, test a representative sample to verify that MOVEit sends the emails correctly.
  • If any tasks use SSH keys for SFTP, TLS certs for FTPS, or PGP Keys, test a representative sample of the tasks.
  • If any tasks use built-in scripts, such as PGP Encrypt/Decrypt or Zip/Unzip Advanced, test a representative sample of those tasks.
  • Confirm that the task and host lists are complete and that all expected tasks and hosts were migrated.
  • Do the Resource items, such as Scripts, Date Lists, Keys and Certs, Global Parameters, and Groups and Permissions seem reasonable and complete?
  • If any tasks use macros or global parameters, test a representative sample of those tasks.
  • Verify the system settings. If you customized any settings from their defaults, confirm that the customizations were migrated correctly.
  • Examine all scheduled tasks to identify and resolve any overlapping schedules that could lead to unexpected behavior.
  • Compare a sample of reports: Task Run, File, and Audit, and save the XML output. When the new server has first been upgraded, those reports should be substantially similar between old and new, although they will start to diverge immediately after the upgrade, as the new server starts to do things on its own.
  • Ensure that MOVEit Automation Server and MOVEit Automation Web Admin services are running in Windows Services.
  • If you are a Java, COM, or REST API user, ensure that you install the updated API version on the server where you run the API. This could be the MOVEit server or another server, depending on your environment.
  • In environments using failover, confirm that PGP Keys, SSL Certificates, and SSH host keys, hosts, and tasks are identical across all MOVEit Automation nodes.
  • In environments that use failover, verify that failover operates correctly by failing over to the secondary node and then failing back to the primary node.
  • Testing in a Failover environment includes all of the above plus additional considerations that are addressed in the Failover topic.