SharePoint Tip of the Month
Using V-Model Test Methodology for QA in SharePoint Deployments
With every new SharePoint initiative, project managers carefully script and manage the necessary phases to ensure a successful deployment of the solution. One of the most important components of development is testing.
Testing can be more iterative throughout creation of the solution or take place at defined check points. The V-Model testing methodology is frequently used when developing SharePoint solutions. Typically, slight variations of this model will be used depending upon the scope of the project, available resources, schedule and budget.
If we look at a basic structure of the V-Model, we can see that each step in the development of the solution incorporates validation testing.
The V-Model originated in Germany for the development of government defense projects
and is now a widely accepted standard in software development
Validation of the solution starts with Unit Testing by developers. Unit testing determines if specific pieces of code behave as designed. It is important to incorporate both positive and negative testing to ensure the code responds correctly to valid and invalid data.
Once the solution is built, Quality Assurance (QA) testing is conducted to make sure the deliverable meets specifications. QA verifies the solution meets both the business and system requirements prior to migrating the solution over to the client. Testing techniques such as Functional, Usability and Security Testing are commonly used during QA.
Functional Testing focuses on what the program does in comparison to design specifications. This may include testing user interfaces for example, but does not look at code. Basic Usability Testing is also reviewed during QA. Usability testing identifies difficulties in completing tasks and possible improvements to the end user experience. Finally, Security Testing verifies that access points to a solution meet defined requirements. In SharePoint solutions, Security Testing is used to verify custom SharePoint Group’s rights and permissions.
Once the solution is deployed into the Client’s staging environment, User Acceptance Testing (UAT) is conducted. This testing is completed by the Client so that they can confirm the final solution integrates well with their SharePoint environment and delivers the results they were expecting. UAT Testing in SharePoint could include a review of custom web parts and performance of workflows for example.
Finally, if a SharePoint solution needs to integrate with existing external applications or systems, Integration Testing will be conducted. This testing verifies interfaces against an external application or system and identifies issues within a client’s environment that could not be tested during earlier phases.
How much of your project budget should be allotted for testing?
A testing budget is based on the amount of development hours required for a solution. Therefore, the percentage used to test a SharePoint solution can range depending upon the complexity and amount of customization that is incorporated. A no-code solution, for example, will require less development resulting in lower testing costs. A no-code solution’s testing budget will typically run between 20% and 30% of development hours. What if your SharePoint solution requires custom code? Since custom code increases the complexity of the solution and the amount of development time, the testing budget will increase. The testing budget for a solution that includes custom code should be 30% to 40% of development hours.
There are other enhancements to a SharePoint solution that can increase the amount of testing conducted. The addition of Nintex Custom Forms and Workflows to a SharePoint solution is one of the more popular enhancements we see. Although some workflows can be quite simple, others can be extremely complex by incorporating extensive enterprise processes that route information through a myriad of logic. Testing a workflow begins with functionality, but also includes testing logic flow, content, security, and integration with other features such as digital signatures. Again, the number and complexity of workflows developed will determine how much time is needed for testing making it analogous to testing a custom code SharePoint solution.
Overall, testing is a critical piece that should be incorporated into each phase of development. Budgeting for the appropriate amount of testing will ultimately ensure a successful deployment of the solution.
This SharePoint Tip contributed by SharePoint Consultant, Margo Bauer.