Best practices for testing, development and production environments

As I am sitting here working through one of our integrations, all I can think is how badly I want to throw my computer. The situation I am in could have easily been avoided by simply following best practices for testing environments.

Unfortunately, my situation was beyond my control as the powers that be didn’t negotiate well on the contract with our vendor, and I wasn’t even made aware of the purchase until the deal was done. Which brings me too best practice number 1.

1. Bring the right people to the table from the beginning

There are many aspects involved in integrating one piece of software with another. For this reason, whenever you or your organization are looking to purchase software you should have at a bare minimum: the person negotiating the contract, a member of the integration team who will build the initial integration, a member of the support team who will respond to bugs after the integration is deployed, and a member of the network team to ensure compliance and security concerns are realize.

2. Test and Dev environments should match production

This is the problem I am having right now. I am trying to test an integration against a testing environment that hasn’t been updated in 4 months. In my case, our contract only allows the sandbox to be updated twice a year and there are no available updates at the moment.

If my company had followed best practices for testing then I would have the capability to test my results against production and gain confidence in the integration. Unfortunately, my results will never match production results because it is not possible to have my testing environment match production. This is what happens when operations managers are allowed to make major software purchases without the partnership of the IT department.