It’s a fair question. Is it just so that your provider can charge you more support and maintenance, or are there real benefits to be had from running with Test systems?
Occasionally, we meet customers who might not benefit from a test system. But, more often than not, there are plenty of advantages to be had.
Currently, 44% of Keyfax customers run with one or more Test (or Dev or Training) Keyfax systems.
To answer this question for yourself, see if the following reasons resonate with you. These examples use Keyfax as the Repairs Diagnostic system, but the principles hold true for other similar systems too.
How often do you get a new version of your chosen Housing Management System (HMS)? When that happens does IT immediately switch all users across, or is there a phase of User Acceptance Testing? It’s likely to be the latter, followed by lots of UAT through the HMS Test system.
If your HMS is integrated with Keyfax, and there’s no Test Keyfax system, then you only have one option:
You’ll be keeping your fingers crossed that:
You would probably be alright. But if you want to mitigate all of those risks, there is a simple way forward. Set up a shiny new Test server and do all testing in a completely separate Keyfax environment. Then none of those items could apply. All of your live users are cocooned in a safe environment.
For similar reasons to the above, when a new version of Keyfax Repairs Diagnostics is available, it’s great to have a Test Keyfax system. Whilst we always thoroughly test any new Keyfax version, we can’t replicate every customer’s exact network set up. So, it makes sense to test the new version through a separate Test Keyfax server.
A Keyfax installation can’t (or shouldn’t) support two different versions on the same server. So, when a new Keyfax version is available, a separate test server is highly recommended.
This is the main reason we recommend setting up a Test server. In the diagram below, the server KEYFAX-TEST is an example. The colours show where the initial launch of Keyfax is made from the Housing Management System (or a tenant portal or MS Dynamics CRM) through Keyfax, which is updating the relevant database in the SQL Server;
More customers are embarking on a move to Microsoft Dynamics 365 as their Housing CRM of choice, too. Along with KeyNamics on the Dynamics server, we need to offer Keyfax Repairs Diagnostics in the DMZ too.
In the diagram above the KEYFAXOL-T server would be an example of such a system.
Some customers are happy that their test servers will only connect via http within the network, and don’t need to be in the DMZ.
But for others, having an identical Test set up to Live in the DMZ, is a must. That means setting up secure sockets layer (SSL) certificates and making the domain publicly accessible. E.g. https://keyfax.housing.org.uk
The advantage to this setup is that you can test end-to-end through the firewall and network setup required for the Live DMZ server. Any issues can be ironed out in Test, before cutting-over to Live.
Omfax can cater for either. These are ‘on premise’ servers and can be configured by your network team, however you need them to be, in line with your network and IT policies.
Some customers like to have separate Live, Test, Training and Development systems. If these systems are available in the host HMS, why not mirror them through all other services like Repairs Diagnosis and Job Scheduling?
We have customers with separate Live, Test, Training & Development Keyfax servers. Others are happy to have a single Live server and a separate Test server that supports multiple Keyfax configurations for Test, Training and Development. E.g. KEYFAX-TEST above would have multiple configurations.
Again, your repairs diagnostics supplier should be able to match a solution to your network & IT policies.
Keyfax comes with a built in Administrative Tools application for diagnostic script Administrators. If they are working on a diagnostic script that is not finished, or needs more testing before it is given to the Customer Service Advisors to use, then they can mark it as a Test script. The test scripts then appear with a yellow triangle to highlight the fact they are not yet live.
Then, when fully tested and ready to release to the users, the switch can be made.
Sometimes customers will ask if they can build a whole new repairs scripting structure. This is often something fundamentally different from their existing Live script set up. Hand-in-hand with this comes a requirement to ‘overwrite’ the Live scripts with this new set, once testing is complete.
There are a few ‘gotchas’ waiting for us when considering this approach. So, whilst this is rarely something we recommend (due to the non-trivial nature of extracting just the scripts), it is something we can do if customers can see no other way forward.
All of the examples shown above are for Keyfax installed on premise in your network. However, Keyfax can be offered as a hosted service on Azure. To test this set up (or indeed for version testing) within a customer’s own Azure environment, a Test system is a must.
Hopefully the above examples outline the main reasons why customers choose to have Test Keyfax environments. Perhaps the best answer to the question in the title of this blog might be another question:
“Why on Earth would you make life difficult for yourself by not having one?”
If you’re not running with a Test system, and you’d like to talk it through with someone, why not contact your Account Manager?