Software Testing: Testing software is operating the software under controlled conditions, to (1) verify that it behaves as specified;

(2) to detect errors, and (3) to validate that what has been specified is what the user actually wanted. 1. Verification is the checking or testing of items, including software, for conformance and consistency by evaluating the results against pre-specified requirements. [Verification: Are we building the system right?] 2. Error Detection: Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldnt or things dont happen when they should. 3. Validation looks at the system correctness i.e. is the process of checking that what has been specified is what the user actually wanted. [Validation: Are we building the right system?] In other words, validation checks to see if we are building what the customer wants/needs, and verification checks to see if we are building that system correctly. Both verification and validation are necessary, but different components of any testing activity. Verification :it is the process of confirming that s/w "meets its specification" Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; Validation: It is the process of confirming that it "meets the user's requirements". Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; Validation typically involves actual testing and take place after verification are Completed.

The definition of testing according to the ANSI/IEEE 1059 standard is that testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item.

Error: Error or mistake is a human action that produces wrong or incorrect result. Defect (Bug, Fault): A flaw in the system or a product that can cause the component to fail or misfunction.

A test case is a set of conditions used by the tester to test if the requirements have been met by the software. Testing Objectives: Glen Myers states a number of rules that can serve well as testing objectives:

Testing is a process of executing a program with the intent of finding an error. A good test case is one that has a high probability of finding an as-yetundiscovered error. A successful test is one that uncovers an as-yet-undiscovered error.

Software testing is performed to verify that the completed software package functions according to the expectations defined by the requirements/specifications. The overall objective is not to find every software bug that exists, but to uncover situations that could negatively impact the customer, usability and/or maintainability. Testing is checking the correctness, completeness, quality and security of the software developed. Testing is one of the important phase of software development which makes the software development team to improve the quality of the software. After each phase of the software development, testing is done to ensure the quality. Testing allows developers to deliver software that: Meets expectations Prevents unexpected results Improves the long term maintenance of the application. Testing Principles: Davis suggests a set of testing principles. They are:

All tests should be traceable to customer requirements Tests should be planned long before testing begins. o Feasibility phase Advantage: Early test estimates help determine overall product feasibility o Analysis phase Advantage: Identify requirements that might not be testable o Development phase Advantage: Early product experience helps finalize test strategies.

The Pareto principle applies to software testing. o The Pareto principle (also known as the 80-20 rule) states that, for many events, roughly 80% of the effects come from 20% of the causes o Originally, the Vilfredo Pareto Principle referred to the observation that 80% of Italys wealth belonged to only 20% of the population. o More generally, the Pareto Principle is the observation (not law) that most things in life are not distributed evenly o A principle, named after economist Vilfredo Pareto, that specifies an unequal relationship between inputs and outputs. The principle states that, for many phenomena, 20% of invested input is responsible for 80% of the results obtained o So what is Pareto Principle It states that 80 percent of the uncovered errors in testing is from the 20 percent of the software components.

20% of the bugs cause 80% of the crashes

Testing should begin in the small and progress toward testing in the large. Testing should begin by focusing on testing the individual program components to the integrated clustered components. Exhaustive testing is not possible. o According to Davis, testing of all possible combinations is impossible as each combination leads to a different path, but it is possible to test all the logic statements and also check that all conditions in the component level design have been tested. To be most effective, testing should be conducted by an independent third party. o The testing should be done by a third party. The software engineers who create the software is not the best person for testing the software. That is why we have testing teams to test the software.

Test Characteristics: (attributes of a good test.) 1. A good test has a high probability of finding an error. To achieve this goal, the tester must understand the software and attempt to develop a mental picture of how the software might fail 2. A good test is not redundant. Testing time and resources are limited. There is no point in conducting a test that has the same purpose as another test. Every test should have a different purpose (even if it is subtly different). 3. A good test should be best of breed. In a group of tests that have a similar intent, time and resource limitations may mitigate toward the execution of only a subset of these tests. In such cases, the test that has the highest likelihood of uncovering a whole class of errors should be used. When to stop testing? Testing is potentially endless. We can not test till all the defects are unearthed and removed -- it is simply impossible. At some point, we have to stop testing and ship the software. The question is when. Realistically, testing is a trade-off between budget, time and quality. It is driven by profit models. The pessimistic and unfortunately most often used approach is to stop testing whenever some or any of the allocated resources -- time, budget, or test cases -- are exhausted. The optimistic stopping rule is to stop testing when either reliability meets the requirement, or the benefit from continuing testing cannot justify the testing cost. [Yang95] This will usually require the use of reliability models to evaluate and predict reliability of the software under test. Each evaluation requires repeated running of the following cycle: failure data gathering -- modeling -- prediction. This method does not fit well for ultra-dependable systems, however, because the real field failure data will take too long to accumulate.