SharePoint Development Integrators - Handover Quality Checklist

On a regular basis internal SharePoint teams who do not have the capacity to develop inhouse due to not have the relevant resources etc. will often get an external Integrator to build their solutions. This checklist should guide Development Managers on what checklists to run through before signing off on development work. Ideally this checklist should be provided to the external Integrator before the project starts so they know they are dealing with a party who takes testing serious.

SP Dispose Check Tool Pass

Microsoft have released a tool to enable you to check that the managed code is disposing of the objects properly in the object model. For more information on the tool see When to Dispose SharePoint objects.

Tips

• On receiving the code it takes a matter of seconds to fire up the tool and check it...see How to integrate SP Dispose Check into Visual Studio Solutions

Full source control and Deployment Instructions

Like any external developed solution that you have paid to get implemented, you should request the source code incase you wish to modify this internally or do not want to be dependent on that integrator to make changes.
The source code should be build and should include the ability to have it up and running in a vanilla SharePoint environment with the required dependencies of the solution.
Part of the review of the source control should be to test that building the source and deploying to your vanilla environment following the Deploying Instructions provides a working solution.

What to watch out for

• Often integrators will not provide all the dependent files:
  • javascript files
  • images files
  • web part configuration properties
  • missing 3rd Party wsps/dlls e.g. log4net, Enhanced Content by Query Web Part
• Often integrators will not provide all the dependent steps for deployment:
  • changes to web.config required (SafeControl entries, .NET 3.5 additions, log4net additions)
• Some will also not provide the functionality to build a WSP Solution Package to deploy this to an environment and will have lots of convulated scripts that will do exactly what a WSP will do but in a customised format.

Tips

• Don't let the integrator deploy it to your environment. Let your internal SharePoint Administrators do this to ensure they follow the Deployment Instructions to ensure they are complete.

Proof of testing / Quality assurance

It is a sad fact that many developers, both internal and external, do not take quality assurance serious. Therefore it is advisable to ask the integrator to provide proof that they have carried out proper testing. An example of such proof is a set of written test cases as well as an overview of the test results.

Specific tests to look for:

1. Regular functional tests: Has the system been tested to prove that it matches the requirements documentation?
2. Deployment tests: Has the deployment process been tested on an environment that matches yours?
3. Localisation tests (if applicable) Does the solution work properly for users from different countries (Date, number and currency formats)? Is all text stored in resource files?
4. Data Validation tests: Have they tried inserting unexpected / incorrect data in all fields?
5. Exception handling and logging tests: Are errors reported to the user, are exceptions logged to the event and SharePoint trace log?
6. Negative / edge tests: Have they tried 'tricking' the system by using it in a way 'normal users' would not use it?
7. Scalability tests: Have they carried out any load testing?
8. Security tests: Have tests been carried out to make sure the various users can only access the information / functionality they are entitled to? Have all tests been carried out using a regular domain user rather than the Tester's / Developer's administrator account
9. Depency test should also be carried out, what does the solution require to function, is this documented. Stop and think, worse case, tomorrow the data centre floods, what do we need to redeploy this solution. Everything you can think of in this scenario should be a deliverable from the integrator.

   External References

• MSDN - Sample code acceptance checklist for IT organizations
• SharePoint Development Best Practices - Checklist by JAG
• Why you would want access to the sourcecode for custom developed SharePoint solutions