1. Software Testing Introduction

2. Agenda Software Testing Definition Software Testing Objectives Software Testing Strategies Software Test Classifications According to testing concept According to requirements 2

3. Software Testing: Definition “ Testing is the process of executing a program with intention of finding error ”. What is Testing?  It is a formal process  Performed by specialized testing teams  Either a unit / integrated units / complete software is examined  By running the programs on a computer  Performed by approved test procedures  On approved test cases 3

4. Formal: Part of the development & quality plan. Included within the agreement signed by the customer. Specialized Teams: Independent teams or external consultants are hired to perform the task.  They are specialists.  They are unbiased (no favorites)  Results are poor if developers perform themselves Running the program: Quality assurance without program execution is not testing (it can be inspection, walkthrough, review ….) Approved test procedures: They should be approved and in-line with the test plan. Approved test cases: Should be defined in the test plan completely. Nothing should be added or removed from the approved cases. Software Testing: Definition 4

5. Direct Objectives  Identify and reveal as many errors as possible  Make the software of acceptable quality by removing the errors and retesting.  Perform the test effectively and efficiently within budget and schedule constraints. Indirect Objectives  Compile a record of software errors for use in error prevention in future. Software Testing: Objectives 5

6. Two basic strategies – common for all test frameworks  Big-Bang Testing : To test the software the package entirely once the complete package is available  Incremental Testing: To test the software in modules ( unit tests ), then test groups of units integrated with new components ( integration tests ). Repeat until the complete software is done and test again ( system tests ). Software Testing: Strategies 6

7.  Top-down Testing: The first module tested is the main module. The lowest level modules are tested last Incremental Testing Strategy 7 M11 M9 M10 M8 M6M7 M1M2 M3 M4 M5 Integration A Integration B Integration C Integration D Stage 1 Stage 2 Stage 3 Stage 4 Stage 5 Stage 6

8.  Bottom-up Testing : The lowest level modules are tested first and main module is tested last Incremental Testing Strategy 8 M11 M9 M10 M8 M6M7M1M2 M3 M4 M5 Integration A Integration B Integration C Stage 1 Stage 2 Stage 3 Stage 4

9. Stubs  Dummy module – If a upper level module is not available (not yet developed) for testing. Used in botto-up testing. Software Testing: Strategies 9 M9 M8 M1M2 Stubs

10. Drivers  Dummy module – If a lower level module is not available (not yet developed) for testing. Used in top-down testing. Software Testing: Strategies 10 M9 M8 M1M2 Drivers

11. Recommendations  Maintain a library of stubs and drivers – for quick access  Bottom-up strategy  + Ease of performance  - Lateness – whole program is observed  Top-down strategy  + Complete program activated after the main module is tested  + Early identification of analysis and design errors  - Difficult to prepare the stubs  - Difficult to analyze the results of the tests Software Testing: Strategies 11 Finally, depends on the developer which strategy to choose

12.  Big-bang strategy  + Works well with small and simple programs  - Identification of error is very difficult task  Top-down strategy  + Easier to find high percentage of errors – unit / integration tests  + Identification and correction of errors is easier – requires less resources  - A lot of programming resources are required  - A lot of testing operations required (big-bang has only one) Software Testing: Strategies 12 Incremental is the preferred to choice

13.  Black-box (functionality) testing  Ignores internal mechanism of the system and is based on the outputs generated in response to the selected input and conditions.  To evaluate the compliance of a system / component to specified functional requirements  White-box testing  Internal mechanism is taken into account Test Classification: Testing Concept 13

14.  McCall Model for Quality Requirements Classification Test Classification: Requirements 14 1.Output correctness tests 2.Documentation tests 3.Availability (reaction time) tests 4.Reliability tests 5.Stress tests (load tests and durability tests) 6.Software system security tests 7.Training usability tests 8.Operational usability tests 9.Maintainability tests 10.Flexibility tests 11.Testability tests 12.Portability tests 13.Software interoperability tests 14.Equipment interoperability tests Correctness Efficiency Integrity Usability Interoperability