Hypertext Transfer Protocol (http)

Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. Its use for retrieving inter-linked resources led to the establishment of the World Wide Web.

HTTP development was coordinated by the World Wide Web Consortium and the Internet Engineering Task Force (IETF), culminating in the publication of a series of Requests for Comments (RFCs), most notably RFC 2616 (June 1999), which defines HTTP/1.1, the version of HTTP in common use.

HTTP is a request/response standard of a client and a server. A client is the end-user, the server is the web site. The client making a HTTP request—using a web browser, spider, or other end-user tool—is referred to as the user agent. The responding server—which stores or creates resources such as HTML files and images—is called the origin server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels. HTTP is not constrained to using TCP/IP and its supporting layers, although this is its most popular application on the Internet. Indeed HTTP can be "implemented on top of any other protocol on the Internet, or on other networks." HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used."

Typically, an HTTP client initiates a request. It establishes a Transmission Control Protocol (TCP) connection to a particular port on a host (port 80 by default; see List of TCP and UDP port numbers). An HTTP server listening on that port waits for the client to send a request message. Upon receiving the request, the server sends back a status line, such as "HTTP/1.1 200 OK", and a message of its own, the body of which is perhaps the requested resource, an error message, or some other information.

Resources to be accessed by HTTP are identified using Uniform Resource Identifiers (URIs) (or, more specifically, Uniform Resource Locators (URLs)) using the http: or https URI schemes.

Request message:
uest message consists of the following:

* Request line, such as GET /images/logo.gif HTTP/1.1, which requests a resource called /images/logo.gif from server
* Headers, such as Accept-Language: en
* An empty line
* An optional message body

The request line and headers must all end with (that is, a carriage return followed by a line feed). The empty line must consist of only and no other whitespace. In the HTTP/1.1 protocol, all headers except Host are optional.

A request line containing only the path name is accepted by servers to maintain compatibility with HTTP clients before the HTTP/1.0 specification.

Request methods:

HTTP defines eight methods (sometimes referred to as "verbs") indicating the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server.

HEAD
Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.

GET
Requests a representation of the specified resource. Note that GET should not be used for operations that cause side-effects, such as using it for taking actions in web applications. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause. See safe methods below.

POST
Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.

PUT
Uploads a representation of the specified resource.

DELETE
Deletes the specified resource.

TRACE
Echoes back the received request, so that a client can see what intermediate servers are adding or changing in the request.

OPTIONS
Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.

CONNECT
Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.

HTTP servers are required to implement at least the GET and HEAD methods and, whenever possible, also the OPTIONS method.

Safe methods
Some methods (for example, HEAD, GET, OPTIONS and TRACE) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server. In other words, they should not have side effects, beyond relatively harmless effects such as logging, caching, the serving of banner advertisements or incrementing a web counter. Making arbitrary GET requests without regard to the context of the application's state should therefore be considered safe.

By contrast, methods such as POST, PUT and DELETE are intended for actions which may cause side effects either on the server, or external side effects such as financial transactions or transmission of email. Such methods are therefore not usually used by conforming web robots or web crawlers, which tend to make requests without regard to context or consequences.

Despite the prescribed safety of GET requests, in practice their handling by the server is not technically limited in any way, and careless or deliberate programming can just as easily (or more easily, due to lack of user agent precautions) cause non-trivial changes on the server. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents, which can make unintended changes on the server.

Idempotent methods and web applications
Methods PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request. Methods GET, HEAD, OPTIONS and TRACE, being prescribed as safe, should also be idempotent, as HTTP is a stateless protocol.

By contrast, the POST method is not necessarily idempotent, and therefore sending an identical POST request multiple times may further affect state or cause further side effects (such as financial transactions). In some cases this may be desirable, but in other cases this could be due to an accident, such as when a user does not realize that their action will result in sending another request, or they did not receive adequate feedback that their first request was successful. While web browsers may show alert dialog boxes to warn users in some cases where reloading a page may re-submit a POST request, it is generally up to the web application to handle cases where a POST request should not be submitted more than once.

Note that whether a method is idempotent is not enforced by the protocol or web server. It is perfectly possible to write a web application in which (for example) a database insert or other non-idempotent action is triggered by a GET or other request. Ignoring this recommendation, however, may result in undesirable consequences if a user agent assumes that repeating the same request is safe when it isn't.

Status codes:
n HTTP/1.0 and since, the first line of the HTTP response is called the status line and includes a numeric status code (such as "404") and a textual reason phrase (such as "Not Found"). The way the user agent handles the response primarily depends on the code and secondarily on the response headers. Custom status codes can be used since, if the user agent encounters a code it does not recognize, it can use the first digit of the code to determine the general class of the response.

Also, the standard reason phrases are only recommendations and can be replaced with "local equivalents" at the web developer's discretion. If the status code indicated a problem, the user agent might display the reason phrase to the user to provide further information about the nature of the problem. The standard also allows the user agent to attempt to interpret the reason phrase, though this might be unwise since the standard explicitly specifies that status codes are machine-readable and reason phrases are human-readable.

List of HTTP status codes
1. 1xx Informational
2. 2xx Success
3. 3xx Redirection
4. 4xx Client Error
5. 5xx Server Error

Persistent connections:
In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request.

Such persistent connections reduce lag perceptibly, because the client does not need to re-negotiate the TCP connection after the first request has been sent.

Version 1.1 of the protocol made bandwidth optimization improvements to HTTP/1.0. For example, HTTP/1.1 introduced chunked transfer encoding to allow content on persistent connections to be streamed, rather than buffered. HTTP pipelining further reduces lag time, allowing clients to send multiple requests before a previous response has been received to the first one. Another improvement to the protocol was byte serving, which is when a server transmits just the portion of a resource explicitly requested by a client.

HTTP session state:
HTTP is a stateless protocol. The advantage of a stateless protocol is that hosts do not need to retain information about users between requests, but this forces web developers to use alternative methods for maintaining users' states. For example, when a host needs to customize the content of a website for a user, the web application must be written to track the user's progress from page to page. A common method for solving this problem involves sending and receiving cookies. Other methods include server side sessions, hidden variables (when the current page is a form), and URL encoded parameters (such as /index.php?session_id=some_unique_session_code).

Secure HTTP:
There are currently two methods of establishing a secure HTTP connection: the HTTPS URI scheme and the HTTP 1.1 Upgrade header, introduced by RFC 2817. Browser support for the Upgrade header is, however, nearly non-existent, hence the HTTPS URI scheme is still the dominant method of establishing a secure HTTP connection. Secure HTTP is notated by the prefix HTTPS:// instead of HTTP://

HTTPS URI scheme
HTTPS: is a URI scheme syntactically identical to the http: scheme used for normal HTTP connections, but which signals the browser to use an added encryption layer of SSL/TLS to protect the traffic. SSL is especially suited for HTTP since it can provide some protection even if only one side of the communication is authenticated. This is the case with HTTP transactions over the Internet, where typically only the server is authenticated (by the client examining the server's certificate).

HTTP 1.1 Upgrade header
HTTP 1.1 introduced support for the Upgrade header. In the exchange, the client begins by making a clear-text request, which is later upgraded to TLS. Either the client or the server may request (or demand) that the connection be upgraded. The most common usage is a clear-text request by the client followed by a server demand to upgrade the connection, which looks like this:

Client:
GET /encrypted-area HTTP/1.1
Host: www.example.com

Server:
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

The server returns a 426 status-code because 400 level codes indicate a client failure (see List of HTTP status codes), which correctly alerts legacy clients that the failure was client-related.
The benefits of using this method for establishing a secure connection are:
* that it removes messy and problematic redirection and URL rewriting on the server side,
* it allows virtual hosting of secured websites (although HTTPS also allows this using Server Name Indication), and
* it reduces user confusion by providing a single way to access a particular resource.

A weakness with this method is that the requirement for a secure HTTP cannot be specified in the URI. In practice, the (untrusted) server will thus be responsible for enabling secure HTTP, not the (trusted) client.

Search Engine Optimization(SEO)

Search engine optimization or SEO is the art of placing your website in the first few pages of a search engine for a strategically defined set of keywords. In simple words it means that your website will appear on the first page of a search engine like Google, when someone searches for your product or service.

Typically, the earlier a site appears in the search results list, the more visitors it will receive from the search engine. SEO may target different kinds of search, including image search, local search, and industry-specific vertical search engines.
As an Internet marketing strategy, SEO considers how search engines work and what people search for. Optimizing a website primarily involves editing its content and HTML coding to both increase its relevance to specific keywords and to remove barriers to the indexing activities of search engines.

The acronym "SEO" can also refer to "search engine optimizers," a term adopted by an industry of consultants who carry out optimization projects on behalf of clients, and by employees who perform SEO services in-house. Search engine optimizers may offer SEO as a stand-alone service or as a part of a broader marketing campaign. Because effective SEO may require changes to the HTML source code of a site, SEO tactics may be incorporated into web site development and design. The term "search engine friendly" may be used to describe web site designs, menus, content management systems and shopping carts that are easy to optimize.

Another class of techniques, known as black hat SEO or Spamdexing, use methods such as link farms and keyword stuffing that degrade both the relevance of search results and the user-experience of search engines. Search engines look for sites that employ these techniques in order to remove them from their indices.

Why Search Engine Optimization?
# Major search engines command over 400 million searches everyday, day after day. A well designed Search engine optimization(SEO) program helps you get this piece of the pie, which you might be losing otherwise to your competition.
# SEO offers a much better return on investment than other traditional forms of internet marketing like banner campaigns and email marketing.
# Search Engine Optimization helps you capture targeted traffic... people who are already looking for the product or service you offer.
# Search Engine Optimization by an efficient SEO Company is a long term and permanent answer to your traffic woes. Once a website has been optimized for search engines it can stay at the top for long periods of time.

Webmasters with search engines:
By 1997 search engines recognized that webmasters were making efforts to rank well in their search engines, and that some webmasters were even manipulating their rankings in search results by stuffing pages with excessive or irrelevant keywords. Early search engines, such as Infoseek, adjusted their algorithms in an effort to prevent webmasters from manipulating rankings.

Due to the high marketing value of targeted search results, there is potential for an adversarial relationship between search engines and SEOs. In 2005, an annual conference, AIRWeb, Adversarial Information Retrieval on the Web,was created to discuss and minimize the damaging effects of aggressive web content providers.

SEO companies that employ overly aggressive techniques can get their client websites banned from the search results. In 2005, the Wall Street Journal reported on a company, Traffic Power, which allegedly used high-risk techniques and failed to disclose those risks to its clients. Wired magazine reported that the same company sued blogger and SEO Aaron Wall for writing about the ban. Google's Matt Cutts later confirmed that Google did in fact ban Traffic Power and some of its clients.

Some search engines have also reached out to the SEO industry, and are frequent sponsors and guests at SEO conferences, chats, and seminars. In fact, with the advent of paid inclusion, some search engines now have a vested interest in the health of the optimization community. Major search engines provide information and guidelines to help with site optimization. Google has a Sitemaps program to help webmasters learn if Google is having any problems indexing their website and also provides data on Google traffic to the website. Google guidelines are a list of suggested practices Google has provided as guidance to webmasters. Yahoo! Site Explorer provides a way for webmasters to submit URLs, determine how many pages are in the Yahoo! index and view link information.


Getting indexed

he leading search engines, Google, Yahoo! and Microsoft, use crawlers to find pages for their algorithmic search results. Pages that are linked from other search engine indexed pages do not need to be submitted because they are found automatically. Some search engines, notably Yahoo!, operate a paid submission service that guarantee crawling for either a set fee or cost per click. Such programs usually guarantee inclusion in the database, but do not guarantee specific ranking within the search results. Yahoo's paid inclusion program has drawn criticism from advertisers and competitors.Two major directories, the Yahoo Directory and the Open Directory Project both require manual submission and human editorial review. Google offers Google Webmaster Tools, for which an XML Sitemap feed can be created and submitted for free to ensure that all pages are found, especially pages that aren't discoverable by automatically following links.

Search engine crawlers may look at a number of different factors when crawling a site. Not every page is indexed by the search engines. Distance of pages from the root directory of a site may also be a factor in whether or not pages get crawled.

Preventing crawling
To avoid undesirable content in the search indexes, webmasters can instruct spiders not to crawl certain files or directories through the standard robots.txt file in the root directory of the domain. Additionally, a page can be explicitly excluded from a search engine's database by using a meta tag specific to robots. When a search engine visits a site, the robots.txt located in the root directory is the first file crawled. The robots.txt file is then parsed, and will instruct the robot as to which pages are not to be crawled. As a search engine crawler may keep a cached copy of this file, it may on occasion crawl pages a webmaster does not wish crawled. Pages typically prevented from being crawled include login specific pages such as shopping carts and user-specific content such as search results from internal searches. In March 2007, Google warned webmasters that they should prevent indexing of internal search results because those pages are considered search spam.

Search engine optimization methodology includes:
:
1. Website Review:
To rank on Google or any other search engine, a site needs to be indexed first. Hence, the first step in the process of search engine optimization is to ensure that your site pages can be crawled and indexed by the search engine spiders. In this step we analyze your code and identify possible spider stoppers in a website. These may include broken links, missing tags, complicated link structure and other subtle factors that may have been overlooked when the site was designed.

2. Goal Analysis
Why are you indulging in SEO services? What do you expect to gain from your SEO campaign? Do you have practical search engine ranking targets that you would like to achieve?

It is important to have goals clearly defined in an SEO campaign. These goals can be in terms of an increase in revenue from organic search engine traffic, increase in ROI, increase in traffic or just rankings for branding. Keeping goals in perspective, customize and present the best SEO strategy possible given the time-frame, resources and other practical constraints.

3. Competition Analysis
This step involves studying what your competition is doing. Websites of competitors, which have undergone search engine optimization, offer valuable keyword and optimization insights. Analyzing an already optimized site allows us to determine their lead over your site with regards to rankings. Then it determine SEO optimization techniques being employed and the segments being targeted actively on search engines. After this step, able to tell you exactly what your competitor is doing and what you should do to beat them on search engines.

4. Keyword Identification
Many online businesses, despite having great search engine rankings, either do not get enough traffic to their site or do not convert enough visitors. A major reason for this is because the keywords that they are targeting may not be the keywords that are being searched for on the search engines. Keyword identification is a very important part of search engine optimization and includes researching keywords that will not only get great traffic but are also most relevant to your business.

5. On Page Optimization
This step in the process of SEO involves the actual optimization of your web pages. Here, pages will be optimized with regards to tags, link structures, images, body text, and other visible and invisible parts.

6. Building Incoming Links
Good incoming links are often the difference between good rankings and great rankings. Incoming links can be reciprocal links or one way links from directories, articles and news releases. Our link popularity campaigns are human powered and completely manual.

7. Search Engine Submissions
Manual Submissions to search engines and directories is a process often referred as search engine submissions. Many advertise a quick and simple software or service which helps submit to over 1000 engines for a few dollars, but few tell you that it is the top 10 engines that command over 85% of the internet's search engine traffic.

8. Analysis and Tweaking
Search engine optimization is a long-term solution to your traffic woes. Our comprehensive seo services involve continuous fine tuning of the website based on traffic trends and ranking trends. Search engines often change their algorithms... SEO tweak your website to compensate of the changes, hence enabling you to stay on top.

White hat versus black hat:
SEO techniques can be classified into two broad categories: techniques that search engines recommend as part of good design, and those techniques of which search engines do not approve. The search engines attempt to minimize the effect of the latter, among them spamdexing. Some industry commentators have classified these methods, and the practitioners who employ them, as either white hat SEO, or black hat SEO. White hats tend to produce results that last a long time, whereas black hats anticipate that their sites may eventually be banned either temporarily or permanently once the search engines discover what they are doing.

An SEO technique is considered white hat if it conforms to the search engines' guidelines and involves no deception. As the search engine guidelines are not written as a series of rules or commandments, this is an important distinction to note. White hat SEO is not just about following guidelines, but is about ensuring that the content a search engine indexes and subsequently ranks is the same content a user will see. White hat advice is generally summed up as creating content for users, not for search engines, and then making that content easily accessible to the spiders, rather than attempting to trick the algorithm from its intended purpose. White hat SEO is in many ways similar to web development that promotes accessibility,although the two are not identical.

Black hat SEO attempts to improve rankings in ways that are disapproved of by the search engines, or involve deception. One black hat technique uses text that is hidden, either as text colored similar to the background, in an invisible div, or positioned off screen. Another method gives a different page depending on whether the page is being requested by a human visitor or a search engine, a technique known as cloaking.

Search engines may penalize sites they discover using black hat methods, either by reducing their rankings or eliminating their listings from their databases altogether. Such penalties can be applied either automatically by the search engines' algorithms, or by a manual site review. One infamous example was the February 2006 Google removal of both BMW Germany and Ricoh Germany for use of deceptive practices. Both companies, however, quickly apologized, fixed the offending pages, and were restored to Google's list.

Verification and Validation (V & V)

In software project management, software testing, and software engineering, Verification and Validation (V&V) is the process of checking that a software system meets specifications and that it fulfils its intended purpose. It is normally part of the software testing process of a project.

Definitions
It is also known as software quality control.
Validation checks that the product design satisfies or fits the intended usage (high-level checking) — i.e., you built the right product. This is done through dynamic testing and other forms of review.
According to the Capability Maturity Model (CMMI-SW v1.1), “Validation - The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements. [IEEE-STD-610] Verification- The process of evaluating software to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. [IEEE-STD-610]."

In other words, validation ensures that the product actually meets the user's needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications. Validation ensures that ‘you built the right thing’. Verification ensures that ‘you built it right’. Validation confirms that the product, as provided, will fulfill its intended use.

Validation and Verification
Verification is one aspect of testing a product's fitness for purpose. Validation is the complementary aspect. Often one refers to the overall checking process as V & V.

* Validation: "Are we trying to make the right thing?", i.e., does the product do what the user really requires?
Have we built the right software (i.e., is this what the customer wants?)?
It is product based.

* Verification: "Have we made what we were trying to make?", i.e., does the product conform to the specifications?
Have we built the software right (i.e., does it match the specification?)?
It is process based.

The verification process consists of static and dynamic parts. E.g., for a software product one can inspect the source code (static) and run against specific test cases (dynamic). Validation usually can only be done dynamically, i.e., the product is tested by putting it through typical usages and atypical usages ("Can we break it?").


Within the modeling and simulation community, the definitions of validation, verification and accreditation are similar:

* Validation: The process of determining the degree to which a model, simulation, or federation of models and simulations, and their associated data are accurate representations of the real world from the perspective of the intended use(s).
* Accreditation is the formal certification that a model or simulation is acceptable to be used for a specific purpose.
* Verification: The process of determining that a computer model, simulation, or federation of models and simulations implementations and their associated data accurately represents the developer's conceptual description and specifications.

Both verification and validation are related to the concepts of quality and of software quality assurance. By themselves, verification and validation do not guarantee software quality; planning, traceability, configuration management and other aspects of software engineering are required.

Classification of methods
In mission-critical systems where flawless performance is absolutely necessary, formal methods can be used to ensure the correct operation of a system. However, often for non-mission-critical systems, formal methods prove to be very costly and an alternative method of V&V must be sought out. In this case, syntactic methods are often used.

Test cases
A test case is a tool used in the V&V process.

The QA team prepares test cases for verification--to determine if the process that was followed to develop the final product is right.

The QC team uses a test case for validation--if the product is built according to the requirements of the user. Other methods, such as reviews, when used early in the Software Development Life Cycle provide for validation.

Independent Verification and Validation
Verification and validation often is carried out by a separate group from the development team; in this case, the process is called "Independent Verification and Validation", or IV&V.

Risk Based Testing

What exactly is risk?
It’s the possibility of negative or undesirable outcome.
Risk can be defined as the chance of an event, hazard, threat or situation occurring and its undesirable consequences, a potential problem. The level of risk will be determined by the likelihood of an adverse event happening and the impact (the harm resulting from that event).

In the future, a risk has some likelihood between 0% and 100 %; it is possibility, not a certainty. In the past, however, either the risk has materialized and become an outcome or issue or it has not; the likelihood of a risk in the past is either 0% or 100%.
The likelihood of a risk becoming an outcome is one factor to consider when thinking about the level of risk associated with its possible negative consequences. The more likely the outcome is, the worse the risk. However, likelihood is not the only consideration.
For example, most people are likely to catch a cold in the course of their lives, usually more than once. The typical healthy individual suffers no serious consequences. Therefore, the overall level of risk associated with colds is low for this person. But the risk of a cold for an elderly person with breathing difficulties would be high. The potential consequences or impact is an important consideration affecting the level of risk, too.

Classification of Risk
1. Product Risks (Factors relating to what is produced by the work, i.e. the thing we are testing)
2. Project Risks (Factors relating to the way the work is carried out, i.e. the test project)

1.Product Risks:

Potential failure areas (adverse future events or hazards) in the software or system are known as product risks, as they are a risk to the quality of the product, such as:

o Failure-prone software delivered.
o The potential that the software/hardware could cause harm to an individual or company.
o Poor software characteristics (e.g. functionality, reliability, usability and performance).
o Software that does not perform its intended functions.
Risks are used to decide where to start testing and where to test more; testing is used to reduce the
risk of an adverse effect occurring, or to reduce the impact of an adverse effect.

Product risks are a special type of risk to the success of a project. Testing as a risk-control activity provides feedback about the residual risk by measuring the effectiveness of critical defect removal and of contingency plans.

You can think of a product risk as the possibility that the system or software might fail to satisfy some reasonable customer, user, or stakeholder expectation. ‘Product Risks’ sometimes refer as ‘Quality Risks’ as they are risks to the quality of the product. Unsatisfactory software might omit some key functions that the customers specified, the users required or the stakeholders were promised. Unsatisfactory software might be unreliable and frequently fail to behave normally. Unsatisfactory software might fail in ways that cause financial or other damage to a user or the company that user works for. Unsatisfactory software might have problems related to a particular quality characteristic, which might not be functionality, but rather security, reliability, usability, maintainability or performance.

You can think of a product risk as the possibility that the system or software
might fail to satisfy some reasonable customer, user, or stakeholder
expectation. (Some authors refer to 'product risks' as 'quality risks' as they are risks to
the quality of the product.) Unsatisfactory software might omit some key
function that the customers specified, the users required or the stakeholders were
promised. Unsatisfactory software might be unreliable and frequently fail to
behave normally. Unsatisfactory software might fail in ways that cause financial
or other damage to a user or the company that user works for. Unsatisfactory
software might have problems related to a particular quality characteristic,
which might not be functionality, but rather security, reliability, usability,
maintainability or performance.

Risk-based testing is the idea that we can organize our testing efforts in a way that reduces the residual level of product risk when the system ships. Risk-based testing uses risk to prioritize and emphasize the appropriate tests during test execution, but it's about more than that. Risk-based testing starts early in the project, identifying risks to system quality and using that knowledge of risk to guide testing planning, specification, preparation and execution. Risk-based testing involves both mitigation - testing to provide opportunities to reduce the likelihood of defects, especially high-impact defects - and contingency - testing to identify work-arounds to make the defects that do get past us less painful.
Risk-based testing also involves measuring how well we are doing at finding and
removing defects in critical areas, as was shown in Table 1. Risk-based testing
can also involve using risk analysis to identify proactive opportunities to remove
or prevent defects through non-testing activities and to help us select which test
activities to perform.



Risk-based testing starts with product risk analysis. One technique for risk
analysis is a close reading of the requirements specification, design specifica-
tions, user documentation and other items. Another technique is brainstorming
with many of the project stakeholders. Another is a sequence of one-on-one or
small-group sessions with the business and technology experts in the company.
Some people use all these techniques when they can. To us, a team-based
approach that involves the key stakeholders and experts is preferable to a
purely document-based approach, as team approaches draw on the knowledge,
wisdom and insight of the entire team to determine what to test and how much.

While you could perform the risk analysis by asking, 'What should we worry
about?' usually more structure is required to avoid missing things. One way to
provide that structure is to look for specific risks in particular product risk
categories.You could consider risks in the areas of functionality, localization,
usability, reliability, performance and supportability.
You might have a checklist of typical or past risks that should be considered. You might also want to review the tests that failed and the bugs that you found in a previous release or a similar product. These lists and reflections serve to jog the memory, forcing you to think about risks of particular kinds, as well as helping you structure the documentation of the product risks.

When we talk about specific risks, we mean a particular kind of defect or
failure that might occur. For example, if you were testing the calculator utility
that is bundled with Microsoft Windows, you might identify 'incorrect
calculation' as a specific risk within the category of functionality. However, this is too broad. Consider incorrect addition. This is a high-impact kind of defect, as
everyone who uses the calculator will see it. It is unlikely, since addition is not
a complex algorithm. Contrast that with an incorrect sine calculation. This is a
low-impact kind of defect, since few people use the sine function on the
Windows calculator. It is more likely to have a defect, though, since sine
functions are hard to calculate.

After identifying the risk items, you and, if applicable, the stakeholders,
should review the list to assign the likelihood of problems and the impact of
problems associated with each one. There are many ways to go about this
assignment of likelihood and impact. You can do this with all the stakeholders
at once. You can have the business people determine impact and the technical
people determine likelihood, and then merge the determinations. Either way,
the reason for identifying risks first and then assessing their level, is that the
risks are relative to each other.

The scales used to rate likelihood and impact vary. Some people rate them
high, medium and low. Some use a 1-10 scale. The problem with a 1-10 scale is
that it's often difficult to tell a 2 from a 3 or a 7 from an 8, unless the differences between each rating are clearly defined. A five-point scale (very high, high, medium, low and very low) tends to work well.

Given two classifications of risk levels, likelihood and impact, we have a
problem, though: We need a single, aggregate risk rating to guide our testing
effort. As with rating scales, practices vary. One approach is to convert each risk
classification into a number and then either add or multiply the numbers to calculate a risk priority number. For example, suppose a particular risk has a high
likelihood and a medium impact. The risk priority number would then be 6 (2
times 3).

Armed with a risk priority number, we can now decide on the various risk-
mitigation options available to us. Do we use formal training for programmers
or analysts, rely on cross-training and reviews or assume they know enough? Do
we perform extensive testing, cursory testing or no testing at all? Should we
ensure unit testing and system testing coverage of this risk? These options and
more are available to us.

As you go through this process, make sure you capture the key information in
a document. We're not fond of excessive documentation but this quantity of infor-
mation simply cannot be managed in your head.
We recommend a lightweight table like the one shown in Table 2; we usually capture this in a spreadsheet.



Let's finish this section with two quick tips about product risk analysis. First,
remember to consider both likelihood and impact. While it might make you feel
like a hero to find lots of defects, testing is also about building confidence in key functions. We need to test the things that probably won't break but would be
catastrophic if they did.
Second, risk analyses, especially early ones, are educated guesses. Make
sure that you follow up and revisit the risk analysis at key project milestones.
For example, if you're following a V-model, you might perform the initial
analysis during the requirements phase, then review and revise it at the end
of the design and implementation phases, as well as prior to starting unit test,
integration test, and system test. We also recommend revisiting the risk
analysis during testing. You might find you have discovered new risks or
found that some risks weren't as risky as you thought and increased your confidence in the risk analysis.

2.Project risks
Project risks are the risks that surround the project’s capability to deliver its objectives, such as:

o Organizational factors:
- skill and staff shortages;
- personal and training issues;
- political issues, such as
. problems with testers communicating their needs and test results;
. failure to follow up on information found in testing and reviews (e.g. not
improving development and testing practices).
- improper attitude toward or expectations of testing (e.g. not appreciating the value of finding defects during testing).

o Technical issues:
- problems in defining the right requirements;
- the extent that requirements can be met given existing constraints;
- the quality of the design, code and tests.

o Supplier issues:
- failure of a third party;
- contractual issues.

When analyzing, managing and mitigating these risks, the test manager is following well established
project management principles. The ‘Standard for Software Test Documentation’ (IEEE 829) outline
for test plans requires risks and contingencies to be stated.

To deal with the project risks that apply to testing, we can use the same concepts we apply to identifying, prioritizing and managing product risks.

Remembering that a risk is the possibility of a negative outcome, what
project risks affect testing? There are direct risks such as the late delivery of the test items to the test team or availability issues with the test environment. There are also indirect risks such as excessive delays in repairing defects found in
testing or problems with getting professional system administration support for
the test environment.

To discover project risks, ask yourself and other project participants and stakeholders,
-What could go wrong on the project to delay or invalidate the test plan, the test strategy and the test estimate?
-What are unacceptable outcomes of testing or in testing?
-What are the likelihoods and impacts of each of these risks?'
-This process is very much like the risk analysis process for products.

For any risk, product or project, you have four typical options:
• Mitigate: Take steps in advance to reduce the likelihood (and possibly the
impact) of the risk.
• Contingency: Have a plan in place to reduce the impact should the risk
become an outcome.
• Transfer: Convince some other member of the team or project stakeholder
to reduce the likelihood or accept the impact of the risk.
• Ignore: Do nothing about the risk, which is usually a smart option only
when there's little that can be done or when the likelihood and impact are
low.

There is another typical risk-management option, buying insurance, which is
not usually pursued for project or product risks on software projects, though it
is not unheard of.

Here are some typical risks along with some options for managing them.
• Logistics or product quality problems that block tests:
These can be mitigated through careful planning, good defect triage and management, and robust test design.

• Test items that won't install in the test environment:
These can be mitigated through smoke (or acceptance) testing prior to starting test phases or as part of a nightly build or continuous integration. Having a defined uninstall process is a good contingency plan.

• Excessive change to the product that invalidates test results or requires
updates to test cases, expected results and environments:
These can be mitigated through good change-control processes, robust test design and light weight test documentation. When severe incidents occur, transference of the
risk by escalation to management is often in order.

• Insufficient or unrealistic test environments that yield misleading results:
One option is to transfer the risks to management by explaining the limits on
test results obtained in limited environments. Mitigation - sometimes complete alleviation can be achieved by outsourcing tests such as performance
tests that are particularly sensitive to proper test environments.

Here are some additional risks to consider and perhaps to manage:

• Organizational issues such as shortages of people, skills or training,
problems with communicating and responding to test results, bad expec
tations of what testing can achieve and complexity of the project team or
organization.

• Supplier issues such as problems with underlying platforms or hardware,
failure to consider testing issues in the contract or failure to properly
respond to the issues when they arise.

• Technical problems related to ambiguous, conflicting or unprioritized
requirements, an excessively large number of requirements given other
project constraints, high system complexity and quality problems with the
design, the code or the tests.
There may be other risks that apply to your project and not all projects are
subject to the same risks.

Finally, don't forget that test items can also have risks associated with them.
For example, there is a risk that the test plan will omit tests for a functional area or that the test cases do not exercise the critical areas of the system.

Capability Maturity Model (CMM)

The Capability Maturity Model (CMM) in software engineering is a model of the maturity of the capability of certain business processes. A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization, and aids in the definition and understanding of an organization's processes.

Maturity model
A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model may provide, for example :

* a place to start
* the benefit of a community’s prior experiences
* a common language and a shared vision
* a framework for prioritizing actions
* a way to define what improvement means for your organization.

A maturity model can be used as a benchmark for comparison and as an aid to understanding - for example, for comparative assessment of different organizations where there is something in common that can be used as a basis for comparison. In the case of the CMM, for example, the basis for comparison would be the organizations' software development processes.

Capability Maturity Model Structure
The Capability Maturity Model involves the following aspects:

* Maturity Levels: A 5-Level process maturity continuum - where the uppermost (5th) level is a notional ideal state where processes would be systematically managed by a combination of process optimization and continuous process improvement.
* Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
* Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
* Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
* Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.

Levels of the Capability Maturity Model
There are five levels defined along the continuum of the CMM, and, according to the SEI: "Predictability, effectiveness, and control of an organization's software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief."

Level 1 - Ad hoc (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.

Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process discipline is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.

Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization.

Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.

Level 5 - Optimizing
It is a characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.

Software process framework for SEI's Capability Maturity Model

The software process framework documented is intended to guide those wishing to assess an organization/projects consistency with the CMM. For each maturity level there are five checklist types:

Error message

An error message is a message displayed when an unexpected condition occurs, usually on a computer or other device. Error messages are often displayed using dialog boxes. Error messages are used when user intervention is required, indicate that a desired operation has failed, or give very important warnings such as being out of hard disk space. Error messages are pervasive throughout computing, and are part of every operating system, or computer hardware device. Proper design of error messages is an important topic in usability and other fields of human-computer interaction.

Common error messages
These computer-related error messages can occur in almost any program.

* File not found occurs when the requested file cannot be found. The file may have been damaged, moved, deleted, or a bug may have caused the error.
* The device is not ready most often occurs when there is no floppy disk (or a bad disk) in the disk drive and the system tries to perform tasks involving the floppy disk.
* Access is denied occurs if the user has insufficient privileges to a file, or if it has been locked by some program or user.
* Out of memory occurs when the system has run out of memory or tries to load a file too large to store in RAM. The fix is to close some programs or get more memory.
* Low Disk Space occurs when the hard drive is full. To fix this, close some programs (to free swap file usage) and delete some files (normally temporary files, or other files after they have been backed up), or get a bigger hard drive.
* [program name] has encountered a problem and needs to close. We are sorry for the inconvenience. Windows XP message displayed when a program causes a general protection fault or invalid page fault.
* The blue screen of death.

Error message usability checklist

To be effective, an error message must contain the following information:
* Message ID - For many applications, a reference number for the error is an invaluable piece of information. This number will help network support personnel to easily diagnose the error and possible courses of action. An index also serves as a universally understood indicator of an error in situations where various languages are used.

* Timestamp - The date and time of the onset of an error should be displayed so that the help centre can correlate the event to log files with the same timestamp.

* Message type and severity - Classify the error as either an automatically recoverable error, manually recoverable error, or non-recoverable error, or some other appropriate label. Inform the user about the level of severity, and tell the user about the possible consequences of the exception.

* User and process details - Display information that identifies the user who “triggered” the error in the form of a user ID or whatever system is used to identify users for the specific system. The process or task that the system was trying to perform should also be documented in case users have multiple applications running and are not sure which one caused the error. This information is important in diagnosing errors from a helpdesk perspective.

* Short message with details button - The displayed message should be clear and concise, in "novice user" language. It should contain the reference number and the basic information regarding the type of error, severity, and corrective action. There should also be a details button which shows an advanced user more information about the specifics of the error. The details button can also be used to explain corrective actions to the user.

* Program state and configuration - Show information about the error that is relevant to the user. For example, if the user entered an invalid value in a field, the error message should tell the user which field caused the error and what the invalid values were. Showing current program field values and applicable configuration information in the message will allow the user to deduce the cause of the error and correct it. If a piece of hardware is not configured properly, the current configuration can point the user to the real problem. For example, if you have the wrong printer set as your default, the error message should show which printer is currently set to default so the user can clearly see that there is a problem. i.e. "Printer Epson 123A not ready" instead of "Printer not ready".

Message format
The format for error messages is not static. The format of error messages is dependent on many things, however the three main factors that influence the format design are as follows.

Technical limitations

The strengths and restrictions of the technology you're working with should be among the first things you take into account when planning error messages. You must be careful to ensure that the medium you use to communicate the error supports the size, shape, and style of your error message.

Amount of information presented

The nature of the error message will determine the amount of information required for the error message. If the error message is short –"Sorry, our Web site is currently undergoing maintenance, Please try again later." it may be more effective as a pop-up window than as a separately loaded page. This is because short messages can easily be drowned out if there is other content on the page. If there is no other content on the error message page, then the short error message will look out of place on a big empty page.

User input required

Finally, you should choose an error message format based on the type of input you require from the user to correct a problem. Errors that simply inform the user of a problem that they can’t fix, such as a busy server on a website, are best suited to pop ups. In this situation, all you need to do is inform the user of the problem, as no corrective action aside from trying again later. The only control available to the user should be the “Ok” button. However, controls such as “Retry/OK” and “Cancel” should be used if the user is being prompted to corrective action. For example, “Windows encountered an error and needs to restart. Would you like to restart now?” should include an option to cancel and to restart. The buttons should correspond to the available options, i.e. “Restart now” button vs. “OK”, and “Later” vs. “Cancel”. This makes the options clearer to the user and thereby being conducive to correct decision making.

Presentation guidelines
The presentation and appearance of error messages are critical factors that heavily influence how well a user comprehends and responds to an error message. The following three principles should be adhered to when designing an error message.

Capture the user's attention

The visual attributes of an error message, including its color, size, and location can and should be used to grab the user’s attention and inform them that an error has occurred. Usually, the color red, a bold font, and the location at the top of the page and in front of any other window are good ways to allow the user to know that an error is present. In addition, an exclamation point is often used as an iconographic symbol to express importance.

Explain what went wrong

To effectively communicate with users, the application must speak their language. Messages must explain what the problem is using terminology that even a novice user can understand. The key idea here is to explain what went wrong, not just tell the user an error code. This is not to say to never include error codes in the error message. Instead, explain it in the proper context if it could prove useful. For example, an error message could reference error code 3555 and display the message “Please contact our help desk and reference error code 3555 for assistance”.

Show where error occurred and suggest possible solutions

Pointing users to solutions can be accomplished many ways. The language used is an important factor in getting users to understand what went wrong and consequently, how to fix it. For example, a poor error message might read, "You have entered an invalid string character in Field 123A". A better error message reads, "The zip code field contains an invalid character. Only numbers may be entered". Novice users won’t know what a string character or field 123A is, but they will recognize what the zip code field and “numbers” are.

Additionally, you can show the user exactly where the problem occurred by providing visual cues such as highlighting the field label with color, font treatment, and iconographic images.

Once an error is located, instructions should be given to the user on corrective action, once again explained in the users’ language.

Providing examples of acceptable input is also a powerful technique for suggesting solutions for certain types of errors.

Design heuristics
The following is a general set of guidelines to aid in the effective design of error messages. There are many more that can be found in many different texts and this list is by no means absolute. Those included below are only a few of the commonly accepted heuristics.

* Do provide useful information that helps the user diagnose the problem - i.e. Use “Link target does not exist” instead of “Bad link”.
* Do be precise - i.e. “Missing file name extension” instead of “File not found.”
* Do describe the problem - i.e. “Disk full” instead of “File error.”
* Do use a neutral tone - i.e. Change the tone in “Bad input” to “Command is unrecognizable.” to avoid blaming the user.
* Do use complete sentences - i.e. Use “Binding is too long.” rather than “Binding too long.”
* Do not personify the system, unless you mean to convey a sense of naturalness - i.e. “Node parameter cannot use Windows NT protocols.” is better than “Parameter node does not speak any of our protocols.”
* Avoid displaying an error message at all, if possible, i.e. disable the Paste option if no data is on the clipboard, instead of showing an error like “No data on clipboard” when the user attempts a paste operation.

Different Messagebox symbols:

Acceptance Testing

Introduction
In software engineering, acceptance testing is formal testing conducted to determine whether a system satisfies its acceptance criteria and thus whether the customer should accept the system.
The main types of software testing are:
Component.
Interface.
System.
Acceptance.
Release.
Acceptance Testing checks the system against the "Requirements". It is similar to systems testing in that the whole system is checked but the important difference is the change in focus:
Systems Testing checks that the system that was specified has been delivered.
Acceptance Testing checks that the system delivers what was requested.
The customer, and not the developer should always do acceptance testing. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment.

The forms of the tests may follow those in system testing, but at all times they are informed by the business needs.

The test procedures that lead to formal 'acceptance' of new or changed systems. User Acceptance Testing is a critical phase of any 'systems' project and requires significant participation by the 'End Users'. To be of real use, an Acceptance Test Plan should be developed in order to plan precisely, and in detail, the means by which 'Acceptance' will be achieved. The final part of the UAT can also include a parallel run to prove the system against the current system.

Factors influencing Acceptance Testing
The User Acceptance Test Plan will vary from system to system but, in general, the testing should be planned in order to provide a realistic and adequate exposure of the system to all reasonably expected events. The testing can be based upon the User Requirements Specification to which the system should conform.
As in any system though, problems will arise and it is important to have determined what will be the expected and required responses from the various parties concerned; including Users; Project Team; Vendors and possibly Consultants / Contractors.
In order to agree what such responses should be, the End Users and the Project Team need to develop and agree a range of 'Severity Levels'. These levels will range from (say) 1 to 6 and will represent the relative severity, in terms of business / commercial impact, of a problem with the system, found during testing. Here is an example which has been used successfully; '1' is the most severe; and '6' has the least impact :-
'Show Stopper' i.e. it is impossible to continue with the testing because of the severity of this error / bug

Critical Problem; testing can continue but we cannot go into production (live) with this problem
Major Problem; testing can continue but live this feature will cause severe disruption to business processes in live operation
Medium Problem; testing can continue and the system is likely to go live with only minimal departure from agreed business processes
Minor Problem ; both testing and live operations may progress. This problem should be corrected, but little or no changes to business processes are envisaged
'Cosmetic' Problem e.g. colours; fonts; pitch size However, if such features are key to the business requirements they will warrant a higher severity level.
The users of the system, in consultation with the executive sponsor of the project, must then agree upon the responsibilities and required actions for each category of problem. For example, you may demand that any problems in severity level 1, receive priority response and that all testing will cease until such level 1 problems are resolved.
Caution. Even where the severity levels and the responses to each have been agreed by all parties; the allocation of a problem into its appropriate severity level can be subjective and open to question. To avoid the risk of lengthy and protracted exchanges over the categorisation of problems; we strongly advised that a range of examples are agreed in advance to ensure that there are no fundamental areas of disagreement; or, or if there are, these will be known in advance and your organisation is forewarned.
Finally, it is crucial to agree the Criteria for Acceptance. Because no system is entirely fault free, it must be agreed between End User and vendor, the maximum number of acceptable 'outstandings' in any particular category. Again, prior consideration of this is advisable.
N.B. In some cases, users may agree to accept ('sign off') the system subject to a range of conditions. These conditions need to be analysed as they may, perhaps unintentionally, seek additional functionality which could be classified as scope creep. In any event, any and all fixes from the software developers, must be subjected to rigorous System Testing and, where appropriate Regression Testing.


Conclusion
Hence the goal of acceptance testing should verify the overall quality, correct operation, scalability, completeness, usability, portability, and robustness of the functional components supplied by the Software system.

GUI Checklist

User Interface Testing Checklist

1. USER INTERFACE

1.1 COLORS

1.1.1 Are hyperlink colors standard?

1.1.2 Are the field backgrounds the correct color?

1.1.3 Are the field prompts the correct color?

1.1.4 Are the screen and field colors adjusted correctly for non-editable mode?

1.1.5 Does the site use (approximately) standard link colors?

1.1.6 Are all the buttons are in standard format and size?

1.1.7 Is the general screen background the correct color?

1.1.8 Is the page background (color) distraction free?

1.2 CONTENT

1.2.1 All fonts to be the same1.

2.2 Are all the screen prompts specified in the correct screen font?

1.2.3 Does content remain if you need to go back to a previous page, or if you move forward to another new page?

1.2.4 Is all text properly aligned?

1.2.5 Is the text in all fields specified in the correct screen font?

1.2.6 Is all the heading are left aligned

1.2.7 Does the first letter of the second word appears in lowercase? Eg:


1.3 IMAGES

1.3.1 Are all graphics properly aligned?
1.3.2 Are graphics being used the most efficient use of file size?

1.3.3 Are graphics optimized for quick downloads?

1.3.4 Assure that command buttons are all of similar size and shape, and same font & font size.

1.3.5 Banner style & size & display exact same as existing windows

1.3.6 Does text wrap properly around pictures/graphics?

1.3.7 Is it visually consistent even without graphics?


1.4 INSTRUCTIONS

1.4.1 Is all the error message text spelt correctly on this screen?

1.4.2 Is all the micro-help text(i.e tool tip) spelt correctly on this screen?

1.4.3 Microhelp text(i.e tool tip) for every enabled field & button

1.4.4 Progress messages on load of tabbed(active screens) screens

1.5 NAVIGATION

1.5.1 Are all disabled fields avoided in the TAB sequence?

1.5.2 Are all read-only fields avoided in the TAB sequence?

1.5.3 Can all screens accessible via buttons on this screen be accessed correctly?

1.5.4 Does a scrollbar appear if required?

1.5.5 Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.

1.5.6 Is there a link to home on every single page?

1.5.7 On open of tab focus will be on first editable field

1.5.8 When an error message occurs does the focus return to the field in error when the user cancels it?

1.6 USABILITY

1.6.1 Are all the field prompts spelt correctly?

1.6.2 Are fonts too large or too small to read?

1.6.3 Are names in command button & option box names are not abbreviations.

1.6.4 Assure that option boxes, option buttons, and command buttons are logically grouped together in clearly demarcated areas “Group Box”

1.6.5 Can the typical user run the system without frustration?

1.6.6 Do pages print legibly without cutting off text?

1.6.7 Does the site convey a clear sense of its intended audience?

1.6.8 Does the site have a consistent, clearly recognizable “look-&-feel”?

1.6.9 Does User cab Login Member Area with both UserName/Email ID ?

1.6.9 Does the site look good on 640 x 480, 600×800 etc.?

1.6.10 Does the system provide or facilitate customer service? i.e. responsive, helpful, accurate?

1.6.11 Is all terminology understandable for all of the site’s intended users?
Performance & Security Testing Checklist

1. PERFORMANCE

1.1 LOAD

1.1.1 Many users requesting a certain page at the same time or using the site simultaneously

1.1.2 Increase the number of users and keep the data constant

1.1.3 Does the home page load quickly? within 8 seconds

1.1.4 Is load time appropriate to content, even on a slow dial-in connection?

1.1.5 Can the site sustain long periods of usage by multiple users?

1.1.6 Can the site sustain long periods of continuous usage by 1 user?

1.1.7 Is page loading performance acceptable over modems of different speeds?

1.1.8 Does the system meet its goals for response time, throughput, and availability?

1.1.9 Have you defined standards for response time (i.e. all screens should paint within 10 seconds)?

1.1.10 Does the system operate in the same way across different computer and network configurations, platforms and environments, with different mixes of other applications?

1.2 VOLUME

1.2.1 Increase the data by having constant users

1.2.2 Will the site allow for large orders without locking out inventory if the transaction is invalid?

1.2.3 Can the site sustain large transactions without crashing?


1.3 STRESS

1.3.1 Increase both number of users and the data

1.3.2 Performance of memory, CPU, file handling etc.

1.3.3 Error in software, hardware, memory errors (leakage, overwrite or pointers)

1.3.4 Is the application or certain features going to be used only during certain periods of time or will it be used continuously 24 hours a day 7 days a week? Test that the application is able to perform during those conditions. Will downtime be allowed or is that out of the question?

1.3.5 Verify that the application is able to meet the requirements and does not run out of memory or disk space.

1.4 SECURITY

1.4.1 Is confidentiality/user privacy protected?

1.4.2 Does the site prompt for user name and password?

1.4.3 Are there Digital Certificates, both at server and client?

1.4.4 Have you verified where encryption begins and ends?

1.4.5 Are concurrent log-ons permitted?

1.4.6 Does the application include time-outs due to inactivity?

1.4.7 Is bookmarking disabled on secure pages?

1.4.8 Does the key/lock display on status bar for insecure/secure pages?

1.4.9 Is Right Click, View, Source disabled?

1.4.10 Are you prevented from doing direct searches by editing content in the URL?

1.4.11 If using Digital Certificates, test the browser Cache by enrolling for the Certificate and completing all of the required security information. After completing the application and installation of the certificate.

Few Recent Bugs

The technology world has seen many interesting bugs in the past few months, so I thought I would list about a few of my favorites and some lessons learned from each.
1.) Zune Leap Year Bug

On December 31, all 30GB Zune music players failed at the same time. The bug turned out to be a flaw in the date calculation code for leap years, but what made this bug interesting was that it happened on a December 31 and not on a February 29. James Whittaker blogged about the Zune date failure, and one of the conclusions he reaches is that testers need a better way to share tester knowledge and information.

See following link for more details:
http://blogs.msdn.com/james_whittaker/archive/2009/01/06/the-zune-issue.aspx

2.) Canon 5D Mark II Black Dot Bug

The Canon 5D Mark II is a high end SLR camera recently released by Canon for a market of professional photographers and very serious amateurs. It’s the second generation of the 5D - the previous model was considered one of the best digital SLRs on the market. Unfortunately, Canon’s newest camera suffered from a very serious bug - tiny black dots would appear next to highlights (very bright parts of the image). While the dots were small (only a few pixels each on a 21 megapixel camera), the problem was apparent for photographers looking to blow up their images or tightly crop a tiny portion.

Like many bugs, this one was discovered by early adopters. However, the bug was in the pre-release cameras as well, indicating that Canon’s engineers simply missed it. “Many eyes” often see small but important details that are missed during regular testing.

Canon recently released a firmware update fixing this problem.

See following link for more details:
http://forums.dpreview.com/forums/read.asp?forum=1032&message=30264865

3.) Security Flaws: Macrumors and Twitter

Two different sites, but two very similar and serious bugs. In the case of Macrumors, somebody hacked the live feed for their coverage of the MacWorld keynote. Right in the middle of the feed, somebody posing as the site authors posted a message saying that Steve Jobs had died. Macrumors is a very well respected Apple news site, so for a few minutes the world was stunned with the news before it became apparent that the news feed had been compromised. The culprit: an admin control panel that had no authentication.

Twitter had a similar issue - hackers were able to gain control of an admin panel and then hijack the accounts of a 33 celebrities including Barack Obama. Twitter has fixed the issue, but many are wondering if there are other serious issues with the site.

Both of these are very serious bugs, and both show that testing needs to be about security as much as anything else.

See following link for more details:
http://www.techcrunch.com/2009/01/06/when-livestreams-go-wrong/
http://www.techcrunch.com/2009/01/05/twitter-gets-hacked-badly/

Threat Classification

Classes of Attack

Authentication

The Authentication section covers attacks that target a web site's method of validating the identity of a user, service or application. Authentication is performed using at least one of three mechanisms: "something you have", "something you know" or "something you are". This section will discuss the attacks used to circumvent or exploit the authentication process of a web site.

* Brute Force
A Brute Force attack is an automated process of trial and error used to guess a person's username, password, credit-card number or cryptographic key.

* Insufficient Authentication
Insufficient Authentication occurs when a web site permits an attacker to access sensitive content or functionality without having to properly authenticate.

* Weak Password Recovery Validation
Weak Password Recovery Validation is when a web site permits an attacker to illegally obtain, change or recover another user's password.

Authorization

The Authorization section covers attacks that target a web site's method of determining if a user, service, or application has the necessary permissions to perform a requested action. For example, many web sites should only allow certain users to access specific content or functionality. Other times a user's access to other resources might be restricted. Using various techniques, an attacker can fool a web site into increasing their privileges to protected areas.

* Credential/Session Prediction
Credential/Session Prediction is a method of hijacking or impersonating a web site user.

* Insufficient Authorization
Insufficient Authorization is when a web site permits access to sensitive content or functionality that should require increased access control restrictions.

* Insufficient Session Expiration
Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.

* Session Fixation
Session Fixation is an attack technique that forces a user's session ID to an explicit value.

Client-side Attacks

The Client-side Attacks section focuses on the abuse or exploitation of a web site's users. When a user visits a web site, trust is established between the two parties both technologically and psychologically. A user expects web sites they visit to deliver valid content. A user also expects the web site not to attack them during their stay. By leveraging these trust relationship expectations, an attacker may employ several techniques to exploit the user.

* Content Spoofing
Content Spoofing is an attack technique used to trick a user into believing that certain content appearing on a web site is legitimate and not from an external source.

* Cross-site Scripting
Cross-site Scripting (XSS) is an attack technique that forces a web site to echo attacker-supplied executable code, which loads in a user's browser.

Command Execution

The Command Execution section covers attacks designed to execute remote commands on the web site. All web sites utilize user-supplied input to fulfill requests. Often these user-supplied data are used to create construct commands resulting in dynamic web page content. If this process is done insecurely, an attacker could alter command execution.

* Buffer Overflow
Buffer Overflow exploits are attacks that alter the flow of an application by overwriting parts of memory.

* Format String Attack
Format String Attacks alter the flow of an application by using string formatting library features to access other memory space.

* LDAP Injection
LDAP Injection is an attack technique used to exploit web sites that construct LDAP statements from user-supplied input.

* OS Commanding
OS Commanding is an attack technique used to exploit web sites by executing Operating System commands through manipulation of application input.

* SQL Injection
SQL Injection is an attack technique used to exploit web sites that construct SQL statements from user-supplied input.

* SSI Injection
SSI Injection (Server-side Include) is a server-side exploit technique that allows an attacker to send code into a web application, which will later be executed locally by the web server.

* XPath Injection
XPath Injection is an attack technique used to exploit web sites that construct XPath queries from user-supplied input.

Information Disclosure

The Information Disclosure section covers attacks designed to acquire system specific information about a web site. System specific information includes the software distribution, version numbers, and patch levels. Or the information may contain the location of backup files and temporary files. In most cases, divulging this information is not required to fulfill the needs of the user. Most web sites will reveal a certain amount of data, but it's best to limit the amount of data whenever possible. The more information about the web site an attacker learns, the easier the system becomes to compromise.

* Directory Indexing
Automatic directory listing/indexing is a web server function that lists all of the files within a requested directory if the normal base file is not present.

* Information Leakage
Information Leakage is when a web site reveals sensitive data, such as developer comments or error messages, which may aid an attacker in exploiting the system.

* Path Traversal
The Path Traversal attack technique forces access to files, directories, and commands that potentially reside outside the web document root directory.

* Predictable Resource Location
Predictable Resource Location is an attack technique used to uncover hidden web site content and functionality.


Logical Attacks

The Logical Attacks section focuses on the abuse or exploitation of a web application's logic flow. Application logic is the expected procedural flow used in order to perform a certain action. Password recovery, account registration, auction bidding, and eCommerce purchases are all examples of application logic. A web site may require a user to correctly perform a specific multi-step process to complete a particular action. An attacker may be able to circumvent or misuse these features to harm a web site and its users.

* Abuse of Functionality
Abuse of Functionality is an attack technique that uses a web site's own features and functionality to consume, defraud, or circumvents access controls mechanisms.

* Denial of Service
Denial of Service (DoS) is an attack technique with the intent of preventing a web site from serving normal user activity.

* Insufficient Anti-automation
Insufficient Anti-automation is when a web site permits an attacker to automate a process that should only be performed manually.

* Insufficient Process Validation
Insufficient Process Validation is when a web site permits an attacker to bypass or circumvent the intended flow control of an application.