Introduction

Software testing is a critical element of software quality assurance and represents the ultimate process to ensure the correctness of the product. The quality product always enhances the customer confidence in using the product thereby increases the business economics. In other words, a good quality product means zero defects, which is derived from a better quality process in testing.

Software is an integrated set of Program codes, designed logically to implement a particular function or to automate a particular process. To develop a software product or project, user needs and constraints must be determined and explicitly stated. The development process is broadly classified into two.

1. Product development

2. Project development

Product development is done assuming a wide range of customers and their needs. This type of development involves customers from all domains and collecting requirements from many different environments.

Project Development is done by focusing a particular customer’s need, gathering data from his environment and bringing out a valid set of information that will help as a pillar to development process.

Software Testing World

Testing is a necessary stage in the software life cycle: it gives the programmer and user some sense of correctness, though never “proof of correctness. With effective testing techniques, software is more easily debugged, less likely to “break,” more “correct”, and, in summary, better.

Most Software Development processes in the IT industry always seem to follow a tight schedule. Often, these schedules adversely affect the testing process, resulting in step motherly treatment meted out to the testing process. As a result, defects accumulate in the application and are overlooked so as to meet deadlines. The developers convince themselves that the overlooked errors can be rectified in subsequent releases.

The definition of testing is not well understood. People use a totally incorrect definition of the word testing, and that this is the primary cause for poor program testing.

Testing the product means adding value to it by raising the quality or reliability of the product. Raising the reliability of the product means finding and removing errors. Hence one should not test a product to show that it works; rather, one should start with the assumption that the program contains errors and then test the program to find as many of the errors as possible.

Definitions of Testing:

“Testing is the process of executing a program with the intent of finding errors ”

                                                            Or

“Testing is the process of evaluating a system by manual or automatic means and verify that it satisfies specified requirements”

                                                            Or

“… the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements or to identify differences / between expected and actual results…”

Why  software Testing?

 Software testing helps to deliver quality software products that satisfy user’s requirements, needs and expectations. If done poorly,

Ø defects are found during operation,

Ø  it results in high maintenance cost and user dissatisfaction

Ø It may cause mission failure

Ø Impact on operational performance and reliability

Software Bug: A Formal Definition

Calling any and all software problems bugs may sound simple enough, but doing so hasn’t really addressed the issue. To keep from running in circular definitions, there needs to be a definitive description of what a bug is.

A software bug occurs when one or more of the following five rules is true:

1) The software doesn’t do something that the product specification says it should do.

2) The software does something that the product specification says it shouldn’t do.

3) The software does something that the product specification doesn’t mention.

4) The software doesn’t do something that the product specification doesn’t mention but should.

5) The software is difficult to understand, hard to use, slow, or –in the software tester’s eyes- will be viewed by the end user as just plain not right.

What exactly does Software Tester Do? (Or Role of Tester)

From the above Examples you have seen how nasty bugs can be and you know what is the definition of a bug is, and you can think how costly they can be. So main goal of tester is

“The goal of Software Tester is to find bugs”

As a software tester you shouldn’t be content at just finding bugs, you should think about how to find them sooner in the development process, thus making them cheaper to fix.

“The goal of a Software Tester is to find bugs, and find them as early as possible”.

  But, finding bugs early isn’t enough

“The goal of a Software Tester is to find bugs, and find them as early as possible and make sure they get fixed”

 Eight Basic Principles of Testing

. Define the expected output or result.

· Don’t test your own programs.

· Inspect the results of each test completely.

· Include test cases for invalid or unexpected conditions.

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

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

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

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

Software Testing Terms and Definitions

Verification &  Validation

Verification and validation are often used interchangeably but have different definitions. These differences are important to software testing.

Verification is the process confirming that software meets its specifications.

 Validation is the process confirming that it meets the user’s requirements.

Verification can be conducted through Reviews. Quality reviews provides visibility into the development process throughout the software development life cycle, and help teams determine whether to continue development activity at various checkpoints or milestones in the process. They are conducted to identify defects in a product early in the life cycle.

Types of Reviews

In-process Reviews :-

They look at the product during a specific time period of life cycle, such as during the design activity. They are usually limited to a segment of a project, with the goal of identifying defects as work progresses, rather than at the close of a phase or even later, when they are more costly to correct.

· Decision-point or phase-end Reviews: –

This type of review is helpful in determining whether to continue with planed activities or not. They are held at the end of each phase.

· Post implementation Reviews: –

These reviews are held after implementation is complete to audit the process based on actual results. Post-implementation reviews are also know as “ Postmortems”, and are held to assess the success of the overall process after release and identify any opportunities for process improvements.

Classes of Reviews

· Informal or Peer Review: –

In this type of review generally a one-to one meeting between the author of a work product and a peer, initiated as a request for input regarding a particular artifact or problem. There is no agenda, and results are not formally reported. These reviews occur as need-based through each phase of a project.

· Semiformal or Walkthrough Review: –

The author of the material being reviewed facilitates this. The participants are led through the material in one of the two formats: the presentation is made without interruptions and comments are made at the end, or comments are made throughout. Possible solutions for uncovered defects are not discussed during the review.

· Formal or Inspection Review: –

An inspection is more formalized than a ‘walkthrough’, typically with 3-8 people including a moderator, reader, and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what’s missing, not to fix anything.

Attendees should prepare for this type of meeting by reading thru the document; most problems will be found during this preparation. The result of the inspection meeting should be a written report. Thorough preparation for inspections is difficult, painstaking work, but is one of the most cost effective methods of ensuring quality.

Three rules should be followed for all reviews:

The product is reviewed, not the producer.

  1. Defects and issues are identified, not corrected.
  2. All members of the reviewing team are responsible for the results of the review.