Web application Cookies Testing

Website Cookies Basic Test Cases

Check to see what happens if a user deletes cookies while in site

Check to see what happens if a user deletes cookies after visiting a site

Check to see what happens if a user disabling cookies if user has set browser options to warn before writing any cookie or disabled the cookies completely then site containing cookie will be completely disabled and cannot perform any operation resulting in loss of site traffic.

Session cookies: This cookie is active till the browser that invoked the cookie is open. When we close the browser this session cookie gets deleted. Sometime session of say 20 minutes can be set to expire the cookie.

Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.

Password cracking:

If username or password is stored in cookies without encrypting

Cross Site Scripting (XSS

attacker can use scripts like JavaScript to steal user cookies and information stored in the cookies

Where cookies are stored?

When any web page application writes cookie it get saved in a text file on user hard disk drive. The path where the cookies get stored depends on the browser. Different browsers store cookie in different paths. E.g. Internet explorer store cookies on path “C:\Documents and Settings\Default User\Cookies” Here the “Default User” can be replaced by the current user you logged in as. Like “Administrator”, or user name like “Vijay” etc. The cookie path can be easily found by navigating through the browser options. In Mozilla Firefox browser you can even see the cookies in browser options itself. Open the Mozila browser, click on Tools->Options->Privacy and then “Show cookies” button.

How cookies are stored?

Let’s take example of cookie written by rediff.com on Mozilla Firefox browser: On Mozilla Firefox browser when you open the page rediff.com or login to your rediffmail account, a cookie will get written on your Hard disk. To view this cookie simply click on “Show cookies” button mentioned on above path. Click on Rediff.com site under this cookie list. You can see different cookies written by rediff domain with different names. Site: Rediff.com Cookie name: RMID Name: RMID (Name of the cookie) Content: 1d11c8ec44bf49e0… (Encrypted content) Domain: .rediff.com Path: / (Any path after the domain name) Send For: Any type of connection Expires: Thursday, December 31, 2020 11:59:59 PM

General Test cases:

As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.

If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.

Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.

Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)

Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.

Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behaviour of the pages.

Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.

Checking the deletion of cookies from your web application page: Sometimes cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user

Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.

If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.

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