1. Integration testing
Integrate two or more module.i.e. communicate between the modules.
Follow a white box testing (Testing the code)

2. Integration Testing - Overview

3. Integration Testing
The Big-bang Approach.
Incremental Approach.

4. Integration Testing Strategies
Test methodologies may vary but two basic testing strategies applied:
Test the software in its entirety
“Big Bang Testing”
Test the software in modules - Unit Tests, Integration Tests, Systems Tests
“Incremental testing”
Two strategies for incremental testing
Bottom - up testing (test harness).
Top - down testing (stubs).
Sandwich Testing

5. Top-Down Integration Testing
Main program used as a test driver and stubs are substitutes for components directly subordinate to it.
Subordinate stubs are replaced one at a time with real components (following the depth-first or breadth-first approach).
Tests are conducted as each component is integrated.
On completion of each set of tests and other stub is replaced with a real component.
Regression testing may be used to ensure that new errors not introduced.

6. Top Down Integration A
top module is tested with
stubs B F G
stubs are replaced one at
a time, "depth first" C
as new modules are integrated,
some subset of tests is re-run D E
Stub is a piece of code emulating a called function

7. Top down – Advantages & Disadvantages
Top-down integration supports fault isolation;
Major design flaws show up early. Modules of a product can be divided into two groups:
The logic modules and operational modules.
By coding and testing the logic modules before the operational modules, top-down integration will exploit any major design faults early in the development process
The main disadvantage of top-down integration is that potentially reusable modules may not be adequately tested.

8. Bottom-Up Integration Testing
Low level components are combined in clusters that perform a specific software function.
A driver (control program) is written to coordinate test case input and output.
The cluster is tested.
Drivers are removed and clusters are combined moving upward in the program structure.

9. Bottom-Up IntegrationF G
drivers are replaced one at a
time, "depth first" C
worker modules are grouped into
builds and integrated D E
cluster
a driver is a piece of code emulating a calling function

10. Bottom-up – Advantages & Disadvantages
The operational modules are thoroughly tested when using a bottom-up strategy. It also provides fault-isolation, as does top-down integration.
Major design faults will be left undetected until late in the development, since the logic module are integrated last.
This may result in large costs in redesigning and recoding substantial portions of the project.

11. Sandwich Testing
Combine the two so as to capitalize upon their strengths and minimize their weaknesses
neither top-down nor bottom-up inplemenetation/integration is suitable for all the modules, the solution is to partition them

12. Sandwich Testing cluster A Top modules are tested with stubs B F G C
Worker modules are grouped into
builds and integrated D E
cluster

13. Top-Down Integration A top module is tested with stubs B F G
stubs are replaced one at
a time, "depth first" C
as new modules are integrated,
some subset of tests is re-run D E

14. Bottom-Up IntegrationF G
drivers are replaced one at a
time, "depth first" C
worker modules are grouped into
builds and integrated D E
cluster

15. System Testing
Confirms that the system as a whole delivers the functionality originally required.
Follows the black box testing.

16. System Testing - Goals Incorrect or missing feature Performance errors
Security errors
User interface errors
Configuration and compatibility
Compliance to required standards

17. System Testing - Overview

18. System Testing - Overview
System Tests:
Define test procedures and instructions
Review test plans
Execute test plans
Record results

19. System Testing - Strategy
Developing System Tests
stress tests
security tests
recovery tests
performance tests

20. System Testing System Functional Test System Performance Test
Test entire system against the functional requirements.
System Performance Test
Test the non-functional requirements of the system. For example,
Response times, load testing etc.
System Acceptance Test
Set of tests that the software must pass before it is accepted by the client.

21. Need for an automatic test suite execution.
Regression Testing
Change do not always effect the entire program.
Change in one part of system can effect other part.
After each change
Entire test suite of a system must be run again.
Need for an automatic test suite execution.

22. Test Activities
Boils down to selecting and executing test cases. Test case consists of……
Set of test inputs, of if the program is non-terminating, a sequence of test inputs.
Expected results when the inputs are executed; and
Execution conditions or execution environment in which the inputs are to be executed.
These steps generally remain same from
unit testing to system testing.

23. Test Case Selection Coverage criterion;
Equivalence Partitioning
Boundary-Value Analysis
Coverage-Based Testing
Control-flow
Data-flow
Expected behavior of every test input to be generated. (Test Oracles)
Testing environment.

24. Difficult to automate or to assess their quality
Test Oracles
Determines whether or not the program has passed or failed the test case.
A test oracle is
A program
A process
A body of data
In many cases - directly form the requirements.
For example, a test case assessing performance - performance threshold.
Difficult to automate or to assess their quality

25. Generally can be automated to an extend !!!!
Test Evaluation
Compare the actual behavior with the expected behavior.
Generally can be automated to an extend !!!!

26. Generally can be automated to an extend !!!!
Test Reporting
Report the outcome of the testing.
Developers
Project Mangers etc.
Generally can be automated to an extend !!!!

27. Testing Techniques
White Box
Black Box
Incremental
Thread