1) Test Often – SharePoint Designer doesn’t make it easy to test often, but it really is essential, for two reasons. One, you want your testing to be granular. The last thing you want to be doing is looking at a strange error after having made about a dozen changes to your Libraries, Lists and Workflows. Two, you want to re-test features after you have made changes, to make sure the changes didn’t affect your test results. In a systems development environment, you might have a test set to execute, but in SharePoint, well, you have you.
2) Start Over – One of the things that really complicates testing, is the degree to which SharePoint and Office are integrated. Don’t get me wrong, the integration is an awesome feature, but if your process involves metadata columns, you need to be aware that Office documents store those values. It may appear that your workflow is still working, but if you are reusing an old document during testing, Office may have set the metadata for you, even if your workflow failed.
3) Test Non-Obvious Options – Very often, when we look at the process we have built, we see it in terms of the requirements we were given, or the way in which we built the solution. We tend to forget that the user will be seeing it for the first time. What becomes a familiar path to us during development will just be one of several options to the end user. One of our users gave me a great example to illustrate this earlier this week.
We use theMuhimbi PDF Converter for SharePoint, to automate production of PDFs from documents in our library. We added this process to our workflow, but once Muhimbi is installed, users also get options on the Item menu to “Convert to PDF”. Whether you do the conversion in a workflow or manually, Muhimbi lets you choose the destination of the PDF you create. Once the PDF has been created, you are given the option to “Return” to the “Source Library” or the “Destination Library”. In our case we are creating PDFs in the same library as the source documents, so we assumed that it didn’t matter which one you choose. As you can probably guess, that isn’t the case. When working in a Document Set, if you opt to return to the Destination library, everything is fine. However, if you choose to “return to the Source library”, you are moved from the Document Set (a special type of folder) into the main library, but the Document Set header information remains visible. It’s quite the confusing screen, as it appears that the entire library has been added to the document set.
The ironic thing about the example above is that we would have discovered the error earlier if I had remembered suggestion number one. We tested the two options Muhimbi presents when we were working with simple documents in a library. We didn’t test those options again when we started storing documents in Document Sets.
My example illustrates one other fact about testing – if you don’t test your solution, your users will. When you find an error during testing, it’s known as a “test result.” When your users discover the problem, it becomes a “runtime error”; the choice is yours.
Note: In fairness to Muhimbi, in researching a different problem, we realized that they have just released a new version of their PDF Converter product. We have not yet installed the new version, nor have we discussed this specific problem with their Tech-support crew. I am confident that this problem will be resolved quickly.