Mercury Quality Centre: Introduction

Mercury Quality Centre is a web-based test management tool. It gives you a centralized control over the entire testing life cycle. It gives an easy interface to manage and organize activities like Requirements coverage, Test Case Management, Test Execution Reporting, Defect Management, and Test Automation. All these activities are provided from a single tool, which is web-based and can be accessed from any where. Hence, making the task of the testers and managers easy.

Mercury Quality Centre can be divided into two parts:
- Site Administrator Bin
- Quality Centre Bin

Site Administration Bin:
It is the starting point for the usage of Mercury Quality Centre. This part is used for all the administrative activities. Password for site admin is defined during the installation so make sure that you remember the password during installation. From this part of Mercury Quality Centre, we generally do the following activities:

- Creating the projects
- Assigning users to the projects
- Creating specific roles
- Configuring QTP or Winrunner scripts to use from Mercury Quality Centre
- Configuring the mail servers
- Verifying licensing information
- Information about database

Note: If you are using Winrunner, you need to make sure that backward compatibility property of the application to true.

Quality Center Bin:
This part of Mercury Quality Centre gives functionality of almost everything that as a tester or test manager you need to do in your day to day activity apart from execution. This is the most common interface used by the customers or users. In this part, we generally do the following activities:

- Creating test plans
- Defining requirements
- Creating test cases
- Creating test labs
- Associating requirements with defects in essence

Mercury Quality Centre is installed as a service in Microsoft windows environment. Before start working on it, make sure that Mercury Quality Centre service is running.

As soon as you access the application, the first screen is a login screen where you need to provide administrator credentials which were used during the installation of Mercury Quality Centre. Once you are logged on to the SABin, you can perform all the administrative tasks mentioned above.

Note: If Mercury Quality Centre is listening to default port, then you can access the application using the following URL:

http://%7Byourmachinename%7D:8080/sabin/SiteAdmin.htm

Define your projects in SABin. Mercury Quality Center provides the role based accessed to the Projects. For example, A Test Manager can create projects and Test Lead can prepare test plans and tester can write the test cases. This role based access makes it very easy to control access to various artifacts of the project and also distribution of responsibility among team members. Following four things can be managed in Mercury Quality Centre:
- Requirements
- Test Plan
- Test Lab
- Defects

Once you have created a project in SABin, Now log on to QCBin by providing your credentials and access the project that you have created. Here, you will notice different tabs for Requirements, TestPlan, TestLab and Defects.

Under Requirements Tab, you can organize the project requirements. You can also create folder hierarchy to represent various features in your project. This can be accomplished by just right-clicking and choosing appropriate options. After creating requirements, move on to next tab Test Plan.

Test Plan Tab will have information about the test cases. These test cases can also be mapped to requirements created in the earlier steps, thus makes foundation for the traceability metrics. Each requirement can be mapped to one or more than one test cases.

After creating new test case you will see in the left hand pane. The right hand pane will have tabs for writing the steps, mapping to requirements, description, expected result etc. Every test case will have steps and for every step you can specify the expected behavior.

The test cases written here, can also be linked to the QTP or Winrunner Scripts. This way, it is providing you better management for the automation and capability of executing automation scripts from Mercury Quality Centre itself. Once you are done with Test Plan preparation, move on to the next tab Test Lab.

To manage test execution for a specific release, you have to create a Test Lab. Test Labs can be created, specific to the release and execution of test cases specific to release can be managed very easily using this concept. In the Test Lab you can identify the set of test cases already written under test plan to include for execution.

If the test cases are already linked to the requirements, then after each test cycle the management will be able to trace what requirements have been tested.

When you choose the option of manual test execution, a window will open up containing the steps to execute. These steps are executed and after every step you can specify whether it is passed or not. Mercury Quality Center also allows parameterized manual test execution, where some of the default parameters like username, password etc. can automatically be read during the manual execution. If you encounter any defects during the failure of any of the steps, it will be automatically logged in to the defect tracking system of Mercury Quality Centre. Once you are done with Test Execution move on to next tab, Defects.

Report generation is one of the most important part of the test management process. Once you are done with planning and execution, its REPORTING time. Mercury Quality Centre provides a very good reporting feature by providing certain pre-defined reports and also capability to create your own reports.

Agile Testing

Agile testing is a software testing practice that follows the principles of the agile manifesto, emphasizing testing from the perspective of customers who will utilize the system. Agile testing does not emphasize rigidly defined testing procedures, but rather focuses on testing iteratively against newly developed code until quality is achieved from an end customer's perspective. In other words, the emphasis is shifted from "testers as quality police" to something more like "entire project team working toward demonstrable quality."

Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing.
Since working increments of the software are released often in agile software development, there is also a need to test often. This is commonly done by using automated acceptance testing to minimize the amount of manual labor involved. Doing only manual testing in agile development may result in either buggy software or slipping schedules because it may not be possible to test the entire build manually before each release.

Testing Agenda in Agile Projects:
Agile methodologies are designed to break the software down into manageable parts that can be delivered earlier to the customer. The aim of any Agile project is to deliver a basic working product as quickly as possible and then to go through a process of continual improvement. An Agile project is characterized by having a large number of short delivery cycles (sprints) and priority is given to the feedback-loops from one cycle to the next. The feedback- loops drive continuous improvement and allow the issues that inevitably occur (including the way requirements have been defined or the quality of the solution provided) to be dealt with much earlier in the development life cycle. To achieve this, companies need to re-think their approach to delivery and have their previously independent contributors (Business Analysts, Developers, Testers, End Users etc.) work together in teams.
The testing agenda during the development phase is very different to the traditional approaches that support the Waterfall or V-Model development methodologies because Agile uses a Test Driven Development (TDD) model. However, many of the requirements of the extended testing model will still apply.

Project Initiation Phase:
For an Agile project to succeed, it requires effective planning and management. As part of the project team the Test Manager is responsible for establishing the quality processes, identifying test resources and delivering the test strategy. The test strategy will include details of the Agile development process being used. It will also include details of test phases not directly related to the Agile development for example, Operational Acceptance or Performance Testing.

Development Phase:
True Agile development uses a “Test Driven Development” (TDD) approach. The testers, developers, business analysts and project stakeholders all contribute to kick-off meetings where the “user stories” are selected for the next sprint. Sprints are usually of fixed duration and selecting the right number of stories and estimating the time to deliver them is the key to success. The estimation process can often be inaccurate at the beginning of an Agile project but improves as the team’s experience grows within the specific implementation they are working on. Once the user stories are selected for the sprint they are used as the basis for a set of tests. The testers create test scenarios which are presented to the business analysts and project stakeholders for their approval and signoff. These test scenarios are then broken down to test cases that offer adequate test coverage for the given functionality.
The developers then write code that will pass the tests. In this approach the development and testing take place continuously throughout the sprint – there is no separate testing phase. In the TDD approach the features are tested throughout the sprint and the results presented to the stakeholders for immediate feedback. The test scenarios defined are not limited to functional testing but can include other types of testing including performance and integration testing when the product is mature enough.
While the development is underway the user stories for the next sprint are written. These include the stories specified in the delivery plan but will also include additional stories required to cover any issues that have been identified as part of the feedback process from previous sprints. Sprints in an Agile project can extend to multiple levels in a complex system. A sprint might not lead to a product release if it does not add enough functionality to the product being developed. The stakeholders take a decision on when the application should be moved to the release phase depending on the market need or the level of key functionality being added to the system. While multiple iterations may be required to release a product, there may also be cases where releases are more regular owing to the additional value delivered at each iteration level. Whichever release approach is adopted, the testing team’s goal is to have a release available with minimal defects and low implementation risk at the end of the Sprint.
As functionality grows with each iteration, regression testing must be performed to ensure that existing functionality has not been impacted by the introduction of new functionality in each iteration cycle. Defect fixes should also be followed by extensive regression testing. The scale of the regression testing grows with each sprint and to ensure that this remains a manageable task the test team should use test automation for the regression suite and focus their manual testing effort towards locating new defects during the build phase.

Release Phase:
The aim of any Agile project is to deliver a basic working product as quickly as possible and then to go through a process of continual improvement. This means that there is no single release phase for a product. The product will move into production when enough of the functionality is working and the quality of the product is acceptable to the stakeholders. Prior to release, a final acceptance test is performed before transitioning the application into production. The testing activities listed above are not exhaustive but broadly cover the areas which the testing team contributes to the Agile approach.

Getting Equipped for Agile Testing:
Agile projects present their own challenges to the testing team. Unclear project scope, multiple iterations, minimal documentation, early and frequent testing needs and active stakeholder involvement all demand special and diverse skills from the testing team. Some of the essential skills are illustrated here:

Resource Management
The Agile approach required a mixture of test skills – usually held across one team. Test resource will be required to define the scenarios and test cases, conduct manual testing alongside the developers, write automated regression tests and execute the automated regression packs. As the project progresses, specialist skills will be required to cover further test areas that might include integration and performance testing. The availability of a pool of professional test resources offers the scope for effective resource management across the agile project life cycle. There should be an appropriate mix of domain specialists who plan and gather requirements in addition to test engineers who will have multiple skill sets and own the test execution.

Communication
The benefits of independent testing will not be realized unless good communication exists between the testers, developers, business analysts and project stakeholders. The iterative model of development and the frequency of releases mandate that all teams have a common understanding of the user requirements. The testing teams should be skilled in the use of change management tools. The communication model used by the testing team itself must enable both regular and ad-hoc project updates from various parties engaged in the project. The testing team should adopt the most efficient and effective methods of conveying information to the developers, project stakeholders, domain specialists using a combination of face-to-face conversation, meetings and workshops, phone calls, email and WebEx meetings.

Processes
Another key success factor for Agile Development is the implementation of quality governance processes such as configuration management. Typically, an organization that has no processes in place will be in chaos. As formal processes are implemented the organization will be able to follow a repeatable and consistent delivery method. Organizations considering the use of Agile should ensure that configuration management, change management, project management and release management are in place. Testing teams which bring with them best practices and are accredited with globally recognized certifications (e.g. TMMi, CMMi, ISO etc.) will be able to help organizations accelerate testing and enable lower cost of quality to be achieved.

Conclusion:
Companies which adopt Agile projects should note the importance of engaging test teams at project initiation. This will ensure an accelerated delivery of working software. If Agile projects are to achieve customer satisfaction and ROI then time, cost and quality must be controlled and balanced. To ensure accelerated delivery of working software which conforms to the desired quality, the testing team should be involved from the beginning of every iterative development cycle and not just after the first couple of sprints. The testing team must develop the necessary mindset for an Agile project. Their own agility and flexibility is essentially the key to their success in the project.
 

Incident Management

Terms:
Incident logging, incident management.

Description:
Since one of the objectives of testing is to find defects, the discrepancies between actual and expected outcomes need to be logged as incidents. Incidents should be tracked from discovery and classification to correction and confirmation of the solution. In order to manage all incidents to completion, an organization should establish a process and rules for classification.

Incidents may be raised during development, review, testing or use of a software product. They may be raised for issues in code or the working system, or in any type of documentation including requirements, development documents, test documents, and user information such as “Help” or installation guides.

Incident reports have the following objectives:

o Provide developers and other parties with feedback about the problem to enable identification, isolation and correction as necessary.
o Provide test leaders a means of tracking the quality of the system under test and the progress of the testing.
o Provide ideas for test process improvement.

Details of the incident report may include:

o Date of issue, issuing organization, and author.
o Expected and actual results.
o Identification of the test item (configuration item) and environment.
o Software or system life cycle process in which the incident was observed.
o Description of the incident to enable reproduction and resolution, including logs, database
dumps or screenshots.
o Scope or degree of impact on stakeholder(s) interests.
o Severity of the impact on the system.
o Urgency/priority to fix.
o Status of the incident (e.g. open, deferred, duplicate, waiting to be fixed, fixed awaiting retest,
closed).
o Conclusions, recommendations and approvals.
o Global issues, such as other areas that may be affected by a change resulting from the
incident.
o Change history, such as the sequence of actions taken by project team members with respect
to the incident to isolate, repair, and confirm it as fixed.
o References, including the identity of the test case specification that revealed the problem.

Configuration Management

Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life. For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.

Software configuration management:
The traditional software configuration management (SCM) process is looked upon as the best solution to handling changes in software projects. It identifies the functional and physical attributes of software at various points in time, and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle.

The SCM process further defines the need to trace changes, and the ability to verify that the final delivered software has all of the planned enhancements that are supposed to be included in the release. It identifies four procedures that must be defined for each software project to ensure that a sound SCM process is implemented. They are:

1. Configuration identification
2. Configuration control
3. Configuration status accounting
4. Configuration audits

These terms and definitions change from standard to standard, but are essentially the same.

* Configuration identification is the process of identifying the attributes that define every aspect of a configuration item. A configuration item is a product (hardware and/or software) that has an end-user purpose. These attributes are recorded in configuration documentation and baselined. Baselining an attribute forces formal configuration change control processes to be effected in the event that these attributes are changed.

* Configuration change control is a set of processes and approval stages required to change a configuration item's attributes and to re-baseline them.

* Configuration status accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time.

* Configuration audits are broken into functional and physical configuration audits. They occur either at delivery or at the moment of effecting the change. A functional configuration audit ensures that functional and performance attributes of a configuration item are achieved, while a physical configuration audit ensures that a configuration item is installed in accordance with the requirements of its detailed design documentation.

Configuration management is widely used by many military organizations to manage the technical aspects of any complex systems, such as weapon systems, vehicles, and information systems. The discipline combines the capability aspects that these systems provide an organization with the issues of management of change to these systems over time.

Outside of the military, CM is equally appropriate to a wide range of fields and industry and commercial sectors.

In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.

SCM concerns itself with answering the question "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analysing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products. Now, implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed.

Purposes
The goals of SCM are generally:

* Configuration identification - Identifying configurations, configuration items and baselines.
* Configuration control - Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline.
* Configuration status accounting - Recording and reporting all the necessary information on the status of the development process.
* Configuration auditing - Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals.
* Build management - Managing the process and tools used for builds.
* Process management - Ensuring adherence to the organization's development process.
* Environment management - Managing the software and hardware that host our system.
* Teamwork - Facilitate team interactions related to the process.
* Defect tracking - Making sure every defect has traceability back to the source.

Computer hardware configuration management:
omputer hardware configuration management is the process of creating and maintaining an up-to-date record of all the components of the infrastructure, including related documentation. Its purpose is to show what makes up the infrastructure and illustrate the physical locations and links between each item, which are known as configuration items.

Computer hardware configuration goes beyond the recording of computer hardware for the purpose of asset management, although it can be used to maintain asset information. The extra value provided is the rich source of support information that it provides to all interested parties. This information is typically stored together in a configuration management database (CMDB).

The scope of configuration management is assumed to include, at a minimum, all configuration items used in the provision of live, operational services.

Computer hardware configuration management provides direct control over information technology (IT) assets and improves the ability of the service provider to deliver quality IT services in an economical and effective manner. Configuration management should work closely with change management.

All components of the IT infrastructure should be registered in the CMDB. The responsibilities of configuration management with regard to the CMDB are:
# dentification
# control
# status accounting
# verification

The scope of configuration management is assumed to include:

* physical client and server hardware products and versions
* operating system software products and versions
* application development software products and versions
* technical architecture product sets and versions as they are defined and introduced
* live documentation
* networking products and versions
* live application products and versions
* definitions of packages of software releases
* definitions of hardware base configurations
* configuration item standards and definitions

The benefits of computer hardware configuration management are:

* helps to minimize the impact of changes
* provides accurate information on CIs
* improves security by controlling the versions of CIs in use
* facilitates adherence to legal obligations
* helps in financial and expenditure planning

Maintenance systems:
Configuration management is used to maintain an understanding of the status of complex assets with a view to maintaining the highest level of serviceability for the lowest cost. Specifically, it aims to ensure that operations are not disrupted due to the asset (or parts of the asset) overrunning limits of planned lifespan or below quality levels.

In the military, this type of activity is often classed as "mission readiness", and seeks to define which assets are available and for which type of mission; a classic example is whether aircraft onboard an aircraft carrier are equipped with bombs for ground support or missiles for defense.

Preventive maintenance
Understanding the "as is" state of an asset and its major components is an essential element in preventative maintenance as used in maintenance, repair, and overhaul and enterprise asset management systems.

Complex assets such as aircraft, ships, industrial machinery etc. depend on many different components being serviceable. This serviceability is often defined in terms of the amount of usage the component has had since it was new, since fitted, since repaired, the amount of use it has had over its life and several other limiting factors. Understanding how near the end of their life each of these components is has been a major undertaking involving labor intensive record keeping until recent developments in software.

Predictive maintenance
Many types of component use electronic sensors to capture data which provides live condition monitoring. This data is analyzed on board or at a remote location by computer to evaluate its current serviceability and increasingly its likely future state using algorithms which predict potential future failures based on previous examples of failure through field experience and modeling. This is the basis for "predictive maintenance".

Availability of accurate and timely data is essential in order for CM to provide operational value and a lack of this can often be a limiting factor. Capturing and disseminating the operating data to the various support organizations is becoming an industry in itself.

The consumers of this data have grown more numerous and complex with the growth of programs offered by original equipment manufacturers (OEMs). These are designed to offer operators guaranteed availability and make the picture more complex with the operator managing the asset but the OEM taking on the liability to ensure its serviceability. In such a situation, individual components within an asset may communicate directly to an analysis center provided by the OEM or an independent analyst.

Standards:
* ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
* EIA-649-A 2004 National Consensus Standard for Configuration Management
* ISO 10007:2003 Quality management systems - Guidelines for configuration management
* Federal Standard 1037C
* GEIA Standard 836-2002 Configuration Management Data Exchange and Interoperability
* IEEE Std. 828-1998 IEEE Standard for Software Configuration Management Plans
* MIL-STD-973 Configuration Management (cancelled on September 20, 2000)
* STANAG 4159 NATO Material Configuration Management Policy and Procedures for Multinational Joint Projects
* STANAG 4427 Introduction of Allied Configuration Management Publications (ACMPs)
* CMMI CMMI® for Development, Version 1.2 CONFIGURATION MANAGEMENT

Guidelines:
* IEEE Std. 1042-1987 IEEE Guide to Software Configuration Management
* MIL-HDBK-61A CONFIGURATION MANAGEMENT GUIDANCE 7 February 2001
* ISO 10007 Quality management - Guidelines for configuration management
* GEIA-HB-649 - Implementation Guide for Configuration Management
* ANSI/EIA-649-1998 National Consensus Standard for Configuration Management
* EIA-836 Consensus Standard for Configuration Management Data Exchange and Interoperability
* ANSI/EIA-632-1998 Processes for Engineering a System

Test Strategy (OR Test Approaches)

A test strategy is an outline that describes the testing portion of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.

In the test strategy is described how the product risks of the stakeholders are mitigated in the test levels, which test types are performed in the test levels, and which entry and exit criteria apply.

The test strategy is created based on development design documents. The system design document is the main one used and occasionally, the conceptual design document can be referred to. The design documents describe the functionalities of the software to be enabled in the upcoming release. For every set of development design, a corresponding test strategy should be created to test the new feature sets.

One way to classify test approaches or strategies is based on the point in time at which the bulk of the test design work is begun:
o Preventative approaches, where tests are designed as early as possible.
o Reactive approaches, where test design comes after the software or system has been
produced.

Typical approaches or strategies include:

* Analytical approaches, such as risk-based testing where testing is directed to areas of greatest
risk.
* Model-based approaches, such as stochastic testing using statistical information about failure
rates (such as reliability growth models) or usage (such as operational profiles).
* Methodical approaches, such as failure-based (including error guessing and fault-attacks),
experienced-based, check-list based, and quality characteristic based.
* Process- or standard-compliant approaches, such as those specified by industry-specific
standards or the various agile methodologies.
* Dynamic and heuristic approaches, such as exploratory testing where testing is more reactive
to events than pre-planned, and where execution and evaluation are concurrent tasks.
* Consultative approaches, such as those where test coverage is driven primarily by the advice
and guidance of technology and/or business domain experts outside the test team.
* Regression-averse approaches, such as those that include reuse of existing test material, extensive automation of functional regression tests, and standard test suites.

Different approaches may be combined, for example, a risk-based dynamic approach.

The selection of a test approach should consider the context, including:

* Risk of failure of the project, hazards to the product and risks of product failure to humans, the
environment and the company.
* Skills and experience of the people in the proposed techniques, tools and methods.
* The objective of the testing endeavour and the mission of the testing team.
* Regulatory aspects, such as external and internal regulations for the development process.
* The nature of the product and the business.

Test Levels

The test strategy describes the test level to be performed. There are primarily three levels of testing: unit testing, integration testing, and system testing. In most software development organizations, the developers are responsible for unit testing. Individual testers or test teams are responsible for integration and system testing.

Roles and Responsibilities

The roles and responsibilities of test leader, individual testers, project manager are to be clearly defined at a project level in this section. This may not have names associated: but the role has to be very clearly defined.

Testing strategies should be reviewed by the developers. They should also be reviewed by test leads for all levels of testing to make sure the coverage is complete yet not overlapping. Both the testing manager and the development managers should approve the test strategy before testing can begin.

Environment Requirements

Environment requirements are an important part of the test strategy. It describes what operating systems are used for testing. It also informs clearly the necessary OS patch levels and security updates required. For example, a certain test plan may require service pack 2 installed on the Windows XP OS as a prerequisite for testing.

Testing Tools

There are two methods used in executing test cases: manual and automation. Depending on the nature of the testing, it is usually the case that a combination of manual and automated testing is the most optimal testing method. Planner should find the appropriate automation tool to reduce total testing time.

Risks and Mitigation

Any risks that will affect the testing process must be listed along with the mitigation. By documenting the risks in this document, we can anticipate the occurrence of it well ahead of time and then we can proactively prevent it from occurring. Sample risks are dependency of completion of coding, which is done by sub-contractors, capability of testing tools etc.

Test Schedule

A test plan should make an estimation of how long it will take to complete the testing phase. There are many requirements to complete testing phases. First, testers have to execute all test cases at least once. Furthermore, if a defect was found, the developers will need to fix the problem. The testers should then re-test the failed test case until it is functioning correctly. Last but not the least, the tester need to conduct regression testing towards the end of the cycle to make sure the developers did not accidentally break parts of the software while fixing another part. This can occur on test cases that were previously functioning properly.

The test schedule should also document the number of tester available for testing. If possible, assign test cases to each tester.

It is often difficult to make an accurate approximation of the test schedule since the testing phase involves many uncertainties. Planners should take into account the extra time needed to accommodate contingent issues. One way to make this approximation is to look at the time needed by the previous releases of the software. If the software is new, multiplying the initial testing schedule approximation by two is a good way to start.

Regression Test Approach

When a particular problem is identified, the programs will be debugged and the fix will be done to the program. To make sure that the fix works, the program will be tested again for that criteria. Regression test will make sure that one fix does not create some other problems in that program or in any other interface. So, a set of related test cases may have to be repeated again, to make sure that nothing else is affected by a particular fix. How this is going to be carried out must be elaborated in this section. In some companies, whenever there is a fix in one unit, all unit test cases for that unit will be repeated, to achieve a higher level of quality.

Test Groups

From the list of requirements, we can identify related areas, whose functionality is similar. These areas are the test groups. For example, in a railway reservation system, anything related to ticket booking is a functional group; anything related with report generation is a functional group. Same way, we have to identify the test groups based on the functionality aspect.

Test Priorities

Among test cases, we need to establish priorities. While testing software projects, certain test cases will be treated as the most important ones and if they fail, the product cannot be released. Some other test cases may be treated like cosmetic and if they fail, we can release the product without much compromise on the functionality. This priority levels must be clearly stated. These may be mapped to the test groups also.

Test Status Collections and Reporting

When test cases are executed, the test leader and the project manager must know, where exactly we stand in terms of testing activities. To know where we stand, the inputs from the individual testers must come to the test leader. This will include, what test cases are executed, how long it took, how many test cases passed and how many failed etc. Also, how often we collect the status is to be clearly mentioned. Some companies will have a practice of collecting the status on a daily basis or weekly basis. This has to be mentioned clearly.

Test Records Maintenance

When the test cases are executed, we need to keep track of the execution details like when it is executed, who did it, how long it took, what is the result etc. This data must be available to the test leader and the project manager, along with all the team members, in a central location. This may be stored in a specific directory in a central server and the document must say clearly about the locations and the directories. The naming convention for the documents and files must also be mentioned.

Requirements Traceability Matrix

Ideally each software developed must satisfy the set of requirements completely. So, right from design, each requirement must be addressed in every single document in the software process. The documents include the HLD, LLD, source codes, unit test cases, integration test cases and the system test cases. Refer the following sample table which describes Requirements Traceability Matrix process. In this matrix, the rows will have the requirements. For every document {HLD, LLD etc}, there will be a separate column. So, in every cell, we need to state, what section in HLD addresses a particular requirement. Ideally, if every requirement is addressed in every single document, all the individual cells must have valid section ids or names filled in. Then we know that every requirement is addressed. In case of any missing of requirement, we need to go back to the document and correct it, so that it addressed the requirement.

Test Summary

The senior management may like to have test summary on a weekly or monthly basis. If the project is very critical, they may need it on a daily basis also. This section must address what kind of test summary reports will be produced for the senior management along with the frequency.
The test strategy must give a clear vision of what the testing team will do for the whole project for the entire duration. This document will/may be presented to the client also, if needed. The person, who prepares this document, must be functionally strong in the product domain, with a very good experience, as this is the document that is going to drive the entire team for the testing activities. Test strategy must be clearly explained to the testing team members right at the beginning of the project.

Volume Testing

Definition:
Volume Testing belongs to the group of non-functional tests, which are often misunderstood and/or used interchangeably. Volume testing refers to testing a software application with a certain amount of data. This amount can, in generic terms, be the database size or it could also be the size of an interface file that is the subject of volume testing. For example, if you want to volume test your application with a specific database size, you will expand your database to that size and then test the application's performance on it. Another example could be when there is a requirement for your application to interact with an interface file (could be any file such as .dat, .xml); this interaction could be reading and/or writing on to/from the file. You will create a sample file of the size you want and then test the application's functionality with that file in order to test the performance.

Objective:
o Find problems with max. amounts of data.
o System performance or usability often degrades when large amounts of
data must be searched, ordered etc.

Test Procedure:
• The system is run with maximum amounts of data.
• Internal tables, databases, files, disks etc. are loaded with a maximum of
data.
• Maximal length of external input.
• Important functions where data volume may lead to trouble.

Result wanted:
• No problems, no significant performance degradation, and no lost data.

Considerations:
• Data generation may need analysis of a usage profile and may not be
trivial. (Same as in stress testing.)
• Copy of production data or random generation.
• Use data generation or extraction tools.
• Data variation is important!
• Memory fragmentation important!

Volume test shall check if there are any problems when running the system under test
with realistic amounts of data, or even maximum or more. Volume test is necessary, as ordinary function testing normally does not use large amounts of data, rather the
opposite.

A special task is to check out real maximum amounts of data, which are possible in
extreme situations, for example on days with extremely large amounts of processing to be done (new year, campaigns, tax deadlines, disasters, etc.) Typical problems are full or nearly full disks, databases, files, buffers, counters that may lead to overflow. Maximal data amounts in communications may also be a concern.

Part of the test is to run the system over a certain time with a lot of data. This is in order to check what happens to temporary buffers and to timeouts due to long times for access.

One variant of this test is using especially low volumes, such as empty databases or files, empty mails, no links etc. Some programs cannot handle this either.

One last variant is measuring how much space is needed by a program. This is important if a program is sharing resources with other ones. All programs taken together must not use more resources than available.

Examples:

Online system: Input fast, but not necessarily fastest possible, from different input channels. This is done for some time in order to check if temporary buffers tend to overflow or fill up, if execution time goes down. Use a blend of create, update, read and delete operations.

Database system: The database should be very large. Every object occurs with maximum number of instances. Batch jobs are run with large numbers of transactions, for example where something must be done for ALL objects in the database. Complex searches with sorting through many tables. Many or all objects linked to other objects, and to the maximum number of such objects. Large or largest possible numbers on sum fields.

File exchange: Especially long files. Maximal lengths. Lengths longer than typical maximum values in communication protocols (1, 2, 4, 8, … Mega- og Gigabytes). For example lengths that are not supported by mail protocols. Also especially MANY files,even in combination with large lengths. (1024, 2048 etc. files). Email with maximum number of attached files. Lengths of files that let input buffers overflow or trigger timeouts. Large lengths in general in order to tripper timeouts in communications.

Disk space: Try to fill disk space everywhere there a re disks. Check what happens if there is no more space left and even more data is fed into the system. Is there any kind of reserve like “overflow-buffers”? Are there any alarm signals, graceful degradation? Will there be reasonable warnings? Data loss? This can be tested by “tricks”, by making less
space available and testing with smaller volumes.

File system: Maximal numbers of files for the file system and/or maximum lengths.

Internal memory: Minimum amount of memory available (installed). Open many
programs at the same time, at least on the client platform.

General points to check:


• Check error messages and warnings, if they come at all for volume problems and
if they are helpful and understandable.
• Is data lost?
• Does the system slow down too much?
• Do timeouts happen? IN that case failures may also happen.
• If it looks like it goes fine, are really ALL data processed or stored? Even the end
of files, objects or tables?
• Are data stored wrong?
• Are data lost or written over without warning?

How to find test conditions:

Test conditions are data that could turn into a problem:

Find which input data and output data occur in an application or function.
Find restrictions for number of data, especially maximum and minimum. Include
especially data, which are stored temporarily or are read from temporary store.

For every data element, check if there can occur larger volumes than allowed. Check
what happens if data elements are counted. Can the maxima come out of bounds? What
about sums, if many objects are summed up? Can that cause out of bounds values?

If a data element is stored temporarily, how much space is necessary? If there are many such elements, can the space be too little?

If there is any form of numbering or coding, are there restrictions in it that can preclude growth? For example if there are two character fields, there may not be more codes than 26*26 possibilities.

Find boundaries on system wide data, for example maximum disk volume, maximum
number of files for the file system, maximal file lengths, buffer lengths etc. and look if any of them can turn into a problem.

Find restrictions in temporary storage media like maximal length of mail, CD, DVD, tape etc.

Find restrictions in communications, for example timeouts and maximal lengths of
messages, files etc. Check how much data can be transferred before a timeout will come.

Find places where data is stored temporarily. Find the functions storing data there and functions reading and taking away these data. Make test scenarios (soap operas) going thorough both storing and deleting. Try to find out if the place can get full, and overflow problems. This requires long scenarios, maybe even random generated function calls. Check if an audit trail may lead to problems after logging many transactions.

Can volume test be left out?
The preconditions for taking away volume test is that volume questions are checked in earlier test and answered sufficiently well. This means volume is tested or checked in lower level tests or reviews and the results can be checked.

Caution when integrating several independent systems to be executed on the same
platform: It must be guaranteed that every system has enough resources for itself. If one cannot guarantee that the platform delivers the necessary resources, in this case all kinds of memory, then a volume test of all systems together should be executed with maximal data volumes for every system.

Checklist:
If at least one question is answered with NO, volume test is interesting.

• Is volume test executed before, on the whole system and can the result be
checked?
• Can we guarantee that the system always has he necessary memory resources?
• Can we guarantee this if several systems share the hardware?
• Is it guaranteed that no larger data volumes than specified will occur?
• Is there a low risk if data volume turn greater than specified anyway but the
system does not work well enough then?

Problems when generating data:

• Fragmentation of memory difficult to generate
• Relational integrity of generated data
• Dynamic generation of keys
• Data should follow the usage profile

Smoke And Sanity Testing

Smoke testing
In computer programming and software testing, smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release. In this case, the smoke is metaphorical.

Smoke testing is done by developers before the build is released to the testers, or by testers before accepting a build for further testing. Microsoft claims[1] that after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software.

n software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection or the main branch of source code.

In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing. This is also known as a build verification test. This is a "shallow and wide" approach to the application. The tester "touches" all areas of the application without getting too deep, looking for answers to basic questions like, "Can I launch the test item at all?", "Does it open to a window?", "Do the buttons on the window do things?".

The purpose is to determine whether or not the application is so badly broken that testing functionality in a more detailed way is unnecessary. These written tests can either be performed manually or using an automated tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself.

This is sometimes referred to as "rattle" testing - as in "if I shake it does it rattle?". Steve McConnell gives some good advice for smoke testing software.
http://www.stevemcconnell.com/ieeesoftware/bp04.htm

Sanity testing

In computer science, a sanity test is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that the system or methodology works as expected, often prior to a more exhaustive round of testing.

In software development, the sanity test (a form of software testing which offers "quick, broad, and shallow testing"[1]) determines whether it is reasonable to proceed with further testing.
Software sanity tests are commonly conflated with smoke tests.A smoke test determines whether it is possible to continue testing, as opposed to whether it is reasonable.
A software smoke test determines whether the program launches and whether its interfaces are accessible and responsive (for example, the responsiveness of a web page or an input button). If the smoke test fails, it is impossible to conduct a sanity test. In contrast, the ideal sanity test exercises the smallest subset of application functions needed to determine whether the application logic is generally functional and correct (for example, an interest rate calculation for a financial application). If the sanity test fails, it is not reasonable to attempt more rigorous testing. Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing. Many companies run sanity tests and unit tests on an automated build as part of their development process.

The Hello world program is often used as a sanity test for a development environment. If Hello World fails to compile or execute, the supporting environment likely has a configuration problem. If it works, the problem being diagnosed likely lies in the real application being diagnosed.

Black Box (Vs) White Box

An easy way to start up a debate in a software testing forum is to ask the difference between black box and white box testing. These terms are commonly used, yet everyone seems to have a different idea of what they mean.

Black box testing begins with a metaphor. Imagine you’re testing an electronics system. It’s housed in a black box with lights, switches, and dials on the outside. You must test it without opening it up, and you can’t see beyond its surface. You have to see if it works just by flipping switches (inputs) and seeing what happens to the lights and dials (outputs). This is black box testing. Black box software testing is doing the same thing, but with software. The actual meaning of the metaphor, however, depends on how you define the boundary of the box and what kind of access the “blackness” is blocking.

An opposite test approach would be to open up the electronics system, see how the circuits are wired, apply probes internally and maybe even disassemble parts of it. By analogy, this is called white box testing,

To help understand the different ways that software testing can be divided between black box and white box techniques, consider the Five-Fold Testing System. It lays out five dimensions that can be used for examining testing:

1. People(who does the testing)
2. Coverage (what gets tested)
3. Risks (why you are testing)
4. Activities(how you are testing)
5. Evaluation (how you know you’ve found a bug)

Let’s use this system to understand and clarify the characteristics of black box and white box testing.

People: Who does the testing?
Some people know how software works (developers) and others just use it (users). Accordingly, any testing by users or other non-developers is sometimes called “black box” testing. Developer testing is called “white box” testing. The distinction here is based on what the person knows or can understand.

Coverage: What is tested?
If we draw the box around the system as a whole, “black box” testing becomes another name for system testing. And testing the units inside the box becomes white box testing. This is one way to think about coverage. Another is to contrast testing that aims to cover all the requirements with testing that aims to cover all the code. These are the two most commonly used coverage criteria. Both are supported by extensive literature and commercial tools. Requirements-based testing could be called “black box” because it makes sure that all the customer requirements have been verified. Code-based testing is often called “white box” because it makes sure that all the code (the statements, paths, or decisions) is exercised.


Risks: Why are you testing?
Sometimes testing is targeted at particular risks. Boundary testing and other attack-based techniques are targeted at common coding errors. Effective security testing also requires a detailed understanding of the code and the system architecture. Thus, these techniques might be classified as “white box”. Another set of risks concerns whether the software will actually provide value to users. Usability testing focuses on this risk, and could be termed “black box.”

Activities: How do you test?
A common distinction is made between behavioral test design, which defines tests based on functional requirements, and structural test design, which defines tests based on the code itself. These are two design approaches. Since behavioral testing is based on external functional definition, it is often called “black box,” while structural testing—based on the code internals—is called “white box.” Indeed, this is probably the most commonly cited definition for black box and white box testing. Another activity-based distinction contrasts dynamic test execution with formal code inspection. In this case, the metaphor maps test execution (dynamic testing) with black box testing, and maps code inspection (static testing) with white box testing. We could also focus on the tools used. Some tool vendors refer to code-coverage tools as white box tools, and tools that facilitate applying inputs and capturing inputs—most notably GUI capture replay tools—as black box tools. Testing is then categorized based on the types of tools used.

Evaluation: How do you know if you’ve found a bug?
There are certain kinds of software faults that don’t always lead to obvious failures. They may be masked by fault tolerance or simply luck. Memory leaks and wild pointers are examples. Certain test techniques seek to make these kinds of problems more visible. Related techniques capture code history and stack information when faults occur, helping with diagnosis. Assertions are another technique for helping to make problems more visible. All of these techniques could be considered white box test techniques, since they use code instrumentation to make the internal workings of the software more visible. These contrast with black box techniques that simply look at the official outputs of a program.

White box testing is concerned only with testing the software product; it cannot guarantee that the complete specification has been implemented. Black box testing is concerned only with testing the specification; it cannot guarantee that all parts of the implementation have been tested. Thus black box testing is testing against the specification and will discover faults of omission, indicating that part of the specification has not been fulfilled. White box testing is testing against the implementation and will discover faults of commission, indicating that part of the implementation is faulty. In order to fully test a software product both black and white box testing are required.
White box testing is much more expensive than black box testing. It requires the source code to be produced before the tests can be planned and is much more laborious in the determination of suitable input data and the determination if the software is or is not correct. The advice given is to start test planning with a black box test approach as soon as the specification is available. White box planning should commence as soon as all black box tests have been successfully passed, with the production of flowgraphs and determination of paths. The paths should then be checked against the black box test plan and any additional required test runs determined and applied.

The consequences of test failure at this stage may be very expensive. A failure of a white box test may result in a change which requires all black boxes testing to be repeated and the re-determination of the white box paths

To conclude, apart from the above described analytical methods of both glass and black box testing, there are further constructive means to guarantee high quality software end products. Among the most important constructive means are the usage of object-oriented programming tools, the integration of CASE tools, rapid prototyping, and last but not least the involvement of users in both software development and testing procedures

Summary :
Black box testing can sometimes describe user-based testing (people); system or requirements-based testing (coverage); usability testing (risk); or behavioral testing or capture replay automation (activities). White box testing, on the other hand, can sometimes describe developer-based testing (people); unit or code-coverage testing (coverage); boundary or security testing (risks); structural testing, inspection or code-coverage automation (activities); or testing based on probes, assertions, and logs (evaluation).

Link rot

Link rot (or linkrot) is the process by which links on a website gradually become irrelevant or broken as time goes on, because websites that they link to disappear, change their content, or move to new locations.

The phrase also describes the effects of failing to update web pages so that they become out-of-date, containing information that is old and useless, and that clutters up search engine results.

Prevalence:
The 404 "not found" response is familiar to even the occasional Web user. A number of studies have examined the prevalence of link rot on the Web, in academic literature, and in digital libraries. In a 2003 experiment, Fetterly et al. (2003) discovered that about one link out of every 200 disappeared each week from the internet. McCown et al. (2005) discovered that half of the URLs cited in D-Lib Magazine articles were no longer accessible 10 years after publication, and other studies have shown link rot in academic literature to be even worse (Spinellis, 2003, Lawrence et al., 2001). Nelson and Allen (2002) examined link rot in digital libraries and found that about 3% of the objects were no longer accessible after one year.

Some news sites contribute to the link rot problem by keeping only recent news articles online where they are freely accessible at their original URLs, then removing them or moving them to a paid subscription area. This causes a heavy loss of supporting links in sites discussing newsworthy events and using news sites as references.

Discovering:
Detecting link rot for a given URL is difficult using automated methods. If a URL is accessed and returns back an HTTP 200 (OK) response, it may be considered accessible, but the contents of the page may have changed and may no longer be relevant. Some web servers also return a soft 404, a page returned with a 200 (OK) response (instead of a 404) that indicates the URL is no longer accessible. Bar-Yossef et al. (2004) developed a heuristic for automatically discovering soft 404s.

Combating:
There are several tools that have been developed to help combat link rot.

* WordPress guards against link rot by replacing non-canonical URLs with their canonical versions.[1]
* When a user receives a 404 response, the Google Toolbar for Internet Explorer attempts to assist the user in finding the missing page.[2]
* IBM's Peridot attempts to automatically fix broken links.


Web archiving
To combat link rot, web archivists are actively engaged in collecting the Web or particular portions of the Web and ensuring the collection is preserved in an archive, such as an archive site, for future researchers, historians, and the public. The largest web archiving organization is the Internet Archive Wayback Machine, which strives to maintain an archive of the entire Web, taking periodic snapshots of pages that can then be accessed for free and without registration many years later simply by typing in the URL. National libraries, national archives and various consortia of organizations are also involved in archiving culturally important Web content.

Individuals may also use a number of tools that allow them to archive web resources that may go missing in the future:

* WebCite, a tool specifically for scholarly authors, journal editors and publishers to permanently archive "on-demand" and retrieve cited Internet references (Eysenbach and Trudel, 2005).
* Archive-It, a subscription service that allows institutions to build, manage and search their own web archive
* Some social bookmarking websites, such as Furl, make private copies of web pages bookmarked by their users.

Webmasters
Webmasters have developed a number of best practices for combating link rot:

* Avoiding unmanaged hyperlink collections
* Avoiding links to pages deep in a website ("deep linking")
* Using hyperlink checking software or a Content Management System (CMS) that automatically checks links
* Using permalinks
* Using redirection mechanisms (e.g. "301: Moved Permanently") to automatically refer browsers and crawlers to the new location of a URL

Authors citing URLs
A number of studies have shown how widespread link rot is in academic literature (see below). Authors of scholarly publications have also developed best-practices for combating link rot in their work:

* Avoiding URL citations that point to resources on a researcher's personal home page (McCown et al., 2005)
* Using Persistent Uniform Resource Locators (PURLs) and digital object identifiers (DOIs) whenever possible
* Using web archiving services (e.g. WebCite) to permanently archive and retrieve cited Internet references (Eysenbach and Trudel, 2005).

Broken Link OR Dead link (404 Error)

A dead link (also called a broken link or dangling link) is a link on the World Wide Web that points to a web page or server that is permanently unavailable. The most common result of a dead link is a 404 error, which indicates that the web server responded, but the specific page could not be found. The browser may also return a DNS error indicating that a web server could not be found at that domain name. A link might also be dead because of some form of blocking such as content filters or firewalls.

Another type of dead link is a URL that points to a site unrelated to the content sought. This can sometimes occur when a domain name is allowed to lapse, and is subsequently reregistered by another party. Domain names acquired in this manner are attractive to those who wish to take advantage of the stream of unsuspecting surfers that will inflate hit counters and PageRanking.

Link rot is the process by which links on a website gradually become irrelevant or broken over time as sites they link to disappear, change content, or redirect to new locations.

Links specially crafted to not resolve, as a type of meme, are known as Zangelding, which roughly translated from German means tangle thing. A zangelding is basically a list of self referencing broken links.

Dead links commonplace on the Internet can also occur on the authoring side, when website content is assembled, copied, or deployed without properly verifying the targets, or simply not kept up to date. Because broken links are to some very annoying, generally disruptive to the user experience, and can live on for many years, sites containing them are regarded as unprofessional.

Solutions to broken links:

Due to the unprofessional image that dead links bring to both sites linking and linked to, there are multiple solutions that are available to tackle them - some working to prevent them in the first place, and others trying to resolve then when they have occurred.

* The most obvious form of link management, is employing link checking software that test each link on a website for its validity. An example of, and one of the most widely used link checkers is Xenu's Link Sleuth.
* Content Managment Systems often offer inbuilt solutions to the management of links, eg. links are updated when content is changed or moved on the site.
* Permalinking stops broken links by guaranteeing that the content will never move. Another form of permalinking is linking to a permalink that then redirects to the actual content, ensuring that even though the real content may be moved etc..., links pointing to the resources stay intact.
* The Wayback Machine, operated by the Internet Archive, keeps historical snapshots of websites. If a dead link is found, a search for the webpage on the Wayback Machine may yield a past version, which may be used to replace the dead link with an archived version.

When a broken link remains however, as is very common on the internet (especially between websites due to the difficulty of updating other websites linking to one's own), the visitor that clicks the dead link will get an HTTP 404 error, indicating the resource could not be found. The following tools try to rectify this error:

* The Linkgraph widget get the URL of the correct page based upon the old broken URL by using historical location information.
* The Google 404 Widget employs Google technology to 'guess' the correct URL, and also provides the user a Google search box to find the correct page.
* DeadURL.com gathers and ranks alternate urls for a broken link using Google Cache, the Internet Archive, and user submissions. Typing deadurl.com/ left of a broken link in the browser's address bar and pressing enter loads a ranked list of alternate urls, or (depending on user preference) immediately forwards to the best one.

Client-server

Client-server computing or networking is a distributed application architecture that partitions tasks or work loads between service providers (servers) and service requesters, called clients. Often clients and servers operate over a computer network on separate hardware. A server machine is a high-performance host that is running one or more server programs which share its resources with clients. A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await (listen to) incoming requests.

Description :
Client-server describes the relationship between two computer programs in which one program, the client program, makes a service request to another, the server program. Standard networked functions such as email exchange, web access and database access, are based on the client-server model. For example, a web browser is a client program at the user computer that may access information at any web server in the world. To check your bank account from your computer, a web browser client program in your computer forwards your request to a web server program at the bank. That program may in turn forward the request to its own database client program that sends a request to a database server at another bank computer to retrieve your account balance. The balance is returned to the bank database client, which in turn serves it back to the web browser client in your personal computer, which displays the information for you.

The client-server model has become one of the central ideas of network computing. Many business applications being written today use the client-server model. So do the Internet's main application protocols, such as HTTP, SMTP, Telnet, DNS. In marketing, the term has been used to distinguish distributed computing by smaller dispersed computers from the "monolithic" centralized computing of mainframe computers. But this distinction has largely disappeared as mainframes and their applications have also turned to the client-server model and become part of network computing.

Each instance of the client software can send data requests to one or more connected servers. In turn, the servers can accept these requests, process them, and return the requested information to the client. Although this concept can be applied for a variety of reasons to many different kinds of applications, the architecture remains fundamentally the same.

The most basic type of client-server architecture employs only two types of hosts: clients and servers. This type of architecture is sometimes referred to as two-tier. It allows devices to share files and resources. The two tier architecture means that the client acts as one tier and application in combination with server acts as another tier.

The interaction between client and server is often described using sequence diagrams. Sequence diagrams are standardized in the Unified Modeling Language.

Specific types of clients include web browsers, email clients, and online chat clients.

Specific types of servers include web servers, ftp servers, application servers, database servers, name servers, mail servers, file servers, print servers, and terminal servers. Most web services are also types of servers.

Comparison to peer-to-peer architecture :
In peer-to-peer[disambiguation needed] architectures, each host or instance of the program can simultaneously act as both a client and a server, and each has equivalent responsibilities and status.

Both client-server and peer-to-peer architectures are in wide usage today. Details may be found in Comparison of Centralized (Client-Server) and Decentralized (Peer-to-Peer) Networking.

Comparison to client-queue-client architecture :
While classic client-server architecture requires one of the communication endpoints to act as a server, which is much harder to implement,[citation needed] Client-Queue-Client allows all endpoints to be simple clients, while the server consists of some external software, which also acts as passive queue (one software instance passes its query to another instance to queue, e.g. database, and then this other instance pulls it from database, makes a response, passes it to database etc.). This architecture allows greatly simplified software implementation. Peer-to-peer architecture was originally based on the Client-Queue-Client concept.

Advantages :
* In most cases, a client-server architecture enables the roles and responsibilities of a computing system to be distributed among several independent computers that are known to each other only through a network. This creates an additional advantage to this architecture: greater ease of maintenance. For example, it is possible to replace, repair, upgrade, or even relocate a server while its clients remain both unaware and unaffected by that change.
* All the data is stored on the servers, which generally have far greater security controls than most clients. Servers can better control access and resources, to guarantee that only those clients with the appropriate permissions may access and change data.
* Since data storage is centralized, updates to that data are far easier to administer than what would be possible under a P2P paradigm. Under a P2P architecture, data updates may need to be distributed and applied to each peer in the network, which is both time-consuming and error-prone, as there can be thousands or even millions of peers.
* Many mature client-server technologies are already available which were designed to ensure security, friendliness of the user interface, and ease of use.
* It functions with multiple different clients of different capabilities.

Disadvantages :
* Traffic congestion on the network has been an issue since the inception of the client-server paradigm. As the number of simultaneous client requests to a given server increases, the server can become overloaded. Contrast that to a P2P network, where its aggregated bandwidth actually increases as nodes are added, since the P2P network's overall bandwidth can be roughly computed as the sum of the bandwidths of every node in that network.
* The client-server paradigm lacks the robustness of a good P2P network. Under client-server, should a critical server fail, clients’ requests cannot be fulfilled. In P2P networks, resources are usually distributed among many nodes. Even if one or more nodes depart and abandon a downloading file, for example, the remaining nodes should still have the data needed to complete the download.

Application Server

Definition:
An application server, in an n-tier software architecture, serves an API to expose business logic and business processes for use by third-party applications.

The term can refer to:

1. the services that a server makes available
2. the computer hardware on which the services run
3. the software framework used to host the services (such as JBoss application server or Oracle Application Server)

Java application servers :

Following the success of the Java platform, the term application server sometimes refers to a J2EE or Java EE 5 application server. Some of the better-known Java Enterprise Edition application servers include:

* WebSphere Application Server and WebSphere Application Server Community Edition (IBM)
* Sybase Enterprise Application Server (Sybase Inc)
* WebLogic Server (Oracle)
* JBoss (Red Hat)
* JRun (Adobe Systems)
* Apache Geronimo (Apache Software Foundation)
* Oracle OC4J (Oracle)
* Sun Java System Application Server (based on GlassFish Application Server)(Sun Microsystems)
* SAP Netweaver AS (ABAP/Java) (SAP)
* Glassfish Application Server (open source)

The web modules include servlets and JavaServer Pages. Business logic resides in Enterprise JavaBeans (EJB-3 and later). The Hibernate project offers an EJB-3 container implementation for the JBoss application server. Tomcat from Apache and JOnAS from ObjectWeb exemplify typical containers which can store these modules.

A Java Server Page (JSP) (a servlet from Java) executes in a web container — the Java equivalent of CGI scripts. JSPs provide a way to create HTML pages by embedding references to the server logic within the page. HTML coders and Java programmers can work side by side by referencing each other's code from within their own. JavaBeans are the independent class components of the Java architecture from Sun Microsystems.

The application servers mentioned above mainly serve web applications. Some application servers target networks other than web-based ones: Session Initiation Protocol servers, for instance, target telephony networks.

Microsoft platform :
Microsoft has contributed the .NET Framework to the world of application servers. .NET technology includes the Windows Communication Foundation, .NET Remoting, ADO.NET, and ASP.NET among several other components. It works with (or depends upon) other Microsoft products, such as Microsoft Message Queuing and Internet Information Services.

Zend platform :
Zend offers an application server called Zend Server — used for running and managing PHP applications.

Other platforms :
Open-source application servers also come from other vendors. Examples include Appaserver, Base4, Zope and Spring Framework.

Non-Java offerings have no formal interoperability specifications on a par with the Java Specification Request. As a result, interoperability between non-Java products is poor compared to that of Java EE based products. To address these shortcomings, specifications for enterprise application integration and service-oriented architecture were designed[by whom?] to connect the many different products. These specifications include Business Application Programming Interface, Web Services Interoperability, and Java EE Connector Architecture.

Advantages of application servers :

Data and code integrity
By centralizing business logic on an individual server or on a small number of server machines, updates and upgrades to the application for all users can be guaranteed. There is no risk of old versions of the application accessing or manipulating data in an older, incompatible manner.

Centralized configuration
Changes to the application configuration, such as a move of database server, or system settings, can take place centrally.

Security
A central point through which service-providers can manage access to data and portions of the application itself counts as a security benefit, devolving responsibility for authentication away from the potentially insecure client layer without exposing the database layer.

Performance
By limiting the network traffic to performance-tier traffic the client-server model improves the performance of large applications in heavy usage environments.[citation needed]

Total Cost of Ownership (TCO)
In combination, the benefits above may result in cost savings to an organization developing enterprise applications. In practice, however, the technical challenges of writing software that conforms to that paradigm, combined with the need for software distribution to distribute client code, somewhat negate these benefits.

Transaction Support
A transaction represents a unit of activity in which many updates to resources (on the same or distributed data sources) can be made atomic (as an indivisible unit of work). End-users can benefit from a system-wide standard behaviour, from reduced time to develop, and from reduced costs. As the server does a lot of the tedious code-generation, developers can focus on business logic.

Web Server

Definition:
The term web server or webserver can mean one of two things:
1. A computer program that is responsible for accepting HTTP requests from clients (user agents such as web browsers), and serving them HTTP responses along with optional data contents, which usually are web pages such as HTML documents and linked objects (images, etc.).
2. A computer that runs a computer program as described above.

Common features:
Although web server programs differ in detail, they all share some basic common features.
1. HTTP: every web server program operates by accepting HTTP requests from the client, and providing an HTTP response to the client. The HTTP response usually consists of an HTML or XHTML document, but can also be a raw file, an image, or some other type of document (defined by MIME-types). If some error is found in client request or while trying to serve it, a web server has to send an error response which may include some custom HTML or text messages to better explain the problem to end users.

2. Logging: usually web servers have also the capability of logging some detailed information, about client requests and server responses, to log files; this allows the webmaster to collect statistics by running log analyzers on these files.

In practice many web servers also implement the following features:
1. Authentication, optional authorization request (request of user name and password) before allowing access to some or all kind of resources.

2. Handling of static content (file content recorded in server's filesystem(s)) and dynamic content by supporting one or more related interfaces (SSI, CGI, SCGI, FastCGI, JSP,ColdFusion, PHP, ASP, ASP.NET, Server API such as NSAPI, ISAPI, etc.).

3. HTTPS support (by SSL or TLS) to allow secure (encrypted) connections to the server on the standard port 443 instead of usual port 80.

4. Content compression (i.e. by gzip encoding) to reduce the size of the responses (to lower bandwidth usage, etc.).

5. Virtual hosting to serve many web sites using one IP address.

6. Large file support to be able to serve files whose size is greater than 2 GB on 32 bit OS.

7. Bandwidth throttling to limit the speed of responses in order to not saturate the network and to be able to serve more clients.

Origin of returned content:

The origin of the content sent by server is called:

•static if it comes from an existing file lying on a filesystem;
•dynamic if it is dynamically generated by some other program or script or application programming interface (API) called by the web server.

Serving static content is usually much faster (from 2 to 100 times) than serving dynamic content, especially if the latter involves data pulled from a database.

Path translation:
Web servers are able to map the path component of a Uniform Resource Locator (URL) into:
• a local file system resource (for static requests);
• an internal or external program name (for dynamic requests).

For a static request the URL path specified by the client is relative to the Web server's root directory.
Consider the following URL as it would be requested by a client:
---------------------------------------------------------------
http://www.example.com/path/file.html
---------------------------------------------------------------
The client's web browser will translate it into a connection to www.example.com with the following HTTP 1.1 request:
-----------------------------------------
GET /path/file.html HTTP/1.1
Host: www.example.com
-----------------------------------------
The web server on www.example.com will append the given path to the path of its root directory. On Unix machines, this is commonly /var/www. The result is the local file system resource:
-----------------------------------------
/var/www/path/file.html
-----------------------------------------
The web server will then read the file, if it exists, and send a response to the client's web browser. The response will describe the content of the file and contain the file itself.

Load limits:

A web server (program) has defined load limits, because it can handle only a limited number of concurrent client connections (usually between 2 and 60,000, by default between 500 and 1,000) per IP address (and TCP port) and it can serve only a certain maximum number of requests per second depending on:
• its own settings;
• the HTTP request type;
• content origin (static or dynamic);
• the fact that the served content is or is not cached;
• the hardware and software limits of the OS where it is working.
When a web server is near to or over its limits, it becomes overloaded and thus unresponsive.

Overload causes:
At any time web servers can be overloaded because of:
• Too much legitimate web traffic (i.e. thousands or even millions of clients hitting the web site in a short interval of time. e.g. Slashdot effect);
• DDoS (Distributed Denial of Service) attacks;
• Computer worms that sometimes cause abnormal traffic because of millions of infected computers (not coordinated among them);
• XSS viruses can cause high traffic because of millions of infected browsers and/or web servers;
• Internet web robots traffic not filtered/limited on large web sites with very few resources (bandwidth, etc.);
• Internet (network) slowdowns, so that client requests are served more slowly and the number of connections increases so much that server limits are reached;
• Web servers (computers) partial unavailability, this can happen because of required or urgent maintenance or upgrade, HW or SW failures, back-end (i.e. DB) failures, etc.; in these cases the remaining web servers get too much traffic and become overloaded.

Overload symptoms:
The symptoms of an overloaded web server are:
• requests are served with (possibly long) delays (from 1 second to a few hundred seconds);
• 500, 502, 503, 504 HTTP errors are returned to clients (sometimes also unrelated 404 error or even 408 error may be returned);
• TCP connections are refused or reset (interrupted) before any content is sent to clients;
• in very rare cases, only partial contents are sent (but this behavior may well be considered a bug, even if it usually depends on unavailable system resources).

Anti-overload techniques:
To partially overcome above load limits and to prevent overload, most popular web sites use common techniques like:
• managing network traffic, by using:
o Firewalls to block unwanted traffic coming from bad IP sources or having bad patterns;
o HTTP traffic managers to drop, redirect or rewrite requests having bad HTTP patterns;
o Bandwidth management and traffic shaping, in order to smooth down peaks in network usage;
• deploying web cache techniques;
• using different domain names to serve different (static and dynamic) content by separate Web servers, i.e.:
http://images.example.com
http://www.example.com
• using different domain names and/or computers to separate big files from small and medium sized files; the idea is to be able to fully cache small and medium sized files and to efficiently serve big or huge (over 10 - 1000 MB) files by using different settings;
• using many Web servers (programs) per computer, each one bound to its own network card and IP address;
• using many Web servers (computers) that are grouped together so that they act or are seen as one big Web server, see also: Load balancer;
• adding more hardware resources (i.e. RAM, disks) to each computer;
• tuning OS parameters for hardware capabilities and usage;
• using more efficient computer programs for web servers, etc.;
• using other workarounds, especially if dynamic content is involved.

Paypal

PayPal is an e-commerce business allowing payments and money transfers to be made through the Internet. PayPal serves as an electronic alternative to traditional paper methods such as checks and money orders.
A PayPal account can be funded with an electronic debit from a bank account or by a credit card. The recipient of a PayPal transfer can either request a check from PayPal, establish their own PayPal deposit account or request a transfer to their bank account. PayPal is an example of a payment intermediary service that facilitates worldwide e-commerce.

PayPal performs payment processing for online vendors, auction sites, and other commercial users, for which it charges a fee. It sometimes also charges a transaction fee for receiving money (a percentage of the amount sent plus an additional fixed amount). The fees charged depend on the currency used, the payment option used, the country of the sender, the country of the recipient, the amount sent and the recipient's account type.In addition, eBay purchases made by credit card through PayPal may incur a "foreign transaction fee" if the seller is located in another country, as credit card issuers are automatically informed of the seller's country of origin.

Safety and protection policies
The PayPal Buyer Protection Policy states that customers may file a buyer complaint within 45 days if they did not receive an item or if the item they purchased was significantly not as described. If the buyer used a credit card, they might get a refund via chargeback from their credit card company.

According to PayPal, it protects sellers in a limited fashion via the Seller Protection Policy.In general the Seller Protection Policy is intended to protect the seller from certain kinds of chargebacks or complaints if seller meets certain conditions including proof of delivery to the buyer. PayPal states the Seller Protection Policy is "designed to protect sellers against claims by buyers of unauthorized payments and against claims of non-receipt of any merchandise". Note that this contrasts with the consumer protection they claim to offer. This policy should be read carefully before assuming protection. In particular the Seller Protection Policy includes a list of "Exclusions" which itself includes "Intangible goods", "Claims for receipt of goods 'not as described'" and "Total reversals over the annual limit". There are also other restrictions in terms of the sale itself, the payment method and the destination country the item is shipped to (simply having a tracking mechanism is not sufficient to guarantee the Seller Protection Policy is in effect). A class-action lawsuit was filed against PayPal, days after the company's successful initial public offering.

Difference Between http and https

Hypertext Transfer Protocol (http) is a system for transmitting and receiving information across the Internet. Http serves as a request and response procedure that all agents on the Internet follow so that information can be rapidly, easily, and accurately disseminated between servers, which hold information, and clients, who are trying to access it. Http is commonly used to access html pages, but other resources can be utilized as well through http. In many cases, clients may be exchanging confidential information with a server, which needs to be secured in order to prevent unauthorized access. For this reason, https, or secure http, was developed by Netscape corporation to allow authorization and secured transactions.

In many ways, https is identical to http, because it follows the same basic protocols. The http or https client, such as a Web browser, establishes a connection to a server on a standard port. When a server receives a request, it returns a status and a message, which may contain the requested information or indicate an error if part of the process malfunctioned. Both systems use the same Uniform Resource Identifier (URI) scheme, so that resources can be universally identified. Use of https in a URI scheme rather than http indicates that an encrypted connection is desired.

There are some primary differences between http and https, however, beginning with the default port, which is 80 for http and 443 for https. Https works by transmitting normal http interactions through an encrypted system, so that in theory, the information cannot be accessed by any party other than the client and end server. There are two common types of encryption layers: Transport Layer Security (TLS) and Secure Sockets Layer (SSL), both of which encode the data records being exchanged.

When using an https connection, the server responds to the initial connection by offering a list of encryption methods it supports. In response, the client selects a connection method, and the client and server exchange certificates to authenticate their identities. After this is done, both parties exchange the encrypted information after ensuring that both are using the same key, and the connection is closed. In order to host https connections, a server must have a public key certificate, which embeds key information with a verification of the key owner's identity. Most certificates are verified by a third party so that clients are assured that the key is secure.

Https is used in many situations, such as log-in pages for banking, forms, corporate log ons, and other applications in which data needs to be secure. However, if not implemented properly, https is not infallible, and therefore it is extremely important for end users to be wary about accepting questionable certificates and cautious with their personal information while using the Internet.