SharePoint - Relationships between user roles, permissions, and groups

SharePoint - Relationships between user roles, permissions, and groups

A.      Visitor:

a.       Windows SharePoint Services User Role: Visitor

b.      Windows SharePoint Services Permissions: Can read the internal Web site.

c.       Default Windows SharePoint Services Group for the Internal Web Site: CompanyWeb Visitor

d.      Windows Small Business Server 2008 Security Group: Windows SBS SharePoint_VisitorsGroup

B.    Member:

a.     Windows SharePoint Services User Role: Visitor

b.    Windows SharePoint Services Permissions: Can read and write to the internal Web site. The user can add, edit and change documents, but cannot change the structure of the site, such as add new document libraries.

c.     Default Windows SharePoint Services Group for the Internal Web Site: CompanyWeb Visitor

d.    Windows Small Business Server 2008 Security Group: Windows SBS SharePoint_MembersGroup

C.    Owner:

a.     Windows SharePoint Services User Role: Visitor

b.    Windows SharePoint Services Permissions: Has administrator privileges on the internal Web site.

c.     Default Windows SharePoint Services Group for the Internal Web Site: CompanyWeb Visitor

d.    Windows Small Business Server 2008 Security Group: Windows SBS SharePoint_OwnersGroup

SharePoint Applications Testing

1.     What are Various Tools available for SharePoint Testing?
 Some of the Tool available for Testing are:
 SharePoint 2007 Test Data Population Tool (available at CodePlex)
 Sporm (available at Codeplex)
 Can also Use Typemock Isolator for Testing sharePoint object model.

2.     How will you set up a Platform for Testing SharePoint WebParts?
We would need to install :
1. WSS 3.0
2. Microsoft Office SharePoint Server 2007 installed.
3. Windows Server 2003 or 2008.
4. Visual Studio 2005 or 2008.

3.     How would you plan Testing WebParts.
A Tester would need to verify by adding,deleting and moving webparts on a webpart page.Also, a Tester should verify the Web Part properties, Webpart ToolPane and that nothing fails on the Page.

4.     How will you Test the Performance of a SharePoint Website?
 Various Tools are available in the market to do that. Some of them are
 Fiddler – a very handy and light weight tool that can provide quick overview of you web site performance. It can also records scripts that you can use in VSTS.
neXpert - an add-on to Fiddler which automates the classic performance best practice checks and produces a HTML report on the issues found in a Fiddler capture.
Visual Round Trip Analyzer - Web page performance visualizer and analyzer tool.
Also, Can use SharePoint Capacity Planning * Also, Can use SharePoint Capacity Planning Tool from Microsoft. 

5.     How would you plan Testing WebParts.
We can Test a SharePoint site for various customizations that will be done by a developers or a designers.
For e.g. some important steps for Testing Custom WebParts are:
Verify that you can add the Web Part properly to a sharepoint page, and nothing fails.
Verify that the Web Part handles all of its exceptions.

Verify that the Web Part works correctly regardless of where the Web Part Page is located.
Verify that the Web Part can access its resources in different setup configurations.
Verify that Web Part properties displayed in the tool pane are user-friendly.
Verify that the Web Part renders appropriately based on user permissions.
Verify that the Web Part previews properly.
Verify that adding several instances of the same Web Part to a Web Part Page (or in the same Web Part zone) works correctly.

6.     How would you Test Design and Layout changes in SharePoint?
Some of the changes that we need to check are:
See if companies Logo is displayed correctly.

Verify that it shows up on each and every page of the Site.
Verify that every page in SharePoint including list and library pages (AllForms.aspx) uses the same master Page.
Verify that the application Pages such as "settings.aspx" also inherit the company branding layout ( or master Page).
Verify that any page can be edited successfully, and the user can add/remove webparts from the Page.
Verify the any new page created, inherits the custom Branding Layout or master Page.
Verify that the branding (master page or look and feel) or layout does not fail if a user adds a Content editor webpart with custom Css in the webpart.
Verify design in various browsers. 

CAPTCHA test Cases

CAPTCHA test Cases:

1. The page should have all the correct objects, proper alignment with all Color Combinations (as per requirement).
2. The page should have all the correct objects, proper alignment with all Color Combinations (as per requirement).
3. All  the required objects should present on  form
4. Ensure that the CAPTCHA code screen should be viewable
5. Ensure that the CAPTCHA code should be Case Sensitive or vice versa (According to the Requirement).
6. Ensure that the CAPTCHA code should be in Image format.
7. Ensure that the CAPTCHA code should be reusable. (able to get new code by clicked link)
8. Ensure that the CAPTCHA code should generate new code once the page is refreshed.
9. Ensure that the CAPTCHA code is not confusing. For eg: Zero and O (Alphabet),numbers 6 and 9)
10. Ensure that the CAPTCHA code should generate new code once entered the wrong code.
11. Ensure that the user receives information about how to use the CAPTCHA, on clicking the help button.
12. Ensure that the CAPTCHA code should not able to copy/paste.
13. Ensure that the audio version of CAPTCHA is working (requirement dependent).
14. Ensure that the system accepts valid CAPTCHA.
15. Ensure that the system rejects the invalid CAPTCHA
16. Application should not accept the Invalid CAPTCHA code on form feed and should display proper alert message.
17. Ensure that the CAPTCHA code should not distruot the other fields in the form once entered wrong.(Other form fields should not clear)
18. Only alphabets/digits should be allowed in CAPTCHA, no special characters in CAPTCHA
19. No offensive languages should be used.

Test Cases for Search Functionality

Test Cases for Search Functionality

Every web application by default will contain search feature in it. Many search engines main functionality is search feature. The parameters to be considered while developing this feature or testing this feature are not limited. There are many factors which should be looked in when checking the coverage and usability of the search text box in the application.

Preparation before testing the search functionality

1. Note down the valid input details for the search feature.

2. Find out the minimum and maximum range.

3. Find out the depth of the search – document search, word in a document, image search

4. Should document search display the size of the document also? Similarly for image?

5. Any advanced search features like document or image type selection to refine the search are available?

6. General set of input which can be given are

a. A-Z

b. a-z

c. 0-9

d. { [ ( ~ ! @ # $ % ^ & * ` | \ : ” ; ’ < > ? , . / * - + ) ] }

e. Blank spaces

Work with these inputs when testing the search functionality

1. Special set of data which can be tried as input are

a. 2 blank spaces – These should be trimmed and error message should be displayed

b. Blank spaces followed with special characters or numbers

c. Special set like a* should give the results for all characters starting with a.

d. Enter any sql query like “Select * from hello;” without quotes and with quotes.

e. Search for tags.

f. Search for hyperlinks should be performed.

2. Search for documents. For advanced search feature, search with different valid and invalid types of documents. Document size should also be looked at.

3. Search for images with their sizes, names and types.

4. Any input data entered should return proper error message guiding to enter the correct input.

5. Text in different panels of the page should be searched. For example if left panel of the web page contains menus and hyperlinks. Hyperlinks in that area should be searched properly. If menus are also in scope then they should also appear in the search results.

6. Search response time should be checked.

7. Try pressing “Enter” key instead of clicking “Search” button.

8. Try searching in the page where a part of the page has form with Submit button.

Search results testing

DO not ignore the search results just because you got the results.

1. Check number of results in each page.

2. Check the count of the search results displayed in the page.

3. Check if the search results are displayed by popularity or most viewed or any other criteria mentioned in the requirements.

4. Proper messages should be displayed when there are no results.

5. Each search result should contain one link and few lines containing the searched keyword. Link should navigate to the page where the keyword exists.

6. Searched keyword should be highlighted in the search results page and also in the page where the keyword exists.

7. Pagination of the search results should be tested.

8. Number of search results display and the count should also be tested.

Test Scenarios for Result Grid

1. Page loading symbol should be displayed when it’s taking more than default time to load the result page

2. Check if all search parameters are used to fetch data shown on result grid

3. Total number of results should be displayed on result grid

4. Search criteria used for searching should be displayed on result grid

5. Result grid values should be sorted by default column.

6. Sorted columns should be displayed with sorting icon

7. Result grids should include all specified columns with correct values

8. Ascending and descending sorting functionality should work for columns supported with data sorting

9. Result grids should be displayed with proper column and row spacing

10. Pagination should be enabled when there are more results than the default result count per page

11. Check for Next, Previous, First and Last page pagination functionality

12. Duplicate records should not be displayed in result grid

13. Check if all columns are visible and horizontal scroll bar is enabled if necessary

14. Check data for dynamic columns (columns whose values are calculated dynamically based on the other column values)

15. For result grids showing reports check ‘Totals’ row and verify total for every column

16. For result grids showing reports check ‘Totals’ row data when pagination is enabled and user navigates to next page

17. Check if proper symbols are used for displaying column values e.g. % symbol should be displayed for percentage calculation

18. Check result grid data if date range is enabled