This section helps you create a test plan for validating your MOVEit Transfer system.

Note: It is best practice to test and validate your upgraded MOVEit Transfer system before you "roll it live" to general users. Verify the state of the upgraded system with tests, selected internal users, and scripts that perform standard use cases before you make the system "live" (generally available as a production service to users on the network).

The controls that enable how your organization uses the system is specific to your site policy and the use cases you choose to accommodate. When available, refer to your documented policy, use cases, and operating procedures to best understand what should be part of this plan. The section that follows provides some general guidelines and questions that will help you.

Testing Approaches

There are a couple of different ways to approach testing: the first is a high-level approach, based on likely scenarios or end-to-end use cases. This deals with how your organization uses MOVEit from a process and user standpoint.

Know Your Site Requirements

What end-to-end scenarios do you use, and how can you test them? You can also look at network access settings, user counts, file counts, and so on. It is good to examine both end-to-end contexts (task-based, for example, Automation user or scripted user sending a package) and low-level contexts (individual pieces of functionality, for example, IP Access Rules defined and working as expected) contexts to get the most reliable results. Practically speaking, no test plan will cover all cases.

Use a Mixture of End-to-End Tests and Unit Tests

While planning your upgrade, take time to generate a list of use-case scenarios and end-to-end workflows to confidently validate that your system is upgraded and working with the policies and functionality you expect. It is critical to exercise use-case scenarios before and after your upgrade.

Isolate while Upgrading and Testing

You must ensure that your regular users can’t access MOVEit while you are upgrading and during the testing phase. You only want to allow users to sign-on once you have exercised your test plan and are satisfied that the upgrade completed successfully.

Sample Testing Criteria and Guidelines

The following list provides some of the many things you can look for after your upgrade and before you push your system into production (general availability).

  • Using the sysadmin account, check the list of organizations (ORGS tab).

    • Is the Orgs list what you expect?
    • Is the Orgs list correct?
      Note: The System Org is a built-in default used by MOVEit Transfer.
  • Using an administrator sign-on to the Web UI, do the following areas seem reasonable:

    • The user database: is the content of this list the same?

    • Files and folders: can you traverse the directory structure, and does it seem reasonable?

    • Custom settings like password expiration policies: are they present?

    • Is the list of reports complete?

  • You should run a few basic reports that show some high level indicators of the data on the system. Reports you might want to run before and after the upgrade include:
    • User Status->List for Auditors
    • Storage->Storage by User
    • Storage->Storage by Folder (if your folder structure and file count is not too large).
  • Can your users access MOVEit from places they normally connect and sign on from and perform a cross-section or "sample" of their normal tasks, such as upload files, download files, or send packages? (Try to sign-on both from internal networks and when allowed by policy external networks.)

    • Create a few test user accounts profiled similarly to the way your users are configured, including permissions and group membership, so you can have tests that exercise these policies, permissions, and group membership.

    • Can users sign on using the WebUI from internal and external network?

    • Can users sign on using an SFTP client from internal and external network?
    • Can an "externally authenticated" user, such as cases where Single Sign-on (SSO) using SAML is available, still access MOVEit Transfer as expected.
  • Do you have other automated systems, such as MOVEit Automation that login periodically to transfer files, and are those functioning as expected?
  • Do you have clients, scripts, or processes that use APIs? Be aware that expected API functionality you observed when you first deployed these scripts or applications might be differ with the current capabilities of the REST API.
  • Do you have custom client applications, scripts, or processes that include DLL, object, or class references to legacy MOVEit Transfer API libraries? Test these for expected behavior. For new installations, you can find the most up-to-date library objects in C:\Program Files\MOVEit\API.
  • Are email notifications and Ad Hoc Packages sent from MOVEit as expected? Do they include any customizations made to the email templates.
  • If you utilize MOVEit’s Ad Hoc functionality from the WebUI, can your users send and receive packages?
  • If you utilize MOVEit’s Ad Hoc functionality from the MOVEit Outlook Add-in, can your users send and receive packages?
  • Do you have a customized look-and-feel for the WebUI? Are those customizations visible on the new server?
  • If your server is publicly accessible and you have a valid TLS certificate, does the new server properly use the certificate so a web user of your system does not get any security warnings in their browser?
  • Similarly, if you use SFTP, are there any SSH Key issues when doing a test connection?