1. TESTING IN THE SOFTWARE LIFE CYCLE &TEST LEVELS Chapter 2 1/11/2018 1

2. Contents to be covered 1. Review of Software Development Models ( Water Fall Model, W Model, V Model) 2. Test Levels 1. Component Testing, Integration Testing, System Testing, Acceptance Testing 3. Generic types- 1. Functional, Non Functional, testing software structure, Regression Testing. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 2

3. General V-model  The main idea behind the general V-model is that development tasks and testing tasks are corresponding activities of equal importance.  The two branches of the letter "V" symbolize this.  The left branch represents the development process. During the development process the system is gradually being designed, and then programming is the final step.  The right branch represents the integration and testing process, in which the program elements are successively being assembled to form bigger subsystems (integration), and where their functionality is tested. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 3

4. General V-model 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 4 Figure 3-1. General V-model

5. General V-model : Constructive Activities  The constructive activities of the left branch are the activities we know from the Waterfall-model: 1.Requirements specification:  The needs and requirements of the customer or the future system user are gathered, specified, and finally approved.  The purpose of the system and the desired characteristics and features are defined. 2.Functional system design:  The requirements are mapped onto functions and dialogues of the new system. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 5

6. Constructive Activities 3.Technical system design:  The implementation of the system is designed.  This includes the definition of interfaces to the system environment and the decomposition of the system into smaller understandable subsystems (system architecture).  Each subsystem can be developed independently. 4.Component specification:  Each subsystem, including its task, behavior, inner structure, and interfaces to other subsystems, is defined. 5.Programming:  Each specified component (module, unit, class) is implemented in a programming language. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 6

7. Test Level For Each Construction Level 1. Component test verifies whether each software component performs correctly according to its specification. 2. Integration test checks if groups of components collaborate in the way that is specified by the technical system design. 3. System test verifies whether the system as a whole meets the specified requirements. 4. Acceptance test checks if the system meets the requirements, as specified in the contract, from the customers point of view. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 7

8. Validation  The process of checking the development results according to their original requirements is called validation. Are we building the right system?  During validation the tester judges whether a product (or a part of the product) solves its task, and suitable for its intended use. To validate: to affirm, to declare as valid, to check if something is valid 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 8

9. Verification The v-model also requires verification testing. To verify: to prove, to inspect.  Verification refers to only one single phase of the development process.  Verification shall assure that the outcome of a particular development phase has been achieved correctly and completely, according to its specification. Are we building the system right?  It is examined as to whether specifications are correctly implemented and the product meets its specification, but not the resulting product is suitable for its intended use. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 9

10. Characteristics of the general V- model V-Model evolved from waterfall Model. Each phase must be completed before the next phase begins. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. Testing is emphasized in this model more than in the waterfall model. It is a structured approach to testing. Brings high quality into the development of our products 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 10

11. Characteristics of the general V- model Implementation activities and testing activities are separated, but are equally important (left side / right side). The "V" illustrates the testing aspects of Verification and Validation. We distinguish between different test levels where each test level is testing "against" its corresponding development level. The tests on the right branch of the model shall be interpreted as the levels of test execution. Test preparation (test planning and control, and test analysis and design) starts earlier and is performed in parallel to the development phases on the left branch. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 11

12. Test Levels 1. Unit, Component, Module 2. Integration, 3. System, 4. Acceptance, 5. Generic types 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 12

13. Component Test  Def: The testing of a single software component is called component testing.  The most ‘micro’ scale of testing.  Tests done on particular functions or code modules.  Requires knowledge of the internal program design and code.  Done by Programmers (not by testers).  1.Test Objects:  The software components are tested individually and isolated from all other software components of the system.  The isolation is necessary to prevent external influences on components. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 13

14. Component Test  2.Test Environment:  Component testing as the lowest test level deals with test objects coming "directly from the developer's desk".  Test Drivers are needed.  In order to write suitable test drivers  The knowledge of the component is necessary.  The test object's program code must be available& understood by the tester.  The tester must know the programming language and suitable programming tools must be at hand.  Tools : Debugger, Code Analyzers Path/statement coverage tools. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 14

15. Component Test  3.Test Objectives:  To test the function of a program or unit of code such as a program or module  To test internal logic & verify internal design  To test path & conditions coverage  To test exception conditions & error handling :  When: After modules are coded.  Who: Developer  4.Test Strategy:  White Box Testing Techniques  Test Coverage Techniques 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 15

16. Integration Testing  Def: Testing of combined parts of an application to determine their functional correctness.  1.Test Objects:  Code modules  Individual applications  Client/server applications on a network.  2.Environment  Reuse of the testing environment  Need for monitors  3.Test Objectives: To technically verify proper interfacing between modules, and within sub-systems. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 16

17. Integration Testing  When: After modules are unit tested  Integration Strategies  Top Down Integration testing  Bottom Up Integration testing  Ad hoc integration  Backbone integration strategy  Big Bang testing  Tools:  Debug  Re-structure  Code Analyzers 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 17

18. System Test  Def: The system test, though, looks at the system from the perspective of the customer and the future user.  1.Test Object  After the completion of the integration test, the software system is completely assembled and the system test looks at the system as a whole.  2.Test Environment:  An environment as similar as possible to the intended operational environment.  When: After Integration Testing.  Tools: Recommended set of tools 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 18

19. System Test  3.Test Objectives  To verify that the system components perform control functions  To perform inter-system test  To demonstrate that the system performs both functionally and operationally as specified  To perform appropriate types of tests relating to Transaction Flow, Installation, Reliability, Regression etc.  Problems in System Test Practice  Unclear system requirements  Missed decisions  Projects may fail 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 19

20. Acceptance Test  Def: All the test levels testing activities that are run while still under the producer's responsibility, executed before the software is presented to the customer or the user. But, before installing and using the software in real life, another test level must be executed: the so-called acceptance test.  Typical forms of acceptance testing include the following:  Testing to determine if the contract has been met  User acceptance testing  Operational (acceptance) testing  Field test (alpha and beta testing)  1.Test Object : Complete ready system 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 20

21. Acceptance Test  2.Test Objectives:  To verify that the system meets the user requirements  When: After System Testing  Who: Users / End Users  3.Test Environment:  producer's site  customer's site.  Tools: Comparator, keystroke capture & playback, regression testing  4.Test Strategies  Black Box techniques  Problem / Configuration Management 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 21

22. Generic Types of Testing 1. Functional testing 2. Nonfunctional testing 3. Testing of software structure 4. Testing related to changes 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 22

23. 2. Nonfunctional testing  1.Load test: Measuring of the system behavior for increasing system loads e.g., the number of users that work simultaneously, number of transactions  2.Performance test: Measuring of the processing speed and response time for particular use cases, usually dependent on increasing load  3.Volume test: Observation of the system behavior dependent on the amount of data e.g., processing of very large files  4.Stress test: Observation of the system behavior when it is overloaded. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 23

24. 2. Nonfunctional Testing  5.Testing of security against unauthorized access, denial of service attacks etc.  6.Stability or reliability test during permanent operation  e.g., mean time between failures or failure rate with a given user profile.  7.Robustness test: Measuring the system's response to operating errors, or wrong programming, or hardware failure, etc., as well as examination of exception handling and recovery  8.Testing of compatibility and data conversion: Examination of compatibility to given systems, import/export of data etc. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 24

25. 2. Nonfunctional testing  9.Testing of different configurations of the system, e.g., different versions of the operating system, user interface language, hardware platform, etc. (back-to-back testing)  10.Usability test: Examination of the ease of learning the system, ease and efficiency of operation, understandability of the system output, etc., always with respect to the needs of a specific group of users ([ISO 9241], [ISO 9126])  11.Checking of the documentation for compliance with system behavior (e.g., user manual and GUI)  12.Checking of maintainability: Assessing the understandability of the system documentation and whether it is up to date. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 25

26. 3. Testing of Software Structure  Structural techniques (white box testing) use information about the test object's internal code structure or architecture (statements or decisions, a calling hierarchy, menu structures).   The objective is to design and run enough test cases to, if possible, completely cover all structural items. 1/11/20182.Testing in the SDLC & Test Levels /D.S.Jagli 26

27. 4. Testing Related to Changes and Regression Testing  When existing software is changed, defects are repaired, or new parts are added, the changed parts must be retested.  Regression Testing  The regression test is a retest of a previously tested program following modification, to ensure that faults have not been introduced or uncovered as a result of the changes made.  Regression testing may be performed at all test levels, and applies to functional, nonfunctional, and structural testing.  Selection Of Regression Test Cases  Only the high priority tests according to the test plan are repeated. 1/11/2018 2.Testing in the SDLC & Test Levels /D.S.Jagli 27

28. Other Nonfunctional testing  End-to-end testing  Similar to system testing; involves testing of a complete application environment in a situation that mimics real- world use  Sanity testing  Initial effort to determine if a new software version is performing well enough to accept it for a major testing effort.  Regression testing  Re-testing after fixes or modifications of the software or its environment. 1/11/2018 28 2.Testing in the SDLC & Test Levels /D.S.Jagli

29. Other Nonfunctional testing  Acceptance testing  Final testing based on specifications of the end-user or customer  Load testing  Testing an application under heavy loads.  Eg. Testing of a web site under a range of loads to determine, when the system response time degraded or fails.  Stress Testing  Testing under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database etc.  Term often used interchangeably with ‘load’ and ‘performance’ testing.  Performance testing  Testing how well an application complies to performance requirements. 1/11/2018 29 2.Testing in the SDLC & Test Levels /D.S.Jagli

30. Other Nonfunctional testing  Install/uninstall testing  Testing of full, partial or upgrade install/uninstall process.  Recovery testing  Testing how well a system recovers from crashes, HW failures or other problems.  Compatibility testing  Testing how well software performs in a particular HW/SW/OS/NW environment.  Alpha testing  Testing done when development is nearing  completion; minor design changes may still be made as a result of such testing. 1/11/2018 30 2.Testing in the SDLC & Test Levels /D.S.Jagli

31. Other Nonfunctional testing  Beta-testing  Testing when development and testing are essentially completed and final bugs and problems need to be found before release.  Exploratory testing / ad-hoc testing  Informal SW test that is not based on formal test plans or test cases; testers will be learning the SW in totality as they test it.  Comparison testing  Comparing SW strengths and weakness to competing products.  Mutation testing  To determining if a set of test data or test cases is useful, by deliberately introducing various bugs.  Re-testing with the original test data/cases to determine if the bugs are detected. 1/11/2018 31 2.Testing in the SDLC & Test Levels /D.S.Jagli

32. Thank u ? 1/11/2018 32 2.Testing in the SDLC & Test Levels /D.S.Jagli