Software Testing

Software Testing

• 1.
  Software Testing By –Ravina Jeswani
• 2.
  Definition of Testing:  Software testing is a process, to evaluate the functionality of a software application with an intent to find whether the developed software met the specified requirements or not and to identify the defects to ensure that the product is defect-free in order to produce a quality product.  According to ANSI/IEEE 1059 standard – A process of analyzing a software item to detect the differences between existing and required conditions (i.e., defects) and to evaluate the features of the software item.
• 3.
  Introduction  Meaning oftesting : Intention to find errors  In short testing is = Verification + Validation  Testing is part of a broader process of software verification and validation (V & V). Verification and validation are not the same thing, although they are often confused.  Verification : Meeting Business Requirements.  Validation : Meeting User’s Requirements(Customer’s Requirements)  Testing can only show the presence of errors.
• 4.
  Introduction :  Softwaretesting involves the execution of a software component or system component to evaluate one or more properties of interest. In general, these properties indicate the extent to which the component or system under test: • meets the requirements that guided its design and development, • responds correctly to all kinds of inputs, • performs its functions within an acceptable time, • is sufficiently usable, • can be installed and run in its intended environment. • achieves the general result its stakeholders desire.
• 5.
  Introduction : A primarypurpose of testing is to detect software failures so that defects may be discovered and corrected. Target of the test are -  Errors - These are actual coding mistakes made by developers. In addition, there is a difference in output of software and desired output, is considered as an error.  Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an error which can cause system to fail.  Failure - failure is said to be the inability of the system to perform the desired task. Failure occurs when fault exists in the system.
• 6.
  Testing Objectives : Glen Myers states a number of rules that can serves 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 the high probability of finding an as-yet- undiscovered error.  A successful test is one that uncovers an as-yet-undiscovered error.  Objectives : o To check whether software which builds, it is as per the requirement or not. o Finding defects from the software before customers find them out. o Defects get a fix from the developer. o Preventing defects. o Gaining confidence about the level of quality.
• 7.
  Characteristics of SoftwareTest : There are several tests (such as unit and integration) used for testing the software. Each test has its own characteristics. The following points, however, should be noted. • High probability of detecting errors: To detect maximum errors, the tester should understand the software thoroughly and try to find the possible ways in which the software can fail. For example, in a program to divide two numbers, the possible way in which the program can fail is when 2 and 0 are given as inputs and 2 is to be divided by 0. In this case, a set of tests should be developed that can demonstrate an error in the division operator. • No redundancy: Resources and testing time are limited in software development process. Thus, it is not beneficial to develop several tests,
• 8.
  • Choose themost appropriate test: There can be different tests that have the same intent but due to certain limitations such as time and resource constraint, only few of them are used. In such a case, the tests, which are likely to find more number of errors, should be considered. • Moderate: A test is considered good if it is neither too simple, nor too complex. Many tests can be combined to form one test case. However this can increase the complexity and leave many errors undetected. Hence, all tests should be performed separately.
• 9.
  Documentation :  Testplan – strategy throughout the software development.  Test scenario - one line statement that notifies what area in the application will be tested.  Test case – input -> action -> output  Traceability matrix – requirement tm (RTM)
• 10.
  Davis suggests aset of Testing Principles :  Principle 1. All tests should be traceable to customer requirements. The objective of software testing is to uncover errors. It follows that the most severe defects (from the customer’s point of view) are those that cause the program to fail to meet its requirements.  Principle 2. Tests should be planned long before testing begins. Test planning can begin as soon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified. Therefore, all tests can be planned and designed before any code has been generated.  Principle 3. The Pareto principle applies to software testing. In this context the Pareto principle implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem is to isolate these 20 percent modules and test them
• 11.
   Principle 4.Testing should begin “in the small” and progress toward testing “in the large”. The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system.  Principle 5. Exhaustive testing is not possible. The number of path permutations for even a moderately sized program is exceptionally large. For this reason, it is impossible to execute every combination of paths during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions in the component-level design have been exercised.  Principle 6. Apply to each module in the system a testing effort compatible with its expected fault density. These are often the newest modules or the ones that are least understood by the developers.
• 12.
   Principle 7.Static testing techniques can yield high results. More than 85% of software defects originated in the software documentation (requirements, specifications, code walkthroughs, and user manuals). There may be value in testing the system documentation.  Principle 8. Track defects and look for patterns in defects uncovered by testing. The total defects uncovered is a good indicator of software quality. The types of defects uncovered can be a good measure of software stability. Patterns of defects found over time can forecast numbers of expected defects.  Principle 9. Include test cases that demonstrate software is behaving correctly. As software components are being maintained or adapted, unexpected interactions cause unintended side effects in other components. It is important to have a set of regression test cases ready to check system behavior after changes are applied to a software product.
• 13.
  Testability : The easewith which a program is tested is known as testability. Testability should always be considered while signing and implementing a software system so that the errors (if any) in the system can be detected with minimum effort. There are several characteristics of testability, which are listed below. 1. Easy to operate: High quality software can be tested in a better manner. This is because if the software is designed and implemented considering quality, then comparatively fewer errors will be detected during the execution of tests. 2. Stability: Software becomes stable when changes made to the software are controlled and when the existing tests can still be performed.
• 14.
  Testability : 3. Observability:Testers can easily identify whether the output generated for certain input is accurate simply by observing it. 4. Easy to understand: Software that is easy to understand can be tested in an efficient manner. Software can be properly understood by gathering maximum information about it. For example, to have a proper knowledge of the software, its documentation can be used, which provides complete information of the software code thereby increasing its clarity and making the testing easier. 5. Decomposability: By breaking software into independent modules, problems can be easily isolated and the modules can be easily tested.
• 16.
  Thank You