Blog
Running multiple Nexts for test or training
Every day I hear about companies that rely on their Next solution for business critical processes. Shut down Next, and within minutes no one has anything meaningful to do — expect talking to annoyed customers, partners, and suppliers, who have absolutely no understanding of why they can not get the services they have become accustomed to.
We take that responsibility seriously in Software Engineering — very seriously.
That is one of the reasons why every piece of software that leaves our labs has undergone a myriad of both totally automated and manual tests.
No matter how well we do our engineering — design, development, and test — we sometimes have a glitch or a bug in the product. Luckily it's mostly smaller inconveniences that are resolved without much impact to the business that runs on our software — and that's how it's supposed to be.
Undeniable risk
But even when we deliver spotless software, there is an undeniable risk in deploying new software versions to a running solution.
Your use cases, your environment, your adaptions, or even your data may all be just a little bit different from what we have been able to verify in all our rigorous testing efforts.
And it leaves us with a risk — it leaves YOU and US with a risk.
QA environment is recommended
We have always advised our users to establish a test or quality assurance environment in order to reduce this risk even further. Some have taken this advice and many have not.
The primary arguments being:
- We don't want to spend our time testing your software
- It's way too complicated and resource demanding
- It has gone all right until now
You are not testing our software
Just to clear this misunderstanding once and for all — you are not testing our software. We do that. And we do it well.
What you will be testing is your solution. The way your solution is setup, in the enviroment you have, and the way you use it.
As the Next product evolves, your solution may change behaviour. A minor fault in your configuration or integration may have no impact until a later version of the software rely on the configuration (or integration) to be correct.
No new bugs in the Next software, but still your users, customers, suppliers and partners are affected.
If your solution is mission critical, I simply can't see how you can do without.
Besides testing
One thing is to verify that a new version of Next does not alter the behaviour of your running solution. That is important, but rather trivial.
More important is it actually when you want to change your solution. Add new functionality or alter existing functionality. In my eyes the only way you can do that without jeopardizing your daily operation is by having a testing environment. And my experience tells me that your tests are both better and more comprehensive when you have a proper environment to perform them in.
And even more
And when we are at it. Once you have an additional environment up and running, you have the perfect place to perform end-user training, and for users to check out new features. In a live environment, but without any impact on production data.
It's not complicated
What was once complicated and quite resource demanding is now neither. In Software Engineering we have invested thousands of hours in reducing the system resources needed to run an instance of Next. Primarily of course to the benefit of production environments, but definitely also to those who want one or more QA environments.
The simplest way of establishing a QA environment is to install a new Next instance running on separate TCP/IP ports and with other datapaths.
Depending upon the number of documents it may or may not be convenient to copy documents from production to QA.
And from a configuration point of view you may now configure ports and everything so that you can easily deploy multiple Next instances on a single physical or logical server.
Things to remember
- Create a separate top-bar image that clearly indicates to users that this is the QA environment. You don't want someone to waste hours of work in the QA environment, or even worse make a mess of your production environment
- Configure capture process also for the QA environment. Email monitoring and scanning should be as easy in QA as it is in production
- Change mail notification from flow
- Change integration with backend system
- Create QA email adresses
- Create dedicated QA users with access
It takes a little work, but in most cases your QA environment will be up and running in less than a day.
Better safe than sorry
I'm not in Sales — and I never will be — but I have been told by my colleagues in Sales that the actual costs associated with a Quality Assurance License is next to none.
When that's the case, setting up one or two extra instances of Next for testing and training may very well be the cheapest insurance you're ever going to buy yourself.
Please reconsider, now that we have made it so easy for you.
And remember — it's so much better to be safe than sorry.
