How many test workflows in a test environment before deploying them?

Hello Stephan,

this is a very interesting question. Personally I think there is no final answer to this. I think that the effort you need to put into testing in a testing environment is heavily dependent on risk and impact of your workflow and the data its working with. There are lots of simple task that make absolutely no sense to build them in a testing environment like basic approvals, notifications, easy decision workflows and so on.

But when it comes to sensitive data, loops, external data or data that others are depending on I always prefer to first build the scenario on your staging / testing environment. Lot of our customers share your point, that testing environments rarely reflect the production environment and it's hard to build valid test parcours there. I think thats the first thing to be changed. You wouldn't learn to drive in a bobby car. You need a real car to know what you're doing. Testing only makes sense when you have a testing environment that holds as much of the production data as possible and gives you the same infrastructure to work in.

It's not that difficult to achieve and I'd suggest you talk with whoever is responsive to fix this.

Kind regards,

Enrico

ah, the age old developing and deploying in SharePoint discussion.

Like many, testing environments are only "strictly" worthwhile if they are kept in line with the Live environment. 

I've always taken the approach, that if I'm developing a new application, I will develop that app in the Live environment, because, well, nobody is using it till the app goes live. Once I have got the app to a point where I'd happily call it 1.0 then I'd take the site collection back it up and restore it to my development environment.

With regards to testing, it's terrible practice to test your own work anyway, I'd be interested to know how many people get a dedicated test resource. I'm quite lucky in that I have a guy in my current place who's not a tester at all, but very methodical and thorough and has a good go at breaking everything I do before I send it on to UAT.

I've converted this to a discussion, as I don't think there is any real "one true answer" to this!

For myself.. I use a dev environment when working for clients on prem. They do UAT in the dev environment, so we don't push everything to a second area.

For internal - o365 - no dev enviro there. I test on a dummy lists and dummy AD groups and so forth.

many people here have suggested the right approach...use test environment for complex workflows and only then move to prod.

unfortunately my experience with this approach is very frustrating for reasons mentioned below:

1) Nintex workflow export / import is a good feature, but most of the time i see workflow actions like "Query List" loosing settings. We need to reconfigure the action once a workflow is imported to production environment. 

2) Nintex has issues with double byte characters. If a Nintex form (list based or within workflow) has any double byte labels, the text is garbled after import ! (I work with a lot of Japanese text). 

So i directly work on production for new workflow and sites and keep my fingers crossed 

if we already had a UAT on test environment then after importing the workflow to Prod i make sure at least one of my teammates reviews the entire workflow action by action ! (Yes painful...but better than losing data)

I created a subsite/duplicate lists for testing my workflows.  I actually have "test-only" actions that I can disable or enable as I need to (most of these are setting variables for people who are getting tasks later on in the flow).  This allows me to set all the critical variables to my own email address so when I execute the flow, I get all the email tasks as if I were the actual recipient.

It depends - always my favorite answer:) We have a QA environment for certain sites, so I use QA for building and testing Workflows, if there is one. For the sites that don't have QA I use a "Test Site" built specifically for testing InfoPath and Nintex workflows. I always do multiple test scenarios on my test workflows and then I also have at least two others test the scenarios - even more for complex scenarios. Just like Stephan, when I import the workflow to Production I have the original workflow open in one browser while I fix anything necessary in the Production version in the second window. I also test all scenarios again in Production (usually late at night or on the weekend) so I can fix the workflow and clean up the SP library before I announce the changes.