1. CSC 480 Software Engineering
Integration Testing

2. Software Engineering Roadmap:
Construct system in stages
- Plan integration of parts
to yield whole
- Test subassemblies
- Assemble in “builds”
- Test whole system
in a variety of ways
Identify
corporate
practices
Plan
project
Maintain
Analyze
requirements
Integrate
& test system
Design
Implement
Test units
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

3. Chapter Learning Goals
Be able to plan the integration of modules
Understand types of testing required
Be able to plan and execute testing
beyond the unit level
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. 1. Introduction to system integration

5. Unified Process for Integration & Test
Jacobson et al: USDP
Requirements
Analysis
Design
Implemen-
tation
Test
Inception
Elaboration
Construction
Transition
Integration
Unit Tests
Integration tests ... System tests
Prelim.
iterations
Iter. #1
Iter. #n
Iter.
#n+1
Iter. #m
Iter.
#m+1
Iter. #k
…..
…..

6. Development Overview Customer Requirements Architecture
loss of information
Requirements
loss
Architecture

7. Module (e.g., package) code
Customer
Development Overview
loss of information
Requirements
loss
Architecture
loss
loss
Detailed design
Interface specs
loss
Function code
loss
Module (e.g., package) code
After Myers
System code

8. Testing Units in Context
Stand-alone unit test of function
-- may require driver & stubs
Test of function in context
-- eliminate or reduce driver & stubs
Function
code
Function tests
code +
Iteration or System
code
Complete code

9. Testing Overview: Artifact Flow (After Myers)
order of testing
Requirements
(11) Acceptance tests
Testing Overview: Artifact Flow (After Myers)
Docs.
(10) Installation tests
Architecture
(9) Usability tests
Docs.
Docs.
Detailed design
(8) System tests
Docs.
(7) Regression tests
Interface specs
(6) Integration tests
Function code
Docs.
(5) Interface tests
Code +
Code +
Module (e.g., package) code
(2),(4) Module tests
Code +
Code +
(1),(3) Function tests
Iteration or System code
Complete code

10. Testing for Validation and Verification (After Myers)
(11) Acceptance tests*
Requirements
Tested
against
requirements
(“validation”)
(10) Installation tests*‡
(9) Usability tests*‡
(8) System tests*‡
(7) Regression tests*
Testing for Validation and Verification (After Myers)
(1), (4) Function tests
Includes… : *use-cases
‡performance testing

11. Testing for Validation and Verification (After Myers)
(11) Acceptance tests*
Requirements
(10) Installation tests*‡
“validation1”
(9) Usability tests*‡
(8) System tests*‡
Architecture
“verification2”
(7) Regression tests*
(6) Integration tests*
Interface specs
“verification2”
(5) Interface tests
(1), (4) Function tests
Detailed design
“verification2”
(2), (3) Module tests
requirements
Note 1: Tested against
Note 2: Tested against
documents indicated
Includes… : *use-cases
‡performance testing

12. 2. The integration process

13. Build 1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

14. Build 2
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

15. Build 3
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

16. Final Build of Single Level
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

17. Final Build of Double Level
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

18. . . . . The Build Process Single level iteration
Double level iteration
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

19. Integration in Spiral Development
Design
Requirements
analysis
First iteration
Second iteration
2. Design for
additional
requirements
1. Get additional
requirements
3. Code
additional
5. Test
4. Integrate
new code
Implementation
Test
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

20. Relating Builds and Iterations in the RUP
Jacobson et al: USDP
Requirements
Analysis
Design
Implemen-
tation
Test
Inception
Elaboration
Construction
Transition
First build
for
iteration i
Last build
for
iteration i
Prelim.
iterations
Iter. #1
Iter. #n
Iter.
#n+1
Iter. #i
Iter. #m
Iter.
#m+1
Iter. #k
…..
…..
…..

21. Typical Build 1
Module 1 2 3 4
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

22. Typical Build 2
Module 1 2 3 4
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

23. Module 1 Unit-Oriented Build 1
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

24. Module 1 2 3 4 Unit-Oriented Build 2
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

25. Module 1 2 3 4 Unit-Oriented Build 3
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

26. Last Build
Module 1 2 3 4
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

27. Build Sequences: Ideal vs. Typical
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

28. Plan Integration & Builds
1. Understand the architecture decomposition.
try to make architecture simple to integrate
2. Identify the parts of the architecture that each iteration will implement.
build framework classes first, or in parallel
if possible, integrate “continually”
build enough UI to anchor testing
document requirements for each iteration
try to build bottom-up
so the parts are available when required
try to plan iterations so as to retire risks
biggest risks first
specify iterations and builds so that each use case is handled completely by one
3. Decompose each iteration into builds if necessary.
4. Plan the testing, review and inspection process.
5. Refine the schedule to reflect the results.
One way to ...
Plan Integration & Builds
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

29. Roadmap for Integration and System Test
1. Decide extent of all tests.
Roadmap for Integration and System Test
2. For each iteration …
2.1
For
each
build …
2.2 Perform iteration system and usability tests -- see section tbd
3. Perform installation tests -- see section tbd
4. Perform acceptance tests -- see section tbd

30. Roadmap for Integration and System Test
1. Decide extent of all tests.
2. For each iteration …
2.1
For
each
build …
2.1.1 Perform regression testing from prior build
2.1.2 Retest functions if required
Retest modules if required
Test interfaces if required
Perform build integration tests -- section 3.1
Development of iteration complete
2.2 Perform iteration system and usability tests -- sections 3.4, 3.5
System implemented
Roadmap for Integration and System Test
3. Perform installation tests -- section 3.8
System installed
4. Perform acceptance tests -- section 3.7
Job complete

31. Artifacts and Roles for Integration Testing*
Component engineer
Integration tester
System tester
Test
engineer
responsible for

32. Artifacts and Roles for Integration Testing*
Component engineer
Integration tester
System tester
Test
engineer
responsible for
Test evaluation 
Use-case model
Test plan
Test procedure
Test component
Defect management
Test case
*Jacobson et al: USDP

33. Key Attributes for Usability Testing*
Accessibility
How easily can users enter, navigate & exit?
e.g., measure by average time taken to . . .
Responsiveness
How quickly does the application allow the user to accomplish specified goals?
e.g., measure by average time taken
Efficiency
Degree to which the number of required steps for selected functionality is minimal
“minimal” deduced in theory
e.g., measure by minimal time / average time
Comprehensibility
How easy is the product to understand and use with documentation and help?
e.g., measure time taken for standard queries
Key Attributes for Usability Testing*
Adapted
from Kit [Ki].