1. What is a level of test?  Defined by a given Environment  Environment is a collection of people, hard ware, software, interfaces, data etc.

2. Levels of testing imbursement Unit Testing Integration Testing System Testing CodeCodeCodeCode DesignDesignDesignDesign Validation Testing Acceptance Testing REQREQREQREQ

3. Unit or Module Testing  A unit is smallest testable piece of software – can be compiled, linked, loaded – e.g functions/procedures, classes, interfaces – normally done by programmer – Test cases written after coding  Disadvantage Test cases written to suit programmer’s implementation (not necessarily specification  Better to use “Buddy Testing”

4. Buddy Testing  Team approach to coding and testing.  One programmer codes the others tests and vice versa. Test Cases-written by tester( before coding starts). Better than single work approach. Objectivity Cross-training Models program specification requirement

5. Integration testing  Integration testing is intended to find bugs in interfaces between modules.  In integration we assemble units together into subsystems and finally into systems. It is possible for units to function perfectly in isolation but to fail when integrated  It has 3 Approaches Top Down Testing Bottom-Up Testing Sandwich Testing

6.  Tests the high levels of a system before testing its detailed components. The program is represented as a single abstract component with sub-components represented by stubs.  Advantage Should be used with top-down program development. A limited, working system is available at an early state in the development. Top-Down Testing

7.  Disadvantage Strict top-down testing is difficult to implement because of the requirement that program stubs, simulating lower level of the system, must be produced. Test output may be difficult to observe. Collections of objects are not usually in a strictly hierarchical way.

8. ADCBFEG Example component hierarchy

9. Bottom up testing  Tests the modules at the lower levels in the hierarchy, and then working up the hierarchy of modules until the final module is tested.  Component driver  Appropriate for object-oriented systems.

10. Bottom-up testing : example Test E Test F Test G Test B,E,F Test C Test D,G Test A,B,C,D, E,F,G

11. Sandwich testing  System is viewed as three layers.  A top-down approach is used in the top layer and a bottom-up approach in the lower layer.  Modified sandwich testing allows upper level components to be tested before merging them with others.

12. Test A Test B,E,F Test A,B,C,D, E,F,G Test E Test D,G Test F Test G

13. Test A Test B,E,F Test A,B,C,D, E,F,G Test B Test D Test E Test C Test D,G Test F Test G

14. System Testing  A system consists of all of the software (and possibly hardware, user manuals, training materials, etc.).  System testing focuses on defects that arise at this highest level of integration.  Typically system : functionality, usability, security,..  The following tests can be categorized under System testing:  Recovery Testing.  Security Testing.  Performance Testing. a)Stress b)Load

15. Recovery Testing  It is a system test that forces the software to fail in a variety of ways and verifies that recovery is properly performed.  If recovery is automatic, reinitialization, checkpointing mechanisms, data recovery and restart are evaluated for correctness. If recovery requires human intervention, the mean-time-to-repair (MTTR) is evaluated to determine whether it is within acceptable limits.

16. Security Testing  Security testing attempts to verify that protection mechanisms built into a system will, in fact, protect it from improper penetration. During Security testing, password cracking, unauthorized entry into the software, network security are all taken into consideration.

17. Performance Testing  Performance tests are coupled with stress testing and load testing, usually require both hardware and software instrumentation.

18. Stress Testing  Stress testing executes a system in a manner that demands resources in abnormal quantity, frequency, or volume.  Running the software under less condition.  Low memory, low disk space and so on

19. Load Testing  Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.

20. Acceptance Testing  To determine if the software meets customer requirements. (Alpha and beta testing are variants of acceptance testing).

21. Alpha Testing  It is conducted at the developer’s site by the customer.  It is conducted in a controlled environment.

22. Beta Testing  The Beta testing is conducted at one or more customer sites by the end- user of the software.  The beta test is a live application of the software in an environment that cannot be controlled by the developer.

23. Validation testing  Validation testing is to determine if the software meets all its requirements (as defined in a document like an SRS).

24. Regression Testing  As part of validation testing, regression testing is performed to determine if the software still meets all its requirements in light of changes and modifications to the software. ( Regression testing frequently is also performed during software development as new versions of the product are being developed.)

25. Factors influencing test scope  Size of project  Complexity of project  Budget for project  Time scope for project  Number of staff

26. Why test at different Level  Software development naturally split to phases.  Easily track bugs  Ensure a working subsystem, components, library  Software reuse is more practical.

27. V-model