Skip to main content

Hi Guys

Wondering what your approach is to testing of your environment and forms/workflows following an update to SharePoint platform or Nintex or any other add on?  Do you do the same testing for each?  How do you ensure that the update gives you the new functionality at the same time of being confident it hasn't broken anything else?

‌ do any of you have a standard process?

I help many clients to setup a Dev Ops scenario so that usually there is at least a Dev & Prod SharePoint farms when on prem. This allows them to not only develop workflows and test theories without affecting prod, but also to install updates to Nintex or SharePoint and test BEFORE updates in prod. Pre-testing is the best approach. 

If you have only a prod farm and use a separate site collection(s) for development then you need to have a rollback possibility for updates that go bad. This is very difficult because you can't only do a SharePoint backup/restore as database schemas are changed and the Nintex database schema was updated, and the DLL files were updated. So you need a whole server restore.

But, I've found that most issues I've ever had post deployment of a Nintex update was with JavaScript code in forms that were not compatible, or workflows that all I needed to do was republish and they began to work again.

It is very difficult to test EVERY process you have, especially when you have to test prod data and people can get emails. The best you can do in this scenario is know your environment, know your inventory, so there are no surprises as users get back to running them again. Sometimes you know if there is a process going to go wrong, it's "that" one. So you can focus on it. If anything, smoke test a few workflows and even have a workflow that is just for this purpose that sends you an email, pauses, then sends another email. If it gets through that then the timer service and jobs are up and running.


Reply