Test Plan

1.     Introduction

            This Test Plan Version 1.1 provides the strategy for testing the project “Cluster Management Systems”. This section of the Test Plan document describes the  following.

·         Purpose

·         Objectives

a. Document Purpose

This Test Plan reviews:

                                            i.      Existing project information,

                                          ii.      Business Requirements and critical transactions to be tested,

                                        iii.      Testing types and strategies to be implemented and

                                        iv.      A proposed testing schedule

b. Objectives

                  This document provides the platform for testing the project “Cluster Management System”. The objective of testing is to see if the project meets the “Software Requirement Specifications version 2.0”. This document will provide - (1) the guidelines for the testing team to test the functionalities embedded in the project and (2) help for evaluating the Software Quality of the project.

2.     Project Scope

This section of the Test Plan document describes the (1) Scope of the project “Cluster Management System” and (2) Out of Scope of the project “Cluster Management System”.

a. Scope of the Project

“Cluster Mangement System” will be tested for its functionality on a cluster of 3 computers. Each computer on the cluster is a Pentium III (548 MHz) with Linux operating system. Testing include –   (1) Unit testing, (2) Integration testing, (3) System testing and (4) Customer Acceptance Testing (CAT). Each test is scheduled to take one week with the Customer Acceptance test on 11-11-2008.

The testing includes testing for several functions like

·         Login feature

·         Adding or deleting of an user

·         Reboot a node

·         Updating a user profile

·         Adding or Deleting a node

 

1.    Out of Scope of the Project

Performance of the project “Cluster Management System” for a cluster of large number of computers is out of scope of this project at this point of time.   

3.     Project Resources

Table 1 describes the Roles, Responsibilities and Resource Name for the testing of the Project “Cluster Management System”.

Role	Responsibilities	Resource Name(s)
Testers	ü  Plan testing activities ü  Execute Test Cases ü  Find, report and track defects ü  Measure test effort ü  Analyze results	Prasad and chaitanya
Developers	ü  Deliver complete builds of the application ü  Provide Testers with feedback regarding changes, new functionality ü  Provide expertise and knowledge of the application-under-test ü  Eliminate agreed upon defects	Nilesh
Business Analysts	ü  Interview Users ü  Create Business Requirements ü  Create Test Scenarios, Test Cases	Chaitanya and Prasad
Users	ü  Describe and review Business Requirements ü  Describe and review user profiles ü  Perform Customer Acceptance Testing (CAT)	Nilesh,Prasad and Chaitanya
Desktop Administrators	ü  Installation of software ü  Troubleshooting of hardware/software ü  Information regarding standard desktop	Nilesh Nilesh Nilesh

Table 1 - Project Roles and Responsibilities

4.     Test Strategies/Techniques

This section of the document describes – (1) Test design and (2) Test Data for the project “ Cluster Management System”.

a.      Test Design

Considering the scope of the project and the time limitations, we will be performing following tests.

a)      Unit Test –

This test verifies the program logic and is based on the knowledge of the program structure.

b)      Integration Test –

This test verifies the entire system’s functionality according to the design specification.

c)      Business Requirements –

This test verifies whether specific requirements of the customer are met.

d)     Acceptance Testing –

This test verifies whether the system needs to meet the initial objectives and customer’s expectations.

For performing the above mentioned tests, we will create test cases as shown in table 2.

Use Case ID Description Test Case UC-1 Use Case Login TC-1 UC-2 Use Case Update Profile TC-2 UC-3  Use Case Reboot TC-3 UC-4 Use Case Adding or delete a user TC-4 UC-5 Use Case Adding or Deleting node TC-5 UC-6 Use Case Power up TC-6

Table 2 -  Use cases and Test Cases

Table 3 describes the description of each test case mentioned in table 2 and the results expected from a corresponding test case.

Test Case	Use Case ID	Description	Expected Result
TC-1	UC-1	User enters a valid customer ID and password	User is granted the access to the system
TC-2	UC-2	User edits   information he wants to update in view user profile section	A message is displayed whether to confirm update or cancel and return back to view user profile page.
TC-3	UC-3	Admin clicks the reboot button after accessing the node lists.	A message will appear that rebooting operation is taking place. Once the machine is powered on, power button will become green
TC-4	UC-4	Admin clicks add/delete user menu button and fills the form ‘Add/delete a single user’	Message will  appears   that User was successfully created/deleted.
TC-5	UC-5	Admin clicks on nodes button and selects add/delete node  option	Confirmation screen is displayed verifying that selected nodes are added/deleted
TC-6	UC-6	Admin clicks the nodes button , Once the nodes are listed, click Red power button	“Powering On” message will be displayed until the machine is completely powered on Once the machine is powered on, the power button will become green.
TC-7	UC-7	Admin clicks the Accounts button and clicks list users menu item	.A screen will be displayed listing all users.

Table 3 – Description and the Expected Results of each Test Case

b.      Database

             A    Head node maintains Database that contains the login names and passwords      of all the users and administrator.

5.     Project Tasks/Schedule

Table 4 describes the schedule for the Test Plan of the project “Cluster Management System                                                                                                                                                              

Task	Artifacts	Projected Completion
Test Plan Completed	Test Plan Version 1.0	10-20-2008
Test Environment Prepared	Hardware and software	10-13-2008
Test Cases Recorded and Executed	Cluster, Test Plan Document version 1.0, Test Results Document	10-17-2008
Defects submitted and tracked	Unit Test Results Document	11-05-2008
Integration test	Test Plan Document Version 1.0	11-08-2008
Customer Acceptance Test	Test Plan Document Version 1.0	11-11-2008

Table 4 - Project Schedule

6.     Defect Responsibility/Resolution

Possible defects identified through manual testing will be discussed with development team members to verify that the observed behavior constitutes a defect. Defects found will be tried to be resolved. If not possible, they will be delivered with the deliverables as “Known Bugs”.  Defect register will be maintained to keep a track of all the defects found in the software.

7.     Exit Criteria

Testing can proceed to the next stage of the process when a sufficient proportion of the current stage has been completed All exit criteria should be satisfied by the end of the project.

8) Goals and Deliverables

Goals and deliverables of the test plan of the “Cluster Management System” are as follows –

a)      Goals:

ü  To accomplish all tasks described in this test plan.

ü  To install a measurable, improvable, repeatable, and manageable test process.

ü  To verify the functionality and content of the current version of the application.

ü  To reduce the frequency of error associated with manual testing.

ü  To find and successfully track 100% of defects present along the user path defined in this plan.

b)     Deliverables:

ü   Test Planning Stage 

ü   Test Execution and Defect Tracking Stage

ü   Evaluation and Improvement – this include

§  Test Cycle Evaluation

§  Project Summary / Evaluation

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.