Cookies Testing

1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie
2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.
3) 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.
4) 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)
5) 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.
6) 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 behavior of the pages.
7) 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.
8 ) Checking the deletion of cookies from your web application page: Some times 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.
9) 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.
10) 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.
These are some Major test cases to be considered while testing website cookies. You can write multiple test cases from these test cases by performing various combination.

Cookies Usuage & its drawback

Applications where cookies can be used:

1) To implement shopping cart:
Cookies are used for maintaining online ordering system. Cookies remember what user wants to buy. What if user adds some products in their shopping cart and if due to some reason user don’t want to buy those products this time and closes the browser window? When next time same user visits the purchase page he can see all the products he added in shopping cart in his last visit.

2) Personalized sites:
When user visits certain pages they are asked which pages they don’t want to visit or display. User options are get stored in cookie and till the user is online, those pages are not shown to him.

3) User tracking:
To track number of unique visitors online at particular time.

4) Marketing:
Some companies use cookies to display advertisements on user machines. Cookies control these advertisements. When and which advertisement should be shown? What is the interest of the user? Which keywords he searches on the site? All these things can be maintained using cookies.

5) User sessions:
Cookies can track user sessions to particular domain using user ID and password.

Drawbacks of cookies:

1) Even writing Cookie is a great way to maintain user interaction, 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 can not perform any operation resulting in loss of site traffic.

2) Too many Cookies:
If you are writing too many cookies on every page navigation and if user has turned on option to warn before writing cookie, this could turn away user from your site.

3) Security issues:
Some times users personal information is stored in cookies and if someone hack the cookie then hacker can get access to your personal information. Even corrupted cookies can be read by different domains and lead to security issues.

4) Sensitive information:
Some sites may write and store your sensitive information in cookies, which should not be allowed due to privacy concerns.

This should be enough to know what cookies are. If you want more cookie info see Cookie Central page.

cookies & its Types

Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve information from that machine. Generally cookie contains personalized user data or information that is used to communicate between different web pages.

Why Cookies are used?
Cookies are nothing but the user’s identity and used to track where the user navigated throughout the web site pages. The communication between web browser and web server is stateless.

How cookies work?
The HTTP protocol used to exchange information files on the web is used to maintain the cookies. There are two types of HTTP protocol. Stateless HTTP and Stateful HTTP protocol. Stateless HTTP protocol does not keep any record of previously accessed web page history. While Stateful HTTP protocol do keep some history of previous web browser and web server interactions and this protocol is used by cookies to maintain the user interactions.

Whenever user visits the site or page that is using cookie, small code inside that HTML page (Generally a call to some language script to write the cookie like cookies in JAVAScript, PHP, Perl) writes a text file on users machine called cookie.
Here is one example of the code that is used to write cookie and can be placed inside any HTML page:

Set-Cookie: NAME=VALUE; expires=DATE; path=PATH; domain=DOMAIN_NAME;

When user visits the same page or domain later time this cookie is read from disk and used to identify the second visit of the same user on that domain. Expiration time is set while writing the cookie. This time is decided by the application that is going to use the cookie.

Generally two types of cookies are written on user machine.

1) 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. Some time session of say 20 minutes can be set to expire the cookie.
2) Persistent cookies: The cookies that are written permanently on user machine and lasts for months or years.

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 “Suresh” 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.

Why do we recommended that we test during the design phase?

Because testing during the design phase can prevent defects later on. We recommend verifying three things...
1. Verify the design is good, efficient, compact, testable and maintainable.
2. Verify the design meets the requirements and is complete (specifies all relationships between modules, how to pass data, what happens in exceptional circumstances, starting state of each module and how to guarantee the state of each module).
3. Verify the design incorporates enough memory, I/O devices and quick enough runtime for the final product.

Exceptional circumstances, starting state of each module and how to guarantee the state of each module). Verify the design incorporates enough memory, I/O devices and quick enough runtime for the final product.

Why Scalability and Load Testing is Important?

Some very high profile websites have suffered from serious outages and/or performance issues due to the number of people hitting their website. E-commerce sites that spent heavily on advertising but not nearly enough on ensuring the quality or reliability of their service have ended up with poor web-site performance, system downtime and/or serious errors, with the predictable result that customers are being lost.

In the case of toysrus, its web site couldn't handle the approximately 1000 percent increase in traffic that their advertising campaign generated. Similarly, Encyclopaedia Britannica was unable to keep up with the amount of users during the immediate weeks following their promotion of free access to its online database. The truth is, these problems could probably have been prevented, had adequate load testing taken place.

When creating an e Commerce portal, companies will want to know whether their infrastructure can handle the predicted levels of traffic, to measure performance and verify stability.

These types of services include Scalability / Load / Stress testing, as well as Live Performance Monitoring.

Load testing tools can be used to test the system behavior and performance under stressful conditions by emulating thousands of virtual users. These virtual users stress the application even harder than real users would, while monitoring the behavior and response times of the different components. This enables companies to minimize test cycles and optimize performance, hence accelerating deployment, while providing a level of confidence in the system.

Once launched, the site can be regularly checked using Live Performance Monitoring tools to monitor site performance in real time, in order to detect and report any performance problems - before users can experience them.

Microsoft Sharepoint Online

 

• Manage and share personal documents and insights with colleagues using MySites
• Keep teams in sync with shared document libraries, task lists and calendars with Team Sites
• Stay up to date on company news, events and business updates with Intranet Sites
• Share documents and insights securely with partners and customers using Extranet Sites
• Market your business with a simple and professional public-facing website
• Create office documents and save directly to SharePoint Online
• Set document-level permissions to protect sensitive content
• Access important documents offline
• Enable real-time communication with colleagues right from within SharePoint Online
• My Sites to manage and share documents
• Access documents offline

For more details please log on to :
http://www.office365-support.com/

What is Software Testing?

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test.^[1] Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs (errors or other defects).
Software testing can be stated as the process of validating and verifying that a software program/application/product:

1. meets the requirements that guided its design and development;
2. works as expected; and
3. can be implemented with the same characteristics.

Software testing, depending on the testing method employed, can be implemented at any time in the development process. However, most of the test effort occurs after the requirements have been defined and the coding process has been completed. As such, the methodology of the test is governed by the software development methodology adopted.
Different software development models will focus the test effort at different points in the development process. Newer development models, such as Agile, often employ test driven development and place an increased portion of the testing in the hands of the developer, before it reaches a formal team of testers. In a more traditional model, most of the test execution occurs after the requirements have been defined and the coding process has been completed.

EIGHT BASIC PRINCIPLES OF TESTING

Following are eight basic principles of testing:

1. Define the expected output or result.

2. Don't test your own programs.

3. Inspect the results of each test completely.

4. Include test cases for invalid or unexpected conditions.

5. Test the program to see if it does what it is not supposed to do as well as what it is supposed to do.

6. Avoid disposable test cases unless the program itself is disposable.

7. Do not plan tests assuming that no errors will be found.

8. The probability of locating more errors in any one module is directly proportional to the number of errors already found in that module.

Let's look at each of these points.

1) DEFINE THE EXPECTED OUTPUT OR RESULT

More often that not, the tester approaches a test case without a set of predefined and expected results. The danger in this lies in the tendency of the eye to see what it wants to see. Without knowing the expected result, erroneous output can easily be overlooked. This problem can be avoided by carefully pre-defining all expected results for each of the test cases. Sounds obvious? 

2) DON'T TEST YOUR OWN PROGRAMS

Programming is a constructive activity. To suddenly reverse constructive thinking and begin the destructive process of testing is a difficult task. The publishing business has been applying this idea for years. Writers do not edit their own material for the simple reason that the work is "their baby" and editing out pieces of their work can be a very depressing job.

The attitudinal l problem is not the only consideration for this principle. System errors can be caused by an incomplete or faulty understanding of the original design specifications; it is likely that the programmer would carry these misunderstandings into the test phase.

3) INSPECT THE RESULTS OF EACH TEST COMPLETELY

As obvious as it sounds, this simple principle is often overlooked. In many test cases, an after-the-fact review of earlier test results shows that errors were present but overlooked because no one took the time to study the results.

4) INCLUDE TEST CASES FOR INVALID OR UNEXPECTED CONDITIONS

Programs already in production often cause errors when used in some new or novel fashion. This stems from the natural tendency to concentrate on valid and expected input conditions during a testing cycle. When we use invalid or unexpected input conditions, the likelihood of boosting the error detection rate is significantly increased.

5) TEST THE PROGRAM TO SEE IF IT DOES WHAT IT IS NOT SUPPOSED TO DO AS WELL AS WHAT IT IS SUPPOSED TO DO

It's not enough to check if the test produced the expected output. New systems, and especially new modifications, often produce unintended side effects such as unwanted disk files or destroyed records. A thorough examination of data structures, reports, and other output can often show that a program is doing what is not supposed to do and therefore still contains errors.

6) AVOID DISPOSABLE TEST CASES UNLESS THE PROGRAM ITSELF IS DISPOSABLE

Test cases should be documented so they can be reproduced. With a non-structured approach to testing, test cases are often created on the fly. The tester sits at a terminal, generates test input, and submits them to the program. The test data simply disappears when the test is complete.

Reproducible test cases become important later when a program is revised, due to the discovery of bugs or because the user requests new options. In such cases, the revised program can be put through the same extensive tests that were used for the original version. Without saved test cases, the temptation is strong to test only the logic handled by the modifications. This is unsatisfactory because changes, which fix one problem often, create a host of other apparently unrelated problems elsewhere in the system. As considerable time and effort are spent in creating meaningful tests, tests, which are not documented or cannot be duplicated, should be avoided. 

7) DO NOT PLAN TESTS ASSUMING THAT NO ERRORS WILL BE FOUND

Testing should be viewed as a process that locates errors and not that proves the program works correctly. The reasons for this were discussed earlier.

8) THE PROBABILITY OF LOCATING MORE ERRORS IN ANY ONE MODULE IS DIRECTLY PROPORTIONAL TO THE NUMBER OF ERRORS ALREADY FOUND IN THAT MODULE

At first glance, this may seem surprising. However, it has been shown that if certain modules or sections of code contain a high number of errors, subsequent testing will discover more errors in that particular section that in other sections.