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.
  • Test that MOVEit Automation users can log on to the product user interface and that their permissions are correct.
  • If any of your task processes send emails, test a representative sample to verify that MOVEit sends the emails correctly.
  • If any of your tasks use SSH keys for SFTP, TLS certs for FTPS, or PGP Keys, test a representative sample of the tasks.
  • Do the task and host lists seem reasonable, and have all of the tasks and hosts migrated?
  • Do the Resource items, such as Scripts, Date Lists, Keys and Certs, Global Parameters, and Groups and Permissions seem reasonable and complete?
  • Are the System Settings correct? Users generally leave these at defaults but if you made some customizations, you should ensure that they have 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 Certiicates, and SSH Hopst Keys are identical across all MOVEIt Automation nodes.
  • Testing in a Failover environment includes all of the above plus additional considerations that are addressed in the Failover topic.