Software testing is a process used to identify the correctness, completeness and quality of developed computer software. Actually, testing can never establish the correctness of computer software, as this can only be done by formal verification. It can only find defects, not prove that there are none. There are a number of different testing approaches that are used to do this ranging from the most informal ad hoc testing, to formally specified and controlled methods such as automated testing.

Click here to see the Software Testing Life Cycle - Prepared by Natarajan S.

Winrunner Vs Quick Test Professional

Classic Testing Mistakes

Period of time beginning when a software product is conceived and ending when the product is no longer available for use. The software life cycle is typically broken into phases denoting activities such as requirements, design, programming, testing, installation, and operation and maintenance. Contrast with software development process

Some Good Websites and Groups for Testing :

How to write a bug report :

1.   Be very specific when describing the bug.  Don't let there be any room for interpretation.  More concise means less ambiguous, so less clarification will be needed later on.

2.  Calling windows by their correct names (by the name displayed on the title bar) will eliminate some ambiguity.

3.  Don't be repetitive. Don't repeat yourself.  Also, don't say things twice or three times.

4.  Try to limit the number of steps to recreate the problem.  A bug that is written with 7 or more steps can usually become hard to read.  It is usually possible to shorten that list.

5.  Start describing with where the bug begins, not before.  For example, you don't have to describe how to load and launch the application if the application crashes on exit.

6.  Proofreading the bug report is very important. Send it through a spell checker before submitting it.

7.  Make sure that all step numbers are sequenced. (No missing step numbers and no duplicates.)

8.  Please make sure that you use sentences.  This is a sentence. This not sentence.

9.  Don't use a condescending or negative tone in your bug reports.  Don't say things like "It's still broken", or  "It is completely wrong".

10.  Don't use vague terms like "It doesn't work" or "not working properly"

11.  If there is an error message involved, be sure to include the exact wording of the text in the bug report.  If there is a GPF (General Protection Fault) be sure to include the name of the module and address of the crash.

12.  Once the text of the report is entered, you don't know whose eyes will see it.  You might think that it will go to your manager and the developer and that's it, but it could show up in other documents that you are not aware of, such as reports to senior management or clients, to the company intranet, to future test scripts or test plans.  The point is that the bug report is your work product, and you should take pride in your work.

Overview of Bugs :

No matter what a system does, what language it’s written in, what platform it’s run on, whether it’s client/server based or not  its basic functions are the same.  They are broken down into the following categories:

            Entry

            Storage

            Output

            Process

As the interaction between data and the system increases usually so does the severity of the bug, and the detail needed in a report.

Bug severity can be categorized as follows:

            Cosmetic

            Inconvenience

            Loss of Function

            System crash or hang

            Loss of Data

Cosmetic bugs are the simplest bugs to report, and affect the system the least.  They are simply instances where things look wrong.  Spelling errors, screen anomalies these are cosmetic bugs.

Bugs that are classified as an inconvenience are just that, something that makes the system harder to use.  These are slightly more nebulous since part of their effect is subjective.  This also makes it harder to describe what the actual problem is.

When a bug results in a loss of function, reporting becomes a bit more complicated and the urgency to fix the bug is greater.  These bugs do not affect the data, but it means that a process is useless until it is fixed.  Because of this, the report again becomes more complicated.

Bugs that cause the system to crash or hang can be the hardest to reproduce, and therefore the hardest to adequately describe.  If you experience a crash or hang in testing, it is imperative to see if you can reproduce the problem, documenting all the steps taken along the way.  On these occasions, it is also important to include the data used in causing the system to crash/hang.

The final classification is the worst bugs that result in the loss of data.  Data is the heart of almost every system, and anything that threatens the integrity of that data must be fixed as quickly as possible.  Therefore more than any other bug type it must be documented as thoroughly as possible.

Web sites are essentially client/server applications - with web servers and 'browser' clients. Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.). Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort. Other considerations might include:
What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
Will down time for server and content maintenance/upgrades be allowed? how much?
What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
How reliable are the site's Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?
What processes will be required to manage updates to the web site's content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??
How will internal and external links be validated and updated? how often?
Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet 'traffic congestion' problems to be accounted for in testing?
How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?
How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
Some sources of site security information include the Usenet newsgroup 'comp.security.announce' and links concerning web site security in the 'Other Resources' section.
Some usability guidelines to consider - these are subjective and may or may not apply to a given situation (Note: more information on usability testing issues can be found in articles about web site usability in the 'Other Resources' section):
Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within the page.
The page layouts and design elements should be consistent throughout a site, so that it's clear to the user that they're still within a site.
Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type.
All pages should have links external to the page; there should be no dead-end pages.
The page owner, revision date, and a link to a contact person or organization should be included on each page