Share point projects testing

SharePoint projects testing is same as we doing for another technologies. But keep in mind below things while you go for SharePoint testing.

You can start with the SharePoint Site Collection settings, checking all the Site title, URLs, Enabled Features in the Site Actions.

 Test all the below for individual sites recursively.

 Test the site collection settings if defined and the site collection URL if provided in the design.

 Move on to the different SharePoint lists, libraries and pages settings (in the respective order) within the site.

 Test the Default page first and then move onto other pages.

 For pages, test the Page Title, Filename, Type and Template name before testing the page web parts.

 In the Pages (Default & Custom SharePoint Pages) you can test individual

 1) Data View Web parts for source and functionality as designed.

 2) List View Web parts and their Default Display settings.

 3) .NET Web parts settings and their functionality as designed.

 Test the event actions specified with respect to user actions in the web parts as specified for event handlers for all web parts in the page.  Test the web services defined for user actions on web parts.

 

 After the pages in the site collection is tested, move on to Page navigation in the Site Actions, for Global navigation and left navigation settings.

 Finally, on the page, test the security settings for People & Groups set on the web parts in the page.  Continue the order for other sites within the app.

SharePoint Solution Test Plan

Each solution should have its own defined test plan. What follows is an example of a SharePoint test plan. This plan is very basic and is only meant to introduce ideas.

Objective

To test the new WebPart XYZ for [Organization Name] based on the Requirements Traceability Matrix provided prior to the inception of this portal project. In this Test Plan, [Organization Name] expects to achieve the following:

1.       Ensure that all business requirements have been met.

2.       Ensure that all functional requirements have been met.

3.       Ensure that branding/graphical elements render correctly in our chosen browsers.

4.       Evaluate system performance.

5.       Determine level of user satisfaction.

The above objectives will be accomplished by using the use cases outlined in subsequent sections of this document.

Schedules

The following schedule outlines testing roles, timelines, and dates. Each group is responsible for adhering to the following schedule. Each segment detailed will be completed within the scheduled timeframe.

User Role	Dates	Timeframe
Administrators	Sunday, May 2 – Wednesday, May 5	5pm – 5am
Content Stewards	Monday, May 3 – Friday, May 7	7am – 5pm
End Users	Monday, May 10 – Friday, May 14	7am – 5pm

Responsibilities

Administrators:                Site owners, manage security, content, design, maintenance, users and navigators of the site.

Content Stewards:          People who will administrate sites at the departmental level, also users and navigators of the site.

Users:                                   People who will read, navigate, and/or contribute content to the portal.

Test Cases

What follows is a matrix of the test cases that will be performed for this solution.

User Role	Test Description (Intention)	How to Test	Result (System Response)
Administrators	Minimize and restore the Web Part on a page.	From a page, in the ribbon, click the Page tab, and then click the Edit command. On the page, point to the Web Part, click the down arrow, and then click Minimize. When you have finished editing the page, click the Page tab, and then click Save & Close. From that same page, in the ribbon, click the Page tab, and then click the Edit command. On the page, point to the Web Part, click the down arrow, and then click Restore. When you have finished editing the page, click the Page tab, and then click Save & Close.	Tester documents results here.
Content Stewards	Add Web Part to page.	From a page, in the ribbon, click the Page tab, and then click the Edit command. Click on the page where you want to add a Web Part, click the Insert tab, and then click Web Part.  Under Categories, select a category, such as Lists and Libraries, select the Web Part that you want to add to the page, such as Announcements, and then click Add.  When you select a Web Part, information about the Web Part is displayed in About the Web Part.  When you have finished editing the page, click the Page tab, and then click Save  Close.	Tester documents results here.
End Users	View Web Part on page.	1.       Navigate to Web Part page.	Tester documents results here.

Task Checklist for Testing Web Parts

The following sample SharePoint specific checklist contains a series of tasks designed to help you determine the quality of Web Parts you are asked to deploy or maintain.  This can be used in addition to the tests, or it can be used as a simplified alternative depending on your organizational needs.

Task Checklist

Task
	Verify that you can add the Web Part properly to a Web Part zone.
	Verify that static Web Parts render appropriately and do not cause the Web Part Page to fail.
	Verify that the Web Part works correctly regardless of where the Web Part Page is located.
	Verify that every public property can handle bad input.
	Verify that the Web Part handles all of its exceptions.
	Verify that the Web Part renders correctly in SharePoint Designer.
	Verify that Web Part properties displayed in the tool pane are user-friendly.
	Verify that the Web Part appears appropriately in the web part gallery.
	Verify that the Web Part previews properly (through the web part gallery).
	Verify that you can import and export the Web Part properly.
	Verify that Web Part properties are not dependent on each other.
	Verify that Web Parts work correctly with different combinations of Web Part zone settings.
	Verify that the Web Part renders appropriately based on user permissions.
	Verify that adding several instances of the same Web Part to a Web Part Page (or in the same Web Part zone) works correctly.