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.
|
Thursday, February 27, 2014
Web application Cookies Testing
Friday, October 25, 2013
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.
|
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
Subscribe to:
Posts (Atom)