Testing

Test all aspects of the new configuration. Ensure that the basics are well implemented and solid.

It is important that the first user-experience is a positive one. If some of the basics are not tested, or the user-experience is not right, this will be a barrier to adoption to the new platform.

When moving to a new tool, there is often new configuration and new patterns of work that will be implemented, or become available.

How to configure for testing

There is no single-way to test software configuration, however the following principles / ideas may be helpful.

Use a “test-only” database

Configure a duplicate “test only” instance. This test instance of the software can run against a test-only database, and potentially on a test-only / dev environment. The thing to watch out here is that any automation, or email/communications that are sent out need to be sent to a “test-only” email account, so that you don’t accidentally “spam” users/staff members with test indicents, problems, changes, and approvals etc.

Create “test-only” accounts in your live database

Use these test-only accounts for testing purposes. They have test email addresses, test options set and other meta-data that allow you to test configuration settings under a specilaized test account.

Label test jobs etc with the words “TEST ONLY - PLEASE IGNORE”

If testing is done on a live, or test-only instance, but it still has legitimate email addresses, or notifications that may be sent out, by adding the words “TEST ONLY” to the subject, detials, or other parts of the objects, this will give any recipients of an email or alert the heads-up that it’s just a test job.