I recently did a series of podcasts for SearchSoftwareQuality.com. You can find them here:

• Researching software features to test


• Assessing risk and scope


• How to know you're ready to start testing

A while ago I answered the following question on SearchSoftwareQuality.com’s Ask The Software Quality Expert: Questions & Answers.

As far as I know integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component. My question is: What type of design documents/designs (data flow, use case) exactly are required to write integration test cases?

Here is a clip from my answer:

I can learn about expectations for the interaction based on:

• my understanding of the business problem trying to be solved.


• conversations about the functionality with other people on the project team.


• design documents for the components, the integration or the system in general.


• mapping documents or data-flow diagrams that show how information is moved through the components and what transformations take place.


• state diagrams that show what events take place and when.


• database, XML and other data schemas used in the process.


• other testing I've done or reviewed (at the unit level or system level).


• other similar types of integration I've worked with on past projects.


• and the very last integration test case I've executed (because I'm always thinking of new tests as I'm executing tests).

I suspect I even missed a couple of things I do to come up with test case ideas when I'm doing integration testing.

You can find the full posting here.