Refer back to the two kernels, Software Component Testing and Software Configuration Testing, shown in Example Software Development Process in the linked animation below.

The Example Software Development Process shown in the animation is based on a predefined repository of process "kernels" from which the life cycle model for a given project can be defined. The two kernels defined for integration testing are Software Component Testing and Software Configuration Testing Kernels. Each kernel contains entry and exit criteria, inputs and outputs, activities, process controls, and metrics for a given activity.

The purpose of the software component test kernel above is to test units integrated together to form a component and remove all errors within that component. Then incrementally integrate components to form tested configuration items. Testing is focused on the smaller building blocks of the program rather than initially testing the program as a whole.

The inputs to the software component kernel under test need to be identified for configuration management (CM), by a build number, a list of which units are included in the build, a list of the problem reports corrected by this build, status of all problem reports, etc. The identification scheme must include COTS and NDS. The Software Engineering Environment (SEE) and the Software Testing Environment (STE) are necessary to perform integration testing. Tools and test drivers that are part of the STE. The list of defect reports for software under test, and status of all defect reports. Software Engineering and Testers should concentrate on open problem reports of high priority.

The entry criteria should be done before you start this kernel. This includes successful completion of unit testing for all units of the S/W component under test. The completion of S/W component integration testing support activities form the V&V Test Design & Support Software Development kernels. Again, integration testing is not the repeat of all unit testing.

The activities are: Software component integration testing to ensure correct functions, interfaces, performance, security, and reliability; Generation of Software Problem/Change Reports (SPCRs) by Software Engineering; and Updating the SDFs. The Software Manager needs to ensure that when writing defect reports they are traceability to the test case being run and (if possible) the requirement(s) being verified is maintained. Some developers maintain their own separate integration folders in addition to SDFs.

The process controls are that QA should monitor the testing or perform some spot checks (mini-audits), which might consist of examining the integration test plan for a particular component, running a test case, and ensuring that the results received are the same (when QA runs a test they should get the same results you did). Management should perform reviews of the components. The appropriate software component integration task leader must give approval.

The exit criteria is to successfully integrate the software components. The test success factors will be discussed in the next unit. The exit criteria is usually establish to metrics. For example, "We won’t stop testing until there are less than (44) defect reports open."

The outputs are to provide updates to the Engineering Load Build Kernel.

The metrics that can be collected are number of peer reviews, CSCI or CI code size, schedule progress, the statistics on the software errors found and fixed and, the amount and kind of management applied.

The purpose of the Software Configuration Item Testing Kernel abpve is to test each Configuration Item and remove all errors within that Configuration Item. Testing is first focused on the smaller building blocks of the program rather than initially testing the program as a whole.

The inputs to the Software Configuration Item Testing Kernel above are: The tested and integrated software components. The Software Engineering Environment and the Software Testing Environment are necessary to perform integration testing. Tools, procedures and test drivers are part of the STE. The engineering change control data which is: a list of defect reports for software under test, and status of all defect reports (concentrate on open problem reports of high priority).

The entry criteria should be done before you start this kernel. Again that integration testing is not the repeat of all unit testing. The prior activities for this kernel are completion of configuration item testing support activities from the Verification/Validation Test Design and Support Kernel. Successful completion of software component integration and testing for the components that comprise the configuration item under test (or Unit Test when the software component Test Kernel has been tailored out).

The activities are Software Configuration Item Informal Qualification Testing and/or dry run testing for formal qualification testing. Provide the updates to the SDF's. Generation, tracking, and resolution of Software problem/change requests by engineering need to ensure that when writing defect reports, traceability to the test case being run and (if possible) the requirement(s) being verified is maintained. Some developers maintain separate integration folders (in addition to SDFs).

The process controls are that QA should monitor the testing or perform some spot checks (mini-audits), which might consist of examining the integration test plan for a particular component, running a test case, and ensuring that the results received are the same (when QA runs a test they should get the same results you did). Management should perform reviews of the CSCI. The appropriate CSCI integration task leader must give approval.

The exit criteria is to establish the product baseline. The test success factors will be discussed in the next unit. The exit criteria is usually to establish metrics. For example, "We won’t stop testing until there are less than (44) defect reports open."

The outputs are to provide updates to the Engineering Load Build Kernel successfully integrated and tested configuration items.

The metrics that can be collected are number of peer reviews, CSCI or CI code size, schedule progress, the statistics on the software errors found and fixed and, the amount and kind of management applied.