Checklist for Testing Web Parts

If you install and maintain the Web Parts for your Microsoft Office SharePoint Portal Server portal site or Microsoft Windows SharePoint Services team site, you should help ensure that the Web Parts are secure, well-written, and can integrate appropriately with other components on the Web Part Page.

Verify that you can add the Web Part properly to a Web Part zone.

Adding a Web Part to a Web Part zone is the most common user task. Therefore, it is essential that the Web Part works correctly to create a good user experience.

To test

1. Create a new Web Part Page.
2. Click Modify Shared Page, click Add Web Parts, and then click Import.
3. Import the .dwp file for your Web Part.
4. Add the Web Part to a Web Part zone.

Verify that static Web Parts render appropriately and do not cause the Web Part Page to fail.

Web Parts that are placed outside of a Web Part zone, or static Web Parts, are contained in .aspx pages, but not in the Web Part zone. Because the static Web Part is a Web form control, ASP.NET renders the Web Part. You cannot save changes in either shared or personal view.

To test

1. Open FrontPage.
2. Create a new blank page.
3. In Design view, on the Data menu, click Insert Web Part.
4. From the Web Part Gallery that appears in the task pane, drag a Web Part onto the page.
5. Save the page as an .aspx page.
6. View the page in the browser.
   

   Note

      

   Make sure that your Web Part is within the

   <form runat=”server”>

   tags.

7. Verify that the part renders correctly (for example, you should not be able to save changes in a static Web Part).

Verify that the Web Part works correctly regardless of where the Web Part Page is located.

You can add Web Parts to Web Part Pages that are contained in a document library as well as Web Part Pages that are contained in the top-level Web site. They should work correctly in either location.

To test

1. Create a Web Part Page in a document library.
   • Browse to the portal site.
   • On the Create menu, click Web Part Page.
   • In the New Web Part Page creation form, Save Location lists the document libraries in which the Web Part can be saved. Select a document library, and then click Create.
   • Import your Web Part from the gallery.
2. Create a Web Part Page in the top-level Web site.
   • Open a SharePoint site in FrontPage.
   • On the File menu, click New.
   • In the New Page section of the task pane, click More page templates, and on the Web Part Pages tab, select a template.
   • Click on a zone to bring up the gallery (or on the Data menu, click Insert Web Part), and then import your Web Part into a zone.
   • Save the Web Part Page in the top-level Web site, for example, at the same location where the default.aspx is located.

Verify that property attributes are correctly defined.

You can specify Web Part properties in two ways: as an XML BLOB contained within the Web Part, or as an attribute within the Web Part.

Because of how the Web Part infrastructure handles property values, we recommend that you define properties as simple types rather than as complex types so that they work properly if specified as attributes of the Web Part.

To test

1. Create a static Web Part in FrontPage and, in Code view, try setting every property the Web Part has as an attribute.
2. Browse to the page and see if the page fails or if the property was ignored.

Verify that Web Part changes made in personal view are not reflected in shared view.

Changes made in shared view are seen by all users. Changes made in personal view should only be seen by the person that made them.

To test

1. Add the Web Part in shared view.
2. Edit the properties in shared view.
3. Change to personal view.
4. Edit the property in personal view.
5. Change back to shared view, and then make sure the Web Part does not use any of the values changed while in personal view.

Verify that every public property can handle bad input.

As for any ASP.NET control or application, you should validate all user input before performing operations with it. This validation can help to protect against not only accidental misuse, but also deliberate attacks such as SQL injection, cross-site scripting, buffer overflow, and so on.

To test

1. Verify that the Web Part can detect invalid input for properties and that it informs the end user that bad data was entered.
2. Verify that the property is not used outside of its intended purpose. For example, if a Web Part is intended to allow users to link URLs, limit the protocol usage to HTTP instead of allowing any protocol to be saved (for example, javascript://).
3. Verify that the Web Part HTML encodes the property value when rendering user input to the client.

Check all the ways in which property values can be changed, including:

• Modifying the .dwp file in a text editor.
• Modifying properties in the tool pane.
• Modifying properties in Code view in FrontPage.
• Using the Web Part Page Services Component (WPSC), which is a client-side object model that provides a way to set properties and persist them from the client browser.

Verify that the Web Part handles all of its exceptions.

A Web Part should handle all exceptions rather than risk the possibility of causing the Web Part Page to stop responding.

To test

Enter error and boundary cases for Web Part properties to verify that the Web Part never breaks the page by not catching one of its own exceptions.

Verify that the Web Part renders correctly in Microsoft Office FrontPage.

If your organization is using FrontPage to customize SharePoint sites, verify that the Web Part renders properly within FrontPage. To accomplish this, the Web Part developer must implement the IDesignTimeHtmlProvider interface.

To test

Open up a Web Part Page that contains the Web Part in Design view in FrontPage. Verify that the Web Part renders correctly and you do not see the message “There is no preview available for this part.”

Verify that Web Part properties displayed in the tool pane are user-friendly.

Because the tool pane is where users modify Web Part properties, it is important that users can work with Web Part properties easily in it.

To test

1. Add the Web Part to a Web Part Page. Click Modify Shared Page, click Modify Shared Web Parts, and then select your Web Part. The tool pane should appear and display the Web Part properties.
2. Verify that the Friendly Name is easy to understand, for example, a property named MyText should be My Text (notice the space between the two words).
3. Make sure the Description (the ToolTip that appears) helps the user understand how and why to set the property.
4. Verify that the Category name makes sense. (Miscellaneous is used when no category is specified for the property, but it is not especially helpful to the user.)
5. Verify that the order of the properties makes sense.
6. If appropriate, check that these properties are localized using the following method:After installing the SharePoint language packs, create a new subsite and select a different language. Add the Web Part to a Web Part Page in the new subsite and verify that Friendly Name, Description, and Category are localized in the tool pane.

Verify that the Web Part appears appropriately in the search results.

Because Web Part galleries can contain numerous custom Web Parts, the search capability helps users quickly find the Web Parts they want.

The Web Part infrastructure uses the Title and Description properties of the Web Part to build the result set, so comprehensive information in these fields results in easily searchable Web Parts.

To test

1. Add the Web Part to the Site Web Part Gallery by navigating to Site Settings, clicking Go to Site Administration, clicking Manage Web Part Gallery, and then clicking New Web Part.
2. Choose the Web Part you’re testing, and then click Populate Gallery.
3. Browse to a Web Part Page, and then click Modify Shared Page, click Add Web Parts, and then click Search. Enter the appropriate search text and click Go. The Web Part should appear as one of the top choices.

Verify that you can import and export the Web Part properly.

By default, whenever you export a Web Part, each Web Part property is included in the .dwp file. However, because properties can contain sensitive information, for example, a date of birth, you can identify a property as controlled, allowing you or the user to exclude the value if the Web Part is exported. Only properties that are exported when the user is in personal view can be controlled; in shared view, all property values are exported.

To test

1. Add a Web Part from the gallery into a Web Part Page and set the Web Part’s properties.
2. On the Web Part chrome drop-down menu, click Export to export the Web Part.
3. Save the .dwp generated onto your local computer, and re-import the Web Part by clicking Modify Shared Page, clicking Add Web Parts, and then clicking Import.
4. Browse to the .dwp file, click Upload, and then click Import.
5. Make sure that the properties that were exported are correctly imported.
6. Verify that any property that would not make sense to export (for example, a Social Security number) has the ExportControlledProperties attribute set. (The Allow Export Sensitive Properties check box in the tool pane should be cleared.)

Verify that the Web Part previews properly.

It is important to create previews for Web Parts so that administrators are able to review the parts included in the Web Part gallery.

To test

1. Go to Site Settings, click Go to Site Administration, click Manage Web Part Gallery, and then click the Web Part. The preview should render.
2. Verify that there are no script errors.
3. Verify that the preview appears correctly.

Verify that the Web Part can access its resources in different setup configurations.

Web Part resources cannot be part of the DLL because they must be URL-accessible. Examples of these resources are images, .js files, or .aspx pages.

To test

Note   Because a Web Part assembly can be installed in either the bin directory (

<%SystemDrive%>\Inetpub\wwwroot\bin

), or the global assembly cache, you must go through each of these test steps with the Web Part installed in the bin and again with the Web Part installed in the global assembly cache.

Add the Web Part to your page in all the following scenarios and make sure that it can correctly access its resources:

• Add the Web Part to the top-level Web site.
• Add the Web Part to a subsite with unique permissions, in which the user only has rights in the subsite.
• Add the Web Part to a Web Part Page inside a folder in a document library.
• Add a Web Part to a site with Self-Service Site Creation enabled on the virtual server.
• Add a Web Part to a site with Host Header mode enabled.
• Add the Web part to a site where the top-level Web site is not a SharePoint site, for example, http://servername/customURL.
• Add to the Web Part to Web Part Pages that are in different subsite languages.

Verify that Web Part properties are not dependent on each other.

Because you cannot guarantee the order that properties are set in the tool pane, you should avoid writing Web Part properties that are dependent on each other.

To test

1. Test different values for properties in the tool pane.
   

   Note   If a property is not visible in the UI, or is disabled, you can open the Web Part Page in FrontPage, switch to Code view, and then set the properties by editing the XML. Export the Web Part, save the .dwp file, and then modify the .dwp file.

2. Import the .dwp file back into the page and check the property values.

Verify that the Web Part works correctly with different combinations of Web Part zone settings.

Web Part zones have properties that control whether a user can persist changes. If a user attempts to save changes to a Web Part without the correct permissions, a broken page can result.

The following Web Part zone properties affect Web Parts in the zone:

• AllowCustomization If false, and a user is viewing the page in shared view, the Web Part cannot persist any changes to the database.
• AllowPersonalization If false, and a user is viewing the page in personal view, the Web Part cannot persist any changes to the database.
• LockLayout If true, changes to the AllowRemove, AllowZoneChange, Height, IsIncluded, IsVisible, PartOrder, Width, and ZoneID properties are not persisted to the database regardless of view.

To test

1. Create a page in the browser, and then add your Web Part into several zones, both in shared and personal views.
2. Open FrontPage. Open a Web Part Page on a SharePoint site and, in Design view, double-click a Web Part zone (or right-click over a Web Part zone, and then on the shortcut menu, click Web Part Zone Properties), and then change the zone properties. Alternatively, you can switch to Code view and type in the attributes for the Web Part zone control.
3. View the page in the browser.
4. Verify that the part does not break the page and functions correctly.
5. Verify that any UI displayed in the Web Part indicates to the user that changes cannot be persisted or that UI is disabled as appropriate for the zone settings.

Verify that the Web Part renders appropriately based on user permissions.

Because a Web Part is managed by the user at run time, the Web Part should render with a user interface that is appropriate for each user’s permissions.

To test

1. Test with different User accounts that have only Reader or Contributor rights.
2. Make sure the UI is suppressed if the end user does not have permissions to perform a certain action. (For example, if a Web Part displays a Save button, it should be disabled or hidden if the user does not have permissions to perform that action.)
3. Turn on anonymous access for the site and browse a Web Part Page that has your Web Part, but make sure the sign-in button is still visible on the page. (When the sign-in button is displayed on the page, the user has not yet been authenticated.)

Verify that adding several instances of the same Web Part to a Web Part Page (or in the same Web Part zone) works correctly.

When you want multiple Web Parts to share client-side script, you should place the script in an external file and register the script for the page to improve performance and simplify maintenance.

To test

1. Add several instances of the Web Part to the page. Be sure to execute any client-side script that is specific to the Web Part.
2. Add several instances of the Web Part to the same Web Part zone. Be sure to execute any client-side script that is specific to the Web Part.

Verify that Web Part caching works correctly.

For any operation that works with a large amount of data, use a Web Part cache to store property values and to expedite data retrieval.

Web Part authors can choose to cache data in several ways, but ultimately the administrator decides the type of caching that a Web Part uses.

Following are the three types of cache:

• None, which disables caching.
• Database, which uses the content database (and requires all objects to be serialized).
• CacheObject, which uses the ASP.NET Cache object (the default).

To test

You set the type of cache using the value of the WebPartCache element in the web.config file.

1. In the web.config file, change the <WebPartCache Storage="CacheObject"> statement to <WebPartCache Storage="Database">, and make sure that the Web Part still works correctly.
2. Change the statement to <WebPartCache Storage="None">, and then make sure that the Web Part still works correctly.
   

   Note   By default, exceptions related to caching are not displayed by the Web Part infrastructure. For debugging purposes only, you can make the following changes to your web.config file.

   In the <system.web> tag, locate the <customErrors mode="On"> tag and change it to <customErrors mode="Off"> to see the ASP.NET exception when an error occurs instead of being redirected to the error page.

   In the <SharePoint> tag, locate the <SafeMode MaxControls="50" CallStack="false"/> tag and change it to <SafeMode MaxControls="50" CallStack="true"/>. This causes the ASP.NET error message to display with stack trace information.

Verify that requests to other HTTP sites or Web services are asynchronous.

For performance reasons, you should use an asynchronous thread for any operation that works with a large amount of data.

To test

1. Check with the developer to see if she or he is making any calls to Web services or other HTTP sites. Confirm that the calls are asynchronous.
2. Run some performance tests on a page with the Web Part.

Database Testing guidelines

S. No	Guide Lines	Examples
1	Validate the connectivity of the DB	Check whether the user is able to connect to the database
2	Validating the data that is getting stored in the table	If user is giving some inputs through GUI then check for the data that is getting stored in the tables
3	Field type validation for each input	Suppose if user enters some alphabets in the place of pin code, In GUI we will get error message but what happens at the table level
4	Validating the integrity of the data that is getting stored in the table	Assume that user is giving his bank details and it is supposed to be stored in bank_details table and if he gives his personal details it is supposed to be stored in personal_details table. Now when try to get the all details in a report, check how the data in the two tables are integrated.
5	Validating the Data corruption	Check directly in the table for data corruption – means that what ever the data that we feed the system should be saved in the proper readable format
6	Validating the Data Encryption and decryption	For some sensitive data, while saving the records in table it should be encrypted and while displayed in the GUI it should be decrypted Eg: Password, IPIN, QPIN etc
7	Validating the users (with appropriate role) who can access the DB directly	Generally end users are not allowed to access the DB. Login as end user and check whether you can access the DB.
8	Validating the users (with appropriate role) who can change the Data in the DB directly	Even if users has read permission on DB not all the users will have the write permission, Check for the update, delete operations on DB directly with proper and improper permissions
9	Lack of data integrity across multiple tables in the DB	When some user details are getting stored in the multiple table then the data across table should be integrated with primary key (which can’t be null or duplicated) or else it will create problem in accessing the data.
10	Validate the data that is displayed in the user viewable report	Genarally the report will fetch data from multiple tables. In this case check the data in the report. We can also check whether the sensitive data are displayed in the report and in some pages there will be some option like display my personal information to others, check the data that is getting displayed based on the selection.
11	Validate the store procedure that is getting the data for the report	Assume that the report is getting generated by executing the SP, then if possible take the SP break it down to small queries and we can check the SP
12	Depending on the application size try to get the health of the DB Server (Not all client would be expecting this but this can used by our company to get more work)	In windows we can monitor the health of DB by perfmon and in Linux we have command like Vmstat. For any DB input output operation is very important. We should also track the CPU, memory utilizations along with locks, dead loacks etc.
13	Performance of the DB if the number of records in the reports are huge	Check the performance of the DB when the number of records are huge – means after getting the request how much time does the DB takes to respond to that query.
14	Finally, make sure that test cases are there are for certain basic operation like create, update, retrieve & deleting	This is called CURD testing. Any user should be allowed to this operation from UI level (again based on permission and type of application).
S.No	Advanced points during DB Testing
1	Before we start testing the DB we would need enough realistic data which should be similar to production environment (as much as possible). Dummy test data that we are using will not catch all bugs
2	Dummy DB should be created and by adding, deleting the records we could easily know the relation between the tables
3	Some basic adjustments for DB tuning like primary heap size, secondary heap size, query logs etc should be analyzed so that we can have better idea about the testing
4	Testing indexes – Before index what is the time taken and after indexing what is the time taken
5	Validating the need of SP – SP will store the data in the temp table before it gives data to the user, Some kind of validation should be there to decide the need of store procedure
6	Testing SP – Testing the store procedure could be break the SP in to smaller queries and execute one by one.
7	Error Handling of SP can be tested – Pass parameters which is not accepteable or pass parameters which give the unexpected parameter during the execution of SP
8	Get the health report of the DB like CPU utlization, Memory utilization
9	Get the query logs which can say give you the details about the query which has taken more than the expected seconds
10	Get the Input output report of the DB which plays the vital role in the DB tuning