Note for Software Testing - ST By JNTU Heroes

Topics ( 10 )

Text from page-1

LECTURE NOTES ON SOFTWARE TESTING METHODOLOGIES III B. Tech II semester (JNTUH-R13)

Text from page-2

UNIT- I INTRODUCTION What is testing? Testing is the process of exercising or evaluating a system or system components by manual or automated means to verify that it satisfies specified requirements. The Purpose of Testing Testing consumes at least half of the time and work required to produce a functional program. o MYTH: Good programmers write code without bugs. (It’s wrong!!!) o History says that even well written programs still have 1-3 bugs per hundred statements. Productivity and Quality in Software: o o o o o o o o In production of consumer goods and other products, every manufacturing stage is subjected to quality control and testing from component to final stage. If flaws are discovered at any stage, the product is either discarded or cycled back for rework and correction. Productivity is measured by the sum of the costs of the material, the rework, and the discarded components, and the cost of quality assurance and testing. There is a tradeoff between quality assurance costs and manufacturing costs: If sufficient time is not spent in quality assurance, the reject rate will be high and so will be the net cost. If inspection is good and all errors are caught as they occur, inspection costs will dominate, and again the net cost will suffer. Testing and Quality assurance costs for 'manufactured' items can be as low as 2% in consumer products or as high as 80% in products such as space-ships, nuclear reactors, and aircrafts, where failures threaten life. Whereas the manufacturing cost of software is trivial. The biggest part of software cost is the cost of bugs: the cost of detecting them, the cost of correcting them, the cost of designing tests that discover them, and the cost of running those tests. For software, quality and productivity are indistinguishable because the cost of a software copy is trivial. Testing and Test Design are parts of quality assurance should also focus on bug prevention. A prevented bug is better than a detected and corrected bug.

Text from page-3

Phases in a tester's mental life: Phases in a tester's mental life can be categorized into the following 5 phases: 1. Phase 0: (Until 1956: Debugging Oriented) There is no difference between testing and debugging. Phase 0 thinking was the norm in early days of software development till testing emerged as a discipline. 2. Phase 1: (1957-1978: Demonstration Oriented) the purpose of testing here is to show that software works. Highlighted during the late 1970s. This failed because the probability of showing that software works 'decreases' as testing increases. I.e. the more you test, the more likely you will find a bug. 3. Phase 2: (1979-1982: Destruction Oriented) the purpose of testing is to show that software doesn’t work. This also failed because the software will never get released as you will find one bug or the other. Also, a bug corrected may also lead to another bug. 4. Phase 3: (1983-1987: Evaluation Oriented) the purpose of testing is not to prove anything but to reduce the perceived risk of not working to an acceptable value (Statistical Quality Control). Notion is that testing does improve the product to the extent that testing catches bugs and to the extent that those bugs are fixed. The product is released when the confidence on that product is high enough. (Note: This is applied to large software products with millions of code and years of use.) 5. Phase 4: (1988-2000: Prevention Oriented) Testability is the factor considered here. One reason is to reduce the labor of testing. Other reason is to check the testable and non-testable code. Testable code has fewer bugs than the code that's hard to test. Identifying the testing techniques to test the code is the main key here. Test Design: We know that the software code must be designed and tested, but many appear to be unaware that tests themselves must be designed and tested. Tests should be properly designed and tested before applying it to the actual code. Testing isn’t everything: There are approaches other than testing to create better software. Methods other than testing include: Inspection Methods: Methods like walkthroughs, desk checking, formal inspections and code reading appear to be as effective as testing but the bugs caught don’t completely overlap. 2. Design Style: While designing the software itself, adopting stylistic objectives such as testability, openness and clarity can do much to prevent bugs. 3. Static Analysis Methods: Includes formal analysis of source code during compilation. In earlier days, it is a routine job of the programmer to do that. Now, the compilers have taken over that job. 4. Languages: The source language can help reduce certain kinds of bugs. Programmers find new bugs while using new languages. 1.

Text from page-4

5. Development Methodologies and Development Environment: The development process and the environment in which that methodology is embedded can prevent many kinds of bugs. Dichotomies:  Testing Versus Debugging: Many people consider both as same. Purpose of testing is to show that a program has bugs. The purpose of testing is to find the error or misconception that led to the program's failure and to design and implement the program changes that correct the error. Debugging usually follows testing, but they differ as to goals, methods and most important psychology. The below tab le shows few important differences between testing and debugging. Testing Debugging Testing starts with known conditions, Debugging starts from possibly unknown uses predefined procedures and has initial conditions and the end cannot be predictable outcomes. predicted except statistically. Testing can and should be planned, designed and scheduled. Procedure and duration of debugging cannot be so constrained. Testing is a demonstration of error or apparent correctness. Debugging is a deductive process. Testing proves a programmer's failure. Debugging is the programmer's vindication (Justification). Testing, as executes, should strive to be Debugging demands intuitive predictable, dull, constrained, rigid and experimentation and freedom. inhuman. leaps, Much testing can be done without design knowledge. Debugging is impossible without detailed design knowledge. Testing can often be done by an outsider. Debugging must be done by an insider. Much of test execution and design can be automated. Automated debugging is still a dream.  Function versus Structure: o o Tests can be designed from a functional or a structural point of view. In Functional testing, the program or system is treated as a black box. It is subjected to inputs, and its outputs are verified for conformance to specified behavior. Functional testing takes the user point of view- bother about functionality and features and not the program's implementation.