As SharePoint Delivery Manager, it is your responsibility to ensure that the SharePoint solution being delivered meets SharePoint sponsor technical requirements and fulfil most, if not all the objectives and expectations of service. This means you must Verify and Validate the SharePoint solution, whether that solution is a full-blown deployment of a SharePoint platform, a third party addon, or an internally or externally developed SharePoint app.

This article hopes to describe the preparation of the Verification and Validation (referred to throughout this article as V & V). V&V references the procedures that should be used to carry out the V & V policy against SharePoint solutions being delivered. On larger programs, the contract may require specific acceptance tests to ensure that SharePoint meets the SharePoint sponsors requirements (it may, for example, include not only physical environment acceptance, but also things like branding, functionality, resiliency, etc.). Acceptance tests can be considered as the final stage of V & V and require careful planning.

Prove the solution meets requirement

SharePoint should undergo V & V activities to confirm that the logical planning, design, and build of the solution operates in the organizations physical SharePoint environment. Typically, this is carried out at server, component level, and SharePoint Application level. The scale of the V & V activities will be appropriate to the size and nature of the SharePoint solution. V & V activities must be planned, documented and systematically managed in accordance with contract requirements. These activities must be conducted at discrete stages of the program and be recorded.

Understanding who is accountable for the V & V tasks

The SharePoint Delivery Manager (or designed technical authority for SharePoint) defines and is accountable for managing the V & V tasks. Responsibilities for conducting the V & V activities shall be defined in, or referenced from in individual work instructions. It is particularly important to ensure responsibilities are clearly defined on larger programs, where the V & V activities may be shared on a joint bass with subcontractors or consortium team members.

Understanding where V & V is applicable

V & V is applicable to:

• All SharePoint V & V activities which are conducted and SharePoint activities that needs to meets the V & V management requirements.
• Calls for any specific Acceptance Testing of the solution.
• Third party solutions to be added to the SharePoint environment
• Internally developed solutions to be added to the SharePoint environment
• Modifications which will affect the SharePoint environment
• Changes to Disaster Recovery or Business Continuity plans

Defining the V & V strategy

The V & V strategy must be defined, either in the SharePoint Detail Delivery Plan, or, if appropriate, in a separate document. When produced as a separate plan, the V & V plan shall meet the requirements of Document and Data Control for the organisation. If the SharePoint implementation is defined as an item (e.g. WSP, App, Feature, Third Party solution) it shall be subject to Configuration Management.

V & V can be achieved through a combination of activities and documentation. These will be specific to the needs of the program concerned and should be selected and devised to suit a particular solution. On larger programs the V & V strategy must outline the approach for each part of the program as well as the solution as a whole, i.e. there must be an integrated approach to verification and validation.

There are several associated procedures that provide information on the planning and conduct of V & V. The conduct of a Technical Review; Software Testing; Control of Software Testing; Inspection and Test. Once the hardware and/or software sub systems have been tested in isolation e.g. module level testing, then the final step of V & V is referenced as the Integration, System and Acceptance Testing procedures.

Understanding the appropriate activities

A number of generic V & V techniques are listed below:

• Technical Reviews
• Analysis and Calculations
• Testing at Unit / Integration / System / User Interface
• Inspection
• Sampling

The main verification technique is the Technical Review, which can be applied at each stage and at all levels of the SharePoint program.

V & V can be carried out by conducting high level testing; for example, stress testing of the web servers; stress test of the component connected services e.g. SQL Servers. This can be supported by additional calculations, analysis and testing of low level items (e.g. SharePoint installed features in Central Administration).

V & V can be carried out by conducting high level testing of SharePoint during the final stages of development. For example, there could be some accreditation of the SharePoint environment by independent experts (e.g. a case Study can be classified as validation), or by comparison / calibration with similar SharePoint environments. This is the reason why there is always one level of environment – a Staging and a Production Environment. The Production environment is construed as the realisation of the Staging environment; in other words, what happens in Staging ends up in Production if agreed; if not, Staging is rolled back or replaced with its Production variant.

This also relates to acceptance testing, which is the final stage of validation and may involve a series of trials to enable the capability of the SharePoint solution to be demonstrated. For example, the Staging environment would be used as User Acceptance for a third party SharePoint add-ons, or modifications to a site and demonstrated to one or more stakeholders before its made live. To make the solution live, documentation concerning the acceptance test is defined in the Stage environment and used as a basis to raise a request to apply those very same changes in Production (if the stakeholder(s) are satisfied with the application made in the SharePoint stage environment).

To ensure clear ‘audit control’ means that a relationship to the original software specification and requirements stated by the SharePoint sponsor is established. Documentation must be included and structured in such a way to ensure that proof concerning the V & V of the solution can be understood, and therefore signed off by the SharePoint sponsor. This is crucial because the SharePoint sponsor will not generally have any idea what the needs to be signed off and why. Therefore, you will need to describe in English, not tech speak, what needs to be checked off by the user acceptance, and how the delivery team will provide the SharePoint solution.

Ensuring there is V & V strategy, established and managed

The conduct of the different types of V & V activity is described in the following:

• Carry out Technical or Design Reviews. Progress against the defined V & V activities should be addressed as part of the monthly reporting cycle. Failure of an item during V & V must be assessed and recorded – for SharePoint this is known as ‘Control of Non-Conforming Items’.
• You should produce Technical Records to describe any analysis activity and which is particularly suited to recording results
• You should ensure there is a structured, cohesive and logical control of SharePoint testing, at all stages of development.
• You should ensure that V& V is applied concerning the inspection and testing of items of third party software either procured from an outside supplier or created in-house – e.g. SharePoint WSP packages, Apps, Solutions by third party, connected monitoring software for SharePoint, etc.