Test environments are extremely important with a product as versatile as ImageNow / Perceptive Content. A number of issues can occur without proper testing prior to implementation. The following is a number of common issues that occur when testing in a test environment was not carried out prior to upgrading/updating ImageNow / Perceptive Content, or related components.
ImageNow’s database is vast and complex. Each update of ImageNow generally comes with an update script for the database. There are currently 101 different Incremental scripts for ImageNow, with more rolling out every update. The scripts look very similar, and it is very easy to miss one, or to run an incorrect version. Doing either of these things will cause untold amounts of instability within the product, as the database will not be at the correct version to interact with the software. In a test environment, the correct script should be singled out and prepared for your production environment, so that there is no chance of confusion once implementation begins. This also gives you a chance to review in case you have added or changed the DB tables in any way, to ensure those changes will not adversely affect an updated version of ImageNow.
There is also a chance that the new version of ImageNow has changed in a way which would cause either programmatic issues, or end user confusion. For instance, Applets in older versions of ImageNow are now called Application Plans. This change could potentially cause both confusion with the name change, as well as possible issues with the previously learned applications, since the engine which learns the screens has been updated so dramatically.
Not all of these changes are bad situations. There is also the good possibility that new features have been added that might greatly speed up the process of your daily documents. These features would have to be reviewed and your current processes adapted to the new abilitys of ImageNow. In this instance, the test environment not only saves you time, but allows you to actually make dynamic changes, as well as decisions on whether or not you wish to adapt these new features. Maybe you as an administrator thinks this new process would be helpful, but during testing the end users decide it’s not as efficient as the old method. It’s better to figure this out in test, than to implement and have unhappy end users, forcing them to adapt, or forcing you to rollback.
Supporting software issues:
Internet Explorer, Firefox, Java, and several other programs typically interact with ImageNow. Prior to updating any of these programs, it is a good idea to test them out in a test environment. For instance, if you have IE8 and are using an IE learnmode within ImageNow, and you update to IE9 without first testing, you will likely discover that your learnmodes are broken and will require re-learning the screens. This can cause days worth of work outages due to the inability to use the primary functions of ImageNow until these issues are resolved.
Human error(this one’s for other companies, not yours of course):
Human error is also a large factor when dealing with a software solution as complex as ImageNow. There is a good chance that the development won’t go 100% according to plan on the first shot. Also, the dev can go as planned, however, the outcome might be different than expected. Generally these issues are very simple and quick to resolve, but finding the root cause of the issue sometimes takes a while. It’s best if these issues are weeded out by testing in a test environment as well, as to avoid production outages.