Tracking the URL's used in the application and having the ability to modify them

Any software application would be using many URL's in them. For example, when you take a product, you could have the following URL's in the product:
- A link for the product's home page on the organization site
- Links for Help pages
- Links for Video tutorial
- Links for customer support
- Links for online pages where the workflow is a mix of desktop and online components
- A link where a customer can buy the product
- When the product used 3rd party components, the workflow may be pointing to 3rd party links

There are complications that come in because of the 3rd party links. For example, I have run into cases where the 3rd party component that we were using became like an orphan because the organization that had provided us the component became bankrupt and closed down (was not purchased by another organization, just shut down). In this case, the component still continued to work, but the link was no longer existing. However, the link was the last part of the workflow and there would be a percentage of the users who would still click on the link and thus run into a problem.
For this purpose, the policy that should be followed should be to ensure that all the links that are actually used in the application are redirect links, where the redirect happens on the servers of the organization and the target of the link can be modified. Doing it in such a way will ensure that even in the case of the above situation where the link for the 3rd party does not exist, the modification of the redirect URL can happen on the company server and point to an alternative workflow (such an alternative workflow could even mean just pointing out to the customers that because of business reasons, the final part of the workflow does not work any more and apologize for the same). This is better than being in a situation where the workflow leads to an error, since that makes the customers think that something is not working, and if the error is not rectified, they start wondering about why the organization is not correcting the error.
However, there is a lot of book-keeping that needs to happen for this. All these links, with the date of creation, the target destination and the person who created the links (and of course, any description of what the link was meant for) are essential pieces of information to capture. This ensures that in the future, if the person who created the link is no longer with the organization, the replacing person has a good amount of knowledge about these links.

Capturing information from within the product - Need to balance the privacy perspective

This is a post that is again based on real life experience. Let me lay out an example to you. Lisa is the program manager of a team which is developing a new version of a software that prepared greeting cards. The software allows the users to add their own images or use images that are available within the software, and you can do the same for greetings and videos, and the output is a rich electronic greeting card that can be sent out by email or posted on social networking platforms, and it even provides a more plainer output that can be printed.
Now, this card needs to work on many different operating systems, needs to work at machines with different performance parameters, and also needs to work on different browsers. How do you get this sort of information ? Well, you can get this information from users in the terms of mailers, surveys, questions from within the software, and other such ways, or you can get it from the users own machines. So, Lisa did some discussion with her team, and came out with a technical solution - there will be some tracking devices built within the software that will, on every launch, report back to the company about the platform and browser that is there on the machine of the user and this data will be located in a database where this information can be mined.
In the next version of the software, this process worked out real well. The team was very enthusiastic about the capabilities of retrieving all sorts of information from the user's machine and starts building more of this. Lisa also got swept along in this tide and was an enthusiastic collaborator about trying to determine what more information can be mined. And all of this was done with the best of intentions. So, there was a need to know which printers the users were having, since this would allow the determine which printers were most often used (the belief was that more customers would be using low end printers given the profile of customers), and this would allow some more optimization of the printing capabilities.
Piracy was a big problem, so there was a thought about tracking the serial number on the user's machine, and also getting the machine name and any other such information that would allow identification of the user. Somebody had a bright idea about trying to determine whether the customers were also using a rival software, which was not easy to track, but they managed to do it by searching the registry for the other rival software. By this time Lisa was getting a bit nervous, all her instincts were reporting problems.
And then the whole thing blew up. A user who had a personal firewall and a bit of paranoia found that the software was causing a number of hits on the firewall, and decided to investigate further. As he investigated and reported, other users also started getting curious and doing investigations, and also reporting more such issues, and also raising questions on the user forums. The legal department of the company stepped in and wanted to know what all information was being tracked, and why (WHY in capital terms) they were not consulted. It turned out that there are privacy implications, and every legal team has a list of items that they find fine to track, and other info on the user's machine which absolutely cannot be tracked. The tracking of a rival installation was way beyond what was permissible, and caused a lot of problems when it was discovered.
The company did a mea culpa (not fully though), and also promised that they will ensure that at the time of installation, there will be a note that will let the users know about what all information is being tracked, and also provide the users with an option about tracking such information (this language was all couched in very positive words, but it was far more than what the team was doing). So, when you start trying to get info from the user through your software, make sure that what you are doing is above board. 

What is a follow up alert? How to create follow up alerts in test director?

Test director is mercury interactive’s test management tool. 

- It helps in creating a quality assurance personnel plan and organizing the whole testing process usually termed as the test director testing process.

- It lets you build a data base consisting of the manual as well as automated test cases, test cycles, run tests, reports of the tracking defects and so on. 

- The test director instructs to create alerts automatically and notify the responsible people whenever some changes are encountered by the project. 

- Alerts are generated for the changes that affect the project in one or more than one ways. 

- For generating automatic alerts, the administrator can activate the trace-ability notification rules based on the associations made among the requirements, defects and test.

What is a Follow Up Alert?

- Test director allows to add own follow up flag to a defect, test instance or a specific test so as  to remind oneself to follow up on an issue. 

- When the date of actual follow up arrives, an e – mail is send to the person’s mail box. 

- Test director notifies the tester by adding a trace that changes the flag to the changed entity or by mailing a notification whenever a change is made to the requirement, defect or test in the project. 

- Creating follow-up alerts is always useful since you are always reminded whenever it is required to follow up on some issues. 

Requirements for Follow up Alert

- Test director 8.0 should be installed on your system. 

- You must have access to all the four modules of the test director namely requirements, test plan, test lab and defects. 

- You must have either a sample project or an actual project on which you carry out the exercise.

- Work with a new copy of the project. 

- You should also have either a sample application or an actual application.  

Now we shall discuss the procedure to add a follow up flag to a defect whose status requires to be checked. 

When the follow up date comes, the flag icon is turned to red color and the test director sends a notification via e – mail. One thing that you should always take care of is that the flags have a specific user name which means only the user whose name is on the flag will be able to see it. 

Steps to create a Follow-up Alert

Follow the steps mentioned below to create a follow up alert:

1. Click on the defects tab so as to turn on the defects module.
2. From the defects grid select the defect for which you want to set up a flag to follow  up.
3. Now for creating a follow up alert click on the ‘flag for follow up’ button and a flag for follow up dialog box will open up. Fill in the following details:

a)   Follow up by: select the date.

b)   Description: type:

Once done with filling up the details click ok. A flag icon will be added to the      defect record by the test director.

4. To display the information bar for your follow up alert, double click with the follow up flag on the defect. A defect details dialog box will pop up and will display a yellow information bar with the follow up alert.
5. To close the dialog box click on cancel button.

How is test management done by the test director?

If you are familiar with all the concepts of the test director you can apply them to your software systems or applications since you know how it works.

The test director implements the test management via four major phases as mentioned below:

1. Specification of the requirements
2. Planning the tests
3. Execution of the tests
4. Tracking the defects

Throughout each of the phases the date can be analyzed by the detailed reports and graphs generated earlier. Firstly, you need to analyze your software system or application and determine all of your testing requirements. 

Phase I - specification of Requirements

The first phase of the test director test management process involves the following steps:

1. Examination of the documentation of the software system or application for the determining the testing scope i.e., test goals, strategies, objectives etc.
2. Building of a requirements tree for defining overall testing requirements.
3. Creation of a list of detailed testing requirements for each topic mentioned in the requirements tree.
4. Writing a description for each requirement, assigning a priority level to it and adding attachments if required.
5. Generation of the reports and graphs for providing assistance in the analyzation of the testing requirements.
6. Carrying out a review of the requirements to check if they meet the specifications.

Phase II - Planning the Tests

The second phase involves the following tasks:

1. Examination of the application, testing resources and system requirement for determining the test goals.
2. Division of the application in to modules to be tested and building of a test plan tree to divide the application in to testing units hierarchically.
3. Determination of the type of tests that are required for each module and adding a basic definition of each test to the test plan tree.
4. Linking each test to the corresponding testing requirement.
5. Developing manual tests where each test step describes the test operations and expected outcome. Deciding which tests are to be automated.
6. Creation of the test scripts for the tests that are to be automated using a custom testing tool such as mercury interactive testing tools.
7. Generation of the graphs and reports for the analyzation of the test planning data.
8. Reviewing the tests for determining their suitability to the testing goals.

Phase III - Execution of tests

Third phase involves the following activities:

1. Defining the tests in to groups so as to meet various testing goals of the project. This may involve testing a new version of the application or a specific function in it.
2. Deciding which all tests are to be included in the test set.
3. Scheduling the execution of the tests and assigning tasks to different application testers.
4. Execution of the tests either manually or automatically.
5. Viewing the results of the test runs for determining if a detect was detected in the application under test and generation of the reports and graphs for analyzation of the results.

Phase IV - Tracking the Defects

The last phase of the test management i.e., defect tracking involves the following activities:

1. Submitting new defects detected in the software system or application. Defects can be added during any phase by QA testers, project managers and developers etc.
2. Carrying out a review of the new defects and determining which ones are to be fixed.
3. Correcting the defects that were decided to be fixed.
4. Testing the new build of the software system or application and repeating the whole process until all the defects are fixed.
5. Generation of the graphs and reports to provide assistance in the analyzation of the progress of the defect fixes and determining the date when the application is to be released. 

How to track defects in Test Director?

A software system or application cannot be considered productive and useful if it is full of defects. Hence, it becomes quite essential that all the defects present in the software system or application are located and repaired appropriately during the development process.

The end users, testers and developers can submit the defects that are detected during all the phases of the testing process. The test director helps incredibly in the submission of the defects detected in the software and tracking of them till they are well repaired. 

Life-cycle of a Defect

- Whenever a defect is submitted to the test director project, there are certain stages through which the defects are tracked namely:

1. New
2. Open
3. Fixed
4. Closed

- Once a defect is fixed, the tester can either reject it or reopen it. 

- At the initial stage of reporting the defect to the test director, the status that is assigned to the defect is ‘new’ by default. 

- The defect is reviewed by either a quality assurance or a project manager and it is determined whether or not the defect is to be considered for repair. 

- If the defect is not considered for repair i.e., if it is rejected the status ‘rejected’ is assigned to it. 

- If the opposite case is there i.e., if the defect is accepted for repair it is assigned a repair priority by the project manager or quality assurance and the status ‘open’ is assigned to it. 

- This defect is now assigned to one of the members of the development team for repair. 

- The developer repairs the defect and then the status ‘fixed’ is assigned to it. 

- The software system or application is then retested, thus ensuring that there is no occurrence of the defect again. 

- Even if in case the defect recurs, it is again assigned a new status ‘reopened’ by the quality assurance or project manager. 

- But if the defect gets properly repaired the status ‘closed’ is assigned to it by any of the two managers. 

- The test director also provides the option of adding some new defects to an existing test director project. 

- All information and data regarding the defects found within a software system or application is handled by the defects module of the test director.

- The following are the defects that are undertaken by the defects module of the test director:

1. Creation of the defects.
2. Editing of the defects.
3. Linking defects to each other.

Stages of Defect Tracking Process

The following stages are involved in the defects process:

1. Adding of the defects
2. Reviewing of the new defects
3. Repairing open defects
4. Testing of new build
5. Analyzation of the defect data

- In the first stage of the defect tracking process, the new defects detected in the software system or application are reported. 

- In the next stage, the new defects are put through a review process and the defects to be fixed are determined. 

- In the third stage, the defects are corrected by the developers who have been assigned to do the task.

- In the fourth stage, the new build of the application is tested and this process is continued until and unless all the defects are repaired. 

- The last stage of the defect tracking process witnesses the generation of the reports so as to provide some assistance to the developers for the analyzation of the progress of repairing the defects. 

- Also, in this stage, the date of release of the software system or application is determined. 

- Later, it is determined whether to cancel the rejected defects or take action on them further. 

- The following productivity tools assist the process:

1. Views
2. Filters
3. Sort
4. Manage columns
5. Favorites

How to develop a test plan tree in Test Director?

Testing a software system or application is not a child’s play rather it requires whole lot of focus, organization, management and vigor. Testing phases or tasks such as specification of the testing requirements, planning and execution of the tests, tracking of the defects are made quite easy with the test director. 

In this article we shall discuss about how the test plan trees can be developed using the test director. After the all of the testing requirements have been defined, the testing goals need to be determined by carrying out various activities such as:

1. Examining the testing as well as the system environment.
2. Examining the software system or application under test (SUT and AUT).
3. Examining the testing process

- These three activities are particularly carried out so that the testing strategy designed to achieve the testing goals can be outlined. 

- After testing goals are determined, one proceeds to build a test plan tree. 

- The purpose of this test plan tree is to hierarchically divide the software system or application under testing in to smaller testing units or one can call them ‘subjects’.

- For each subject or unit in the test plan tree some tests are defined consisting of steps. 

- Next, the actions to be performed on the application as well as the expected results are defined for each of those steps. 

- Addition of parameters to the test step adds to its flexibility. 

Now how to keep track of the relationships shared by the testing requirements and tests? 

- Just add links between the two corresponding things.

- Other than being simple, another benefit of adding links is that you can be assured of the compliance with the requirements in all the stages of the testing process. 

- After getting done with this, you decide which all tests you want to get automated. 

- If you see the application as a whole unit to be tested it seems like a very big thing. 

- Here, in the test director, the application is divided into smaller units based up on its functionality with the help of the test plan module. 

- Test plan tree serves all this purpose and is referred to as the graphical representation of the test plan.

- Here the tests are displayed on the basis of the hierarchical relationship in their functions. 

- After all the subjects in the test plan tree have been defined the next step involves creating step for each and adding them to the tree.

- The below mentioned are the steps to be followed:

1. Open and log on the project for which the testing process is going on.
2. Make sure that the test plan module is on display and if it is not click on the test plan module to do so.
3. Now you need to add a subject folder to the test plan tree by clicking on the new folder button. Give a name and description for the folder and hit OK button. You will see a new subject folder under the main subject folder in the test plan tree.
4. Next step is to add a test to the folder we created above by clicking on the new test button. Give a name for test and click OK. You will require to fill in the following details like level, review status and priority. This test then will be added to the test plan tree.
5. Go to the details tab and you can fill up the following details:

a)   Test name

b)   Test designer

c)   Creation date

d)   Test status etc.

e)   description

What is the Test Director Testing Process? What are the phases involved in it?

Mercury provided the world with its first global test management solution popularly known as the test director. Test director has helped many of the organizations in the deployment of very high quality software systems and applications in a quick and efficient manner. 

There are 3 module requirements of the test director on which it operates namely:

1. Test plan
2. Test lab
3. Defects

The above mentioned three module requirements seem to be well integrated providing a way for smooth flow of the information between the various phases of testing.

Up on adding the script editor to all the modules any methodology and best practice can be enforced or followed by the test director based up on the customized requirements of the organization. 

There are several facilities and features that able the users to customize the test director as per the requirements of their projects for capturing the data as needed in the whole testing process such as:

1. Greater number of available user fields
2. Ability to add memo fields
3. Creating input masks

Following processes are incorporated in the test director testing process:

1. Requirements management
2. Scheduling
3. Planning
4. Executing tests
5. Issue management
6. Project status analyzation

What are phases in Test Director Testing Process?

1. Planning Tests: 

In this phase the application software to be tested is broken down in to various test subjects and a project is build. The testing goals as well as objectives are defined keeping all the requirements in view.The following three things are examined so that it can be determined that how and in what way the testing process will take place:

a)   Application software

b)   System environment and

c)   Testing resources

- Next step in this phase, is to provide a definition for each of the test subjects by further dividing them in to test director modules to be tested.  

- A test plan tree is drafted representing the hierarchy among the test subjects. 

- Tests are defined and broken in to steps where each step gives the description of a particular operation that is to be performed. 

- For each test, the output that is expected is determined. 

- Now the turn comes to automate the tests if you are following the automation testing. 

- Here, you will need help from Winrunner for creating the automated test scripts in test script language or TSL. 

- Once all is done, go through your test plan and analyze all the reports, graphs etc.

- Have a rough determination of whether your test plan will be able to meets the defined goals or not.

2. Execution of the Tests: 

- Tests are grouped into suites and running them. 

- Once you have the test schedule in your hand you can start assigning the tasks to the testers and start executing. 

- The graphs and the reports thus generated after the execution of the tests help in the determination of the progress level of the test execution. 

- While the execution of the test suites is in progress there is a need that you keep analyzing how the testing process is going on with the help of the graphs as well as reports.

3. Tracking of the Defects: 

- In this phase the defects that you discovered need to be reported to the management.

- When the defects are repaired, you need to analyze how the repair process is going on. 

- Information and details regarding all the discovered defects are to be stored in the data base meant for storing defect data. 

- After the repair process is complete, put the application once again through the tests and check if again some discrepancy is encountered. 

- After you are done with the analyzation process you can decide when the project is to be released. 

What is meant by defect tracking automated system?

Defects and bugs upset every software system or application and thus it becomes necessary to root them out as early as possible. Tracking the defects and bugs in a software system or application proves to be quite a headache for the tester. It is like searching for one particular fish in an ocean.

Over the years new and advance technologies are being designed to improve the defect tracking methodologies and thus relieve the testers and developers of this headache. Most of the testing processes are now being automated and one of the resultant of this effort is the “defect tracking automated system” which is all what has been discussed in this article.

About Defect Tracking Automated System

- As the name of the system itself suggests it is a tool which tracks the defects and bugs all by itself with the help of the automated processes.

- This defect tracking automated system is easier to use and operate and implement.

- It can carry out many of the testing processes on its own, some instructions from the tester are required.

- The tester just has to sit back and justify the outcomes.

- The automated working of this defect tracking system is what makes this system different from the others.

- Automation is something very common nowadays in the field of computers and this feature has allowed the testers who have less knowledge and experience to carry out the testing process with confidence.

- This is so because this automated defect tracking system makes use of a few commands and simplified options to guide the tester to carry out the whole process so very efficiently and it is so very user friendly.

- There is no need for the tester to mug himself/ herself up with the knowledge of the whole process because anyways the system is smart enough to handle all the processes itself.

- This even makes it easy to teach it to the other fresh testers who don’t have any experience.

- Another feature of defect tracking automated system is that all of its functions are self explanatory.

- The idea of having an automated system has to be simple and easy to understand otherwise it is of no use.

- The evaluation of the defect tracking system in terms of its efficiency and detection rate is also very important concern and helps in deciding for the better defect tracking automated systems.

- But, for the evaluation of the tracking system one needs to know about its specific features and understand the work flow of the system.

- He/ she should be able to relate it to the requirements of the application under testing.

- Also, the defect tracking automated system needs to be in sync with the current bug tracking process.

Requirements of the System

- Before you start evaluating your defect tracking automated system, make sure that you have identified all the requirements of the system because these requirements are required to guide the evaluation process.

- These requirements need to be converted in to a features list like one shown below:
1. Adaptability
2. Change history
3. Customizable fields
4. E mail notifications
5. Security
6. Web based client
7. Work flow

- Some defect tracking automates systems can also be used to track the other types of issues like:
1. Test cases
2. Purchase orders
3. Support calls etc.

If the tracking system that you are using has been specifically designed for the purpose of bug tracking then you will have a hard time in adapting the system to track the other issues. Before starting tracking the bugs make sure that you have set the right commands to the system.

What is meant by defect leakage?

Defects can be defined as any discrepancies that can disrupt the functioning of a software system or application and often they are known to give nightmares and headaches to the software testers.

WHAT ARE DEFECTS?
- Defects are responsible for the production of incorrect or unexpected results and abnormal behavior of the software program.
- Defects are a consequence of the mistakes made by the software developers.

It is very difficult to set straight a buggy program. There are so many concepts that revolve around these defects. One of such concepts is defect leakage and we will be discussing it here in this article.

DEFECT LEAKAGE
- You can imagine water leaking out of a container having holes in it. We can take the defect leakage in the same context and define it.
- The defect leakage can be thought of as a phenomenon in which the defects leak out in the entire software system or application.
- It is due to the presence of the means for the escape of the defects.
- No present software testing methodology is so efficient that it can discover or dig out all the errors and bugs.
- Even after many times of rigorous testing still many bugs remain in the software system or application hidden and undiscovered.
- These defects are discovered later during the latter stages of the software development life cycle.
- Such defects are said constitute the defect leakage factor.
- Tracking the defect leakage is very time consuming process as well as effort consuming process.

APPROACHES FOR FINDING DEFECT LEAKAGE

APPROACH #1:
- The commonly followed approach for finding the defect leakage is the matrix method.
- The defect leakage can be tracked down using a standard matrix provided you can spare much of your time for following this approach.
- You will require to analyze all the defects and determine where actually the defect would have been discovered when those stages were in progress.
- Defect leakage indicates a lot about your programming efficiency and testing skills.
- If a lot of gap exists in your findings then it indicates that your testing and programming efficiency is quite low.
- In some cases it happens that you find defect leakage in the unit level which you could have discovered then and there itself and if not there at least that could have been caught at the level of the integration testing.
- The gap here that we are talking about is nothing but the difference between the actual defect logging time and ideal defect logging time.
- Defect leakages add to greater headaches than the usual defects so try avoiding them as far as possible by following a proper testing strategy and an effective test plan.
- All you need to do is to keep all your processes systematic and organized.
- If you are having a lack of time and need a fast completion of your testing work, then there is a greater probability that you may leave many bugs and errors here and there and later have problems with the defect leakages.

APPROACH #2:
- Another approach that you can follow is using a defect tracking automated system.
- This system files up a detection phase whenever a bug is logged.
- This bug is then rectified in the injection phase.
- Following this approach you can easily define the bug slippage also.
- You can also define the areas in which improvement is needed.
- This approach requires appropriate categorization of the defect injection phase.
- The categorization depends on the perception of the tester.
- A leaked defect is the one that could not be discovered during the usual testing but showed up during the production of the software.
- The documentation for the defect leakage is not produced by the quality assurance people.
- The reason why a defect was missed during the testing is often probed by the program managers.

What are different test cases for testing web application cookies?

To carry out any testing, you need to create effective test cases. Then only you will be able to fetch more appropriate outcomes from the testing. To develop effective test cases for web site cookie testing, you need to understand how the cookies are stored and managed.

Whenever you use a web site a cookie will get written on to your hard disk. Normally cookies are stored in the following format:

Site: abc.com RMID (name of the cookie)
Name: RMID
Content: 1d14c8ec45bf79e0… (Written in Encrypted format)
Domain: .abc.com
Path: / (the path after the name of the domain)
Send For: the type of the connection
Expires: Tuesday, December 31, 2015 10:25:25 PM date of expiry as set by the developer)

The cookies are used for the following applications:

1.Implementation of the shopping cart:
Cookies are used to implement online product or service ordering system. Cookies are a way to remember what the user wants to purchase. Suppose, if at the instant of time the customer adds some products to his carts and closes the browser window, then the cookie remembers what he/ she wants to buy and the customer can see ll those products.

2. Personalized web sites:
When we are browsing and visit certain pages. We are asked whether or not to display this page. The user instruction is stored in the cookie and those pages are displayed or not displayed as per the wish of the user.

3. Marketing:
Cookies are extensively used to advertise on the web sites. These advertisements are controlled by the cookie itself.

4. User tracking:
Cookies are used to track the number of visitors of a web site.

5. User sessions:
User sessions can be tracked using the cookie using the contained user ID and the password.

Apart from the benefits, the cookies have some drawbacks also. These are:
- Some times disabling the cookies can lead to disabling of the site itself.

- If too many cookies are being written on each and every page navigation, and if the cookies are enabled, this can lead to user frustration can result in the loss of traffic.

- Cookies are concerned with security also.

- Some cookies contain user’s personal information and if they are hacked, then the hacker gets access to the user’s personal information.

- Some sites store your sensitive information cookies. This is not advisable since it can lead to serious privacy concerns.

Test Cases for testing Web Application Cookies

- First test case should test whether the application is writing the cookies on the disk properly or not?

- The privacy policy of the cookie makes sure that your personal information is not written in to the cookie. It also makes sure that no sensitive data is leaked.

- Even if some sensitive data is stored in the cookies, it is made sure that the data is stored in the encrypted format.

- Overuse of cookies can annoy the users if the browser prompts for cookies frequently. This can cause loss of traffic of the web site.

- Disabling of cookies can cause some functionalities of the web site to become disabled or the site may not function properly. But always ensure that there is no page crash during the testing. Delete all the previous cookies.

- Acceptation and rejection of some cookies: this is probably the best way to check the functionality of site. All you have to do is accept only some of cookies and reject the others. For executing this case, you can set your browser settings so as to prompt you whenever a cookie is being written so that you can accept or reject that cookie. Observe the behavior of site.

- Corruption of cookies by editing their content.

- Testing of cookie on multiple browsers.

What are different aspects of web site cookie testing?

In the last post, we already discussed what a cookie is and how and when they are used. So let us explore a little more about these cookies. Here we are going to discuss how the websites that use cookies are tested.

Disabling the cookie

Disabling the cookie feature is perhaps the easiest concept under website cookie testing. Disabling the cookies is the first step in web site cookie testing.

- How the turning off or disabling of the cookies does affects a web site? You can check out by yourself.

- Clean up all the cookies and close all the open browser windows of the site that is to be tested.

- When you close the browser windows, the session cookies are automatically deleted.

- Keep the cookie folder open while you are browsing the site.

- You have to close the browser in order to delete all the cookies.

- You will notice that as you close the browser, the session cookies are automatically deleted.

- Now you disable the cookies and try using the features of the website.

- You will observe that most of the features do not work since the cookies have been disabled.

- So we can conclude that the disabling the cookies, disables the functionality of the web site.

To use the website, the cookies must be enabled.
- The question here worth asking is that whether or not the server of that website is able to recognize its failure while attempting to set the cookies?

- And if it is recognizing also, does it send a notification or a message to user stating that the cookies must be enable in order for that web site to work?

- If this is not the case then the user will keep on trying to use the web site and will get frustrated without knowing that why the web site is not responding.

Amazon.com is one of the websites that work well even without the cookies. In such kind of web sites, the maintenance of the state if taken care of by the server side on the basis of the session ID stated at the end of the URL of the home page.

The URL of the home page of the web site was:
www.amazon.com/…/home.html/104-0233809-0567844

- The rightmost digit was changed from 4 to 5 and reposted in the URL.

- Amazon discards the edited URL and effectively recovers from the URL corruption by creating a URL with the help of a new session ID:
www.amazon.com/…/home.html/107-0357660-1139507

- From the above observation we conclude that the above hypothesis is correct.

To understand the test cases you need to understand how the cookies work and how they are stored and how the cookie settings can be edited? Here we are going to list some test cases for web site cookie testing:


- In concern to your privacy, the cookie privacy policy takes care that your personal data is not stored or used by the cookie.

- If no, then the cookie will save your sensitive data in an encrypted format.

- Always make sure that there is no over usage of cookies on the web site under test.This can annoy the users since the browser will prompt for cookies more often and this can cause a decline in the site traffic.

- If the site under test makes use of cookies, then it will not function properly on the disabling of cookies. Try to navigate through the website and use the features. But, make sure that the web site does not crash.

- Corruption of cookies
Change the values of the cookies to some vague values by editing them in note pad. You may later the contents of the cookie or change the parameters and observer the behavior of the website.

What are cookies and its types? Where are cookies used?

A cookie or an HTTP cookie can be defined as a message used by an origin website to send the information about the state to the browser of the user and by the browser to send the information about its state to the origin site.

An HTTP cookie is known by many names such as web cookie, browser cookie etc.

The information of the state that is sent across the origin site and the user’s browser is used for the purpose of:

- Authentication
- Identification of the session of an user
- Preferences of the user and
- Contents of the shopping cart

In other word HTTP cookies are used for any purpose that can be accomplished using the process storing text data on the computer of the user.

Characteristics and Uses of Cookie
- The main characteristic of Cookies is that they cannot be programmed and thus, cannot carry any kind of viruses or worms.

- Any malware cannot be installed on the host system with the use of a cookie. So they are safe to this extent.

- However, cookies can be effectively used by a spyware to track the browsing activities of the users.

- This is a major privacy concern and has prompted European and US law makers to take action in the past few years.

- Cookies are very easy to steal and are thus often misused by the hackers.

- Hackers steal the cookies and use them to gain access to the web account of the victim.

- Cookies were first used to solve the problem of implementation of the shopping cart.

- Initially the cookies were developed for the Netscape browser.

- They were used to check if the earlier visitors visited the site again.

- Later cookies were developed for internet explorer and other browsers.

- The concept of the cookies was not widely known to the public at that time.

The term “HTTP cookie” came into existence in the year of 1994. It has been derived from “magic cookie”.

What are Magic Cookies?
- Magic cookie was actually a data packet that a program receives and sends again to the program on the other side without altering the contents of the packet.

- Magic cookies were used in computing systems long back and were introduced in web communications by Lou Montulli in June 1994.


The development of a cookie for formal specifications is always in progress. Till date many types of cookies have developed. They have been discussed below:

Session cookie:
- This cookie has a lifetime equal to the time period of the user using the website.
- These cookies are automatically deleted after the end of a session.

Persistent cookie:
- These cookies last even after the session has expired.
- If a persistent cookie has its maximum age set to one year, then till the one year is over, the cookie will be sending information to the server every time the website is visited.
- These are also called tracking cookies.

Secure cookie:
- These cookies are used by the browser if it accessing server through an HTTPS connection.
- This ensures that the cookie is always encrypted during the transmission of the information.
- This prevents cookie theft.

HTTP only cookie:
- This type of cookie is mostly supported by all the modern browsers.
- On a browser which supports HTTP, an HTTP only cookie is used during transmission of HTTP requests.
- It restricts the access from other non HTTP scripts.

Third party cookie:
- The first party cookies are set with the same domain or sub domain in the address bar of the browser.
- But, third party cookies are set with various domains other than the one mentioned in the address bar.

Super cookie:
- A cookie with a public suffix domain like .co.uk, .com etc.

Zombie cookie:
- This cookie is automatically recreated after its deletion.

What is Earned Value Analysis (EVA) in Project Scheduling?

Earned Value Analysis(EVA) provides a quantitative indication of progress. The project manager uses this method to track the project. Proponents of the earned value system claim that it works for every software project irrespective of the kind of work. As a part of this, there is an initial estimation of the total number of hours of doing this project, with every task being given an earned value which is based on its estimated percentage of the total effort. In simpler terms, a project manager will be able to determine, through a quantitative analysis, how much of the project is actually complete.

As a part of this process, the following steps are needed to be done:
- The BCWS (Budgeted Cost of Work Schedule) is evaluated for each task that is included in the project. This estimation is done in terms of person-hours or person-days(if the effort is much more than a few hours). So, for a given work task its BCWS is the effort.
- All the BCWS that are calculated for all the tasks are summed up to get a value called BAC(Budgeted Completion).
- The next variable BCWP(Budgeted Cost of Work Performed) is calculated. The method to calculate BCWP is by taking BCWS value for all the tasks that have been completed(at any point in the schedule).

In simple terms, the difference between BCWS and the BCWP is that BCWS is the estimate for all task that was supposed to be done, while BCWP is the summary of all the activities that were completed.

EVA compares the planned amount of work with what has actually been completed, to determine if cost, schedule, and work accomplished are progressing as planned. Work is earned or credited as it is completed.

Earned Value Analysis
- compares like terms and is quick to apply in practice.
- requires the ongoing measurement of the actual work done.
- tasks that have not been started or that have been completed are relatively easy to quantify in terms of earned value.

Define the tracking progress for an object oriented project?

For a object oriented project, tracking becomes really difficult and establishing some meaningful milestones is also a difficult task as there are many things that are happening at once. For tracking an object oriented project, following milestones are considered to be completed when the below mentioned criteria are met:

Milestone for Object Oriented Analysis is considered completed when the following conditions are satisfied :
- Every class is defined and reviewed.
- Every class hierarchy are defined and reviewed.
- Class attributes are defined and reviewed.
- Class operations are defined and reviewed.
- Classes that are reused are noted.
- The relationships among classes are defined and reviewed.
- Behavioral model is created and reviewed.

Milestone for Object Oriented Design is considered completed when the following conditions are satisfied :
- Subsystems are defined and reviewed.
- Classes are allocated to sub systems.
- Classes allocated are reviewed.
- Tasks are allocated.
- Task allocated are reviewed.
- Design classes are created.
- These design classes are reviewed.
- Responsibilities are identified.
- Collaborations are identified.

Milestone for Object Oriented Programming is considered completed when the following conditions are satisfied :
- Classes from design model are implemented in code.
- Extracted classes are implemented.
- A prototype is built.

Milestone for Object Oriented Testing is considered completed when the following conditions are satisfied :
Debugging and testing occur in concert with one another. The status of debugging is often assessed by considering the type and number of bugs.
- The correctness of object oriented analysis and design model is reviewed.
- The completeness of object oriented analysis and design model is reviewed.
- Collaboration between class and responsibility is developed and reviewed.
- Test cases designed are conducted for each class.
- Class level tests are conducted for each class.
- Cluster testing is completed and classes are integrated.
- Tests related to system testing are established and completed.

Each of the milestone is revisited as object oriented process model is iterative in nature.

Project Scheduling - Different ways for tracking the schedule.

A proper project schedule is very important for a successful project delivery. The project schedule is a road map for a software project manager. A project schedule needs to be properly developed. A proper project schedule defines the tasks and milestones that are tracked and controlled as project proceeds. This tracking needs to be accomplished nicely and there are different methods and ways to do so...

- Timely project meetings regarding the status of the project are held and it should be ensured that each team member should report the progress achieved and the problems that are faced.
- There are different reviews that are conducted throughout the software engineering process. It becomes necessary to evaluate the results of all these reviews in order to accomplish proper tracking.
- To accomplish proper tracking, for each task of the project, the actual start date and the planned start date should be compared.
- To accomplish tracking, one should determine whether the formal project milestones are achieved by the scheduled date.
- To accomplish tracking, progress should be assessed quantitatively.

The best indication of progress is the completion and successful review of a defined software work product.
The control administers the project resources, cope with problems and direct the project staff. Control is light if the project is on schedule and within budget. The control is exercised to reconcile the problems if they occur.

In case the problem is identified and diagnosed:
- staff is redeployed
- additional resources should be focused on problem area.

A severe deadline can be managed by time-boxing technique. It chooses an incremental software paradigm and a schedule is derived for each incremental delivery. This technique is done when the product may not be deliverable by a pre-defined deadline.

What is Software Project Management? List the number of tasks it consists.

In Software Project Management, the end users and developers need to know the length, duration and cost of the project. It is a process of managing, allocating and timing resources to develop computer software that meets requirements. It consists of eight tasks:
- Problem Identification
- Problem Definition
- Project Planning
- Project Organization
- Resource Allocation
- Project Scheduling
- Tracking, Reporting and Controlling
- Project Termination

In problem identification and definition, the decisions are made while approving, declining or prioritizing projects. In problem identification, project is identified, defined and justified. In problem definition, the purpose of the project is clarified. The main product is project proposal.

In project planning, it describes a series of actions or steps that are needed to for the development of work product. In project organization, the functions of the personnel are integrated. It is done in parallel with project planning.

In resource allocation, the resources are allocated to a project so that the goals and objectives are achieved. In project scheduling, resources are allocated so that project objectives are achieved within a reasonable time span.

In tracking, reporting and controlling, the process involves whether the project results are in accordance with project plans and performance specification. In controlling, proper action is taken to correct unacceptable deviations.

In project termination, the final report is submitted or a release order is signed.

High-level Best Practice Six(6) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first five areas and there practices are already discussed.

Process

- Track change packages. Even though each file in a codeline has its revision
history, each revision in its history is only useful in the context of a set of related files. Change packages, not individual file changes, are the visible manifestation of software development. Some SCM systems track change packages for you; if yours doesn’t, write an interface that does.
- In order to make propagating logical changes from one codeline branch to another easy, tracking change packages has a benefit. However, it’s not enough to simply propagate change packages across branches; you must keep track of which change packages have been propagated, which propagations are pending, and which codeline branches are likely donors or recipients of propagations.
- SCM process should be able to distinguish between "What to do" and "What was done".
- Every process, policy, document, product, component, codeline, branch, and task in your SCM system should have an owner. Owners give life to these entities by representing them; an entity with an owner can grow and mature.
- The policies and procedures you implement should be described in living documents; that is, your process documentation should be as readily available and as subject to update as your managed source code.

How to support a reliable communication in transport layer ?

At the Transport layer, each particular set of pieces flowing between a source application and a destination application is known as a conversation.To identify each segment of data, the Transport layer adds to the piece a header containing binary data. This header contains fields of bits. It is the values in these fields that enable different Transport layer protocols to perform different functions.

Reliability means ensuring that each piece of data that the source sends arrives at the destination. At the Transport layer the three basic operations of reliability are:
- tracking transmitted data.
- acknowledging received data.
- retransmitting any unacknowledged data.

This requires the processes of Transport layer of the source to keep track of all the data pieces of each conversation and the retransmit any of data that did were not acknowledged by the destination. The Transport layer of the receiving host must also track the data as it is received and acknowledge the receipt of the data. These reliability processes place additional overhead on the network resources due to the acknowledgement, tracking, and retransmission. To support these reliability operations, more control data is exchanged between the sending and receiving hosts. This control information is contained in the Layer 4 header.

Determining the Need for Reliability
Applications, such as databases, web pages, and e-mail, require that all of the sent data arrive at the destination in its original condition, in order for the data to be useful. Any missing data could cause a corrupt communication that is either incomplete or unreadable. Therefore, these applications are designed to use a Transport layer protocol that implements reliability.