Downloaded 20 times
More Related Content
Similar to Software Testing Introduction
Software Testing Introduction
- 1. Software Testing -Introduction N Arun Kumar 1st MSc(Computer Science) Don Bosco College, Yelagiri hills. 3/26/2018 1
- 2. Outline • Software Engineering •SDLC • Phases of SDLC • Testing – Goals of Testing – Test Design – Pesticide-paradox and complexity barrier – Dichotomies – Model for testing – Testing and levels – Is complete testing possible? 3/26/2018 2
- 3. Software Engineering • Software: Collectionof executable programming code, associated libraries and documentations • Engineering: developing products, using well-defined, scientific principles and methods. 3/26/2018 3
- 4. Software Engineering • Asystematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. • Goals: – to improve the quality of software products – to increase the productivity and job satisfaction of software engineers. 3/26/2018 4
- 5. SDLC • Software DevelopmentLife Cycle – is a well-defined, structured sequence of stages in software engineering to develop the intended software product – Variety of SDLC model are available now a days such as Waterfall model, Prototype model, Agile model, etc. which makes the development of software very easy. 3/26/2018 5
- 6. Phases in SDLC •Problem Definition • Requirement Analysis • Planning • Design • Implementation • Testing • Deployment • Maintenance 3/26/2018 6
- 7. Testing • Software testingis a process of executing a program or application with the intent of finding the software bugs. • It can also be stated as the process of validating and verifying that a software program or application or product: Meets the business and technical requirements that guided it's design and development. 3/26/2018 7
- 8. Goals of Testing •Primary Goal: – Bug prevention • A prevented bug is better than the detected and corrected bug because if the bug is prevented there’s no code to correct • Secondary Goal: – Bug Discovery 3/26/2018 8
- 9. Test Design • Insteadof “ design, code, desk check, test, and debug” the programming process should be described as “design, test design, code, test code, program inspection, test inspection, test debugging, test execution, program debugging, testing”. 3/26/2018 9
- 10. Pesticide Paradox andComplexity Barrier • First Law: The Pesticide Paradox – Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. • Second Law: Complexity Barrier – Software complexity grows to the limits of our ability to manage that complexity. 3/26/2018 10
- 11. Dichotomies • Testing vsDebugging Testing Debugging 1. Purpose: to show that a program has bugs. find the error or misconception that led to the programs failure starts with known conditions and has predictable outcomes starts from possibly unknown initial conditions and the end cannot be predicted Testing can and should be planned, designed and scheduled Debugging cannot be so constrained Testing can often be done by an outsider Debugging must be done by an insider Testing can be done without design knowledge Debugging is impossible without detailed design knowledge 3/26/2018 11
- 12. Cont… • Function vsStructure Function Structure It takes the user point of view- bother about functionality and features and not the programs implementation It looks at the implementation details 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 behaviour Things such as programming style, control method, source language, database design, and coding details dominate structural testing. 3/26/2018 12
- 13. Cont… • Designer vsTester – Tester is actually one who tests the code whereas designer is the person one who designs the test. – During functional testing, the designer and tester are probably different persons. During unit testing, the tester and the programmer merge into one person 3/26/2018 13
- 14. Cont… • Modularity vsEfficiency – A module is a discrete, well-defined, small component of a system. – Smaller the modules, difficult to integrate; larger the modules, difficult to understand. Both tests and systems can be modular. – Testing can and should likewise be organised into modular components. – Small, independent test cases can be designed to test independent modules. 3/26/2018 14
- 15. Cont… • Small vsLarge – Programming in the large, means constructing programs that consists of many components written by many different programmers – Programming in the small, is what we do for ourselves in the privacy of our own offices 3/26/2018 15
- 16. Cont… • Builder vsBuyer – Builder: who designs the system and is accountable to the buyer Buyer: who pays for the system in the hope of profits from providing services User: Ultimate beneficiary or victim of the system, The users interests are also guarded by Tester: Who is dedicated to the builders destruction 3/26/2018 16
- 17.
- 18. Cont… • Three models: –Model of the environment – Model of the program – Model of the expected bugs 3/26/2018 18
- 19. Cont… • Environment – Hardwareand the software required to make it run – Example: Operating System, Compiler, utility – Its not smart to blame the environment for bugs. 3/26/2018 19
- 20. Cont… • Program: – Ifthe simple model of the program does not explain the unexpected behavior, we may have to modify that model to include more facts and details. – And if that fails, we may have to modify the program. 3/26/2018 20
- 21. Testing and Levels Thereare three distinct kinds of testing on a typical software system: 1. Unit/Component Testing 2. Integration Testing 3. System Testing 3/26/2018 21
- 22. Cont… • Unit Testing –set of tests performed by an individual programmer prior to integration of the unit into a larger system. – Kinds of unit testing:- • Functional tests • Performance tests • Stress tests • Structure tests(black box or glass box testing) 3/26/2018 22
- 23. Cont… • Integration Testing –Integration is the process by which components are aggregated to created larger components – It checks if the combination of components are incorrect or inconsistent – It verifying software quality by testing two or more dependent software modules as a group 3/26/2018 23
- 24. Cont… • System testing –A system is a big component – It includes testing for performance, security, accountability, configuration sensitivity, startup and recovery – System testing enables us to test, verify and validate both the business requirements as well as the applications architecture 3/26/2018 24
- 25. Is Complete TestingPossible? • According to Manna and Waldinger – “We can never be sure that the specifications are correct” – “No verification system can verify every correct program” – “We can never be certain that a verification system is correct” 3/26/2018 25
- 26.