TDDD04 Software Testing
Lab 4: Integration Testing
Integration testing is the practice of planning for and verifying the successful integration of components, as efficiently and effectively as possible. As a goal, errors during integration should be discovered as soon as possible, with little overhead cost from the testing activities themselves. Ideally, we would like to integrate all real components early, and swiftly pinpoint the source of any unexpected behavior as they occur. In reality though, these two desires lead to mutually exclusive goals. Integration testing, in practice, requires both careful planning and reflection on the outcome.
In this lab assignment, you will be working in teams to assemble a set of LEGO components to form an aircraft. In figure 1, you see the a number of plastic boxes with LEGO that are to form specific parts of an aircraft. In the figure, you see a box labelled ?styrsystem? in Swedish (steering in English), you find wiring components that are to be attached to the airframe. Other boxes contain bits to construct other components of the aircraft. Although the scenario in this assignment does not involve actual software development, it shares several important principles with building a larger software system: there will be a number of smaller teams collaborating on building individual components, the integration of components is crucial to success, and you will need to work methodically to succeed on time. The fact that we are not building software as part of the exercise is actually of little relevance, but it greatly helps us to train on crucial aspects of successful integration testing. The assignment is also used by Saab in their internal training for developers, managers and other team members involved in building large, integrated systems.
You will have a restricted amount of time at your disposal for building the LEGO sets (
20 minutes exactly), and you will be given instructions with specifications before you begin.
These specifications are, just as in real life, the best approximations given to you before you are to commence design and build your product. To the extent there are ambiguities that affect integration, you shall note how you plan to resolve them.
Before you design and build, however, you will need to have an integration test plan in place, that takes into account the various dependencies components have with one another, and the order in which they should be assembled to verify a proper integration.
In integration testing, much of the complexity stems from the fact that a number of different people are to coordinate their actions to produce a working system. This is not a trivial task and requires practice, so you will have a chance to practice integration testing, reflect on the outcome of your work, improve your plans and try a second time.
Organization
In 2019 the integration lab is on october 2nd from 13:15 in room R41. The schedule for each group is detailed below.
The structions for the lab will be given in printed form after the lecture on
26/09. One person from each group should pick them up.
This lab will be run strictly on schedule, if you are late you will not be allowed into the room so please come on time.
Preparations
You will work in your whole WebReg groups (A1, A2, ...) during this assignment. There is a specific, scheduled lab session in the schedule for conducting this assignment.
Each team receives paper copies of design specifications at a given time and place before the lab session, as instructed by the course staff.
Upon receiving the design specifications, each team shall produce an integration testing plan as per the instructions below.
Creating an integration testing plan
Look at the component design specifications and especially, their declared and implicit interfaces to one another. Describe the dependencies between components, as in, which component will need
to be assembled with each other first, in order to assemble other components later. As you describe the dependencies, note any assumptions that you make regarding how components may fit together. Describe an order of integration based on these dependencies. Identify the necessary scaffolding that will be needed in order to conduct integration testing (compare with stubs and mocks in the lab on unit testing).
Usually in integration testing, fake implementations of software components that are not constructed yet are supplied for integration testing. These are usually called stubs or drivers, depending on whether the components are called from the components being tested, or if they call the component tested. In this case, if you feel the need to do something similar, please note how, and describe whether the concept of a stub or a driver best describes your substituted component(s).
This is the template you shall use when you create your integration test plan:
- Overview Present the overall focus and goal of the integration test activities. Write your
assumptions about the design specifications.
- Test cases Present a sequence of test cases, a person responsible for conducting them and
the desired end result, according to the interfaces identified.
- Test data According to the dependencies you identified, identify who will be responsible for
providing information to someone else as you build and test. Will scaffolding be needed?
- Acceptance criteria Identify how to verify that a test is passed, and the severity of a failure.
- Testing Schedule When will you conduct tests, what specific order will you have for your tests? Use your analysis of dependencies here.
- Environment How will you organize yourselves to make optimal use of your time for building and testing?
Building and integrating components
Based on your integration test plans, you are to divide work within your teams so that there are 1-2 people per station (there are 5 stations), along with one team leader and, optionally, one team observer. Stations with 2 people should include one person responsible for taking notes on your progress, according to a simple format so you can take notes quickly. Those who take notes should divide the stations between them, so you collect all data you need to evaluate your performance after the first session. This is one suggestion for such a format, where building and communication tasks are noted for station 5. Mind you, it is only a suggestion and other activities may be noted as well, depending on what you believe may be critical to your success. Columns relate to time intervals from the start of the build and test session.
| Activity |
00:00-05:00 |
05:00-10:00 |
10:00-15:00 |
15:00-20:00 |
| Building |
| Communicating with leader |
| Communicating team 1 |
| Communicating team 2 |
| Communicating team 3 |
| Communicating team 4 |
The team observer, if you choose to assign one of your team members to this function, should note how the overall plan is followed, and how components are integrated. Assuming that the order in which components A-E should be integrated has been determined as per the table below, you could note how integration is then actually performed according to this format, given that you have chosen to integrate components in the order presented in the Integration column to the left:
| Integration |
00:00-05:00 |
05:00-10:00 |
10:00-15:00 |
15:00-20:00 |
| 1-2 |
| 2-3 |
| 3-4 |
| 4-5 |
| 1-2-3 |
| 1-2-3-4-5 |
The team leader should help coordinate the actions of the team.
Note that you are free to organize your work as you please within these restrictions. Seating, communications and coordination is something you will need to decide upon jointly. A testing plan is important, but so, too, is communication and coordination.
At a given time and place, the team must be ready to start their first round of construction and integration, lasting exactly 20 minutes within the time frames given below.
| Time slot |
Team #1 |
Team #2 |
| 13:15-13:45 - 20 min + 10 min turnaround |
Group A1 |
Group A2 |
| 13:45-14:15 - 20 min + 10 min turnaround |
Group B1 |
Group B2 |
| 14:15-14:30 - break |
| 14:30-14:55 - 20 min + 5 min turnaround |
Group A1 |
Group A2 |
| 14:55-15:20 - 20 min + 5 min turnaround |
Group B1 |
Group B2 |
After the first round of construction and integration, you will do a joint review of your performance and each pair shall take short notes to summarize their reflections on the first round.
Revise your plans or procedures before the second round.
Then, you will be given a second chance at building the aircraft, hopefully improving your
performance.
After the second round, you will do another short review of your performance and each pair shall take notes to summarize your reflections.
Reporting your results
Each pair uploads a report to Gitlab that consists of your first and second version of your common integration testing plans, your own reflections on how you improved your work, where you list critical success factors you believe were relevant to successful integration testing. The reflection report shall be 2 pages long, excluding your integration test plans. Note that this is the only lab where you only submit a written report after you have completed the task, and there is no oral examination. We will have a class discussion of the outcome of this exercise though.
Passing requirements
An integration testing plan and reflection document with sufficient details as per the instructions above, active participation in the lab session, and a reflection document as per the instructions.
Q&A
- What if we fail to integrate the components the first time?
No worries, you have another chance.
- What if we fail the second time?
You have five minutes after your second build to reflect on why you failed, although you will not be allowed to try to integrate the components after 20 minutes. During those five minutes, you may try to detect what technical and other difficulties that prevented you from completing your task on time. We will take notes of whether you succeeded, and expect you to provide a proper reflection that describes in some detail why you did not succeed. It will be possible to pass the lab assignment even if you did not succeed in integrating the components, granted that you can present a good explanation for why you did not succeed.
- What if I cannot be present during the lab session?
Contact the course staff well in advance in such case, or if you fall ill, contact us as soon as you can.
Page responsible: Lena Buffoni
Last updated: 2019-09-30
Swedish web site
