Testing Software Changes Before Use

At some point you are going to want to change your software, upgrade it to a new version, or migrate to a different package.

In all of these cases, you need to test the new setup, to make sure that it is working the way that you want with your existing data.  This needs to be done in a test environment before the actual live system is changed.  A test environment is conveniently created with a new company on the same server or the same company on a different server.

One big point, is that everything that you use needs to be checked in this test environment.  Ideally, the two are run parallel for a few days to make sure everything is operating correctly.  While this means a duplication of work, it can be time saving in the long run.  A simple test plan should be constructed to include the following topics:  (this is not a complete list rather a high-point list)

• All daily usage cycles: opening, common functions, closing.  Make sure a user in each group tests all the functions commonly used: POS, Inventory, Sales, back-office, and any others.
• All communications functions: card authorization, address verification, mobile users, and any others.
• All printer functions: thermal, matrix, labels, bar-code, report, and any others.
• Trial end-of-month and end-or-quarter
• Backup and restore functions.
• Security should be checked for breaches introduced.   You can use several open-source or commercial software products for this, such as Microsoft Basic Security Analysis.

Too many times a new system is "spot checked" instead.  By this, I mean that certain pieces are checked, and if they work as expected, it is assumed that the rest will.

This week, I once again had a customer take this approach on a somewhat major change to their system.  In this case the print subsystem was completely changed.  They checked many different parts, but sure enough there was an issue with their label printing.  They had not checked the labels, and assumed it would work.  This meant that there was a scramble to work out the issue with their labels.

Ultimately, they decided that they can work with the existing setup for now, while the labels are changed to high speed thermal printers, from their existing dot matrix ones.  While this will result in a better end product in the end, for a couple of days they have to put up with a small annoyance using their old printers.

If they had taken just a little more time in testing, this anomaly would have shown up then.  Which means that it would have been dealt with before changing their live system.