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.

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

The development team is adding new features to an existing piece of software, and it is causing a lot of regression issues due to the addition of features while testing. As a tester (black box), what advice can I give to the development team so that the software is of good quality and released on time and within budget down the line?

Here is a clip from my answer:

As a tester, you should be able to carry some "street cred" when it comes to testing. So I'd recommend starting there. Try talking about the unit testing taking place. Talk about testability features you think may help the team with developing regression tests or that may help cut regression test cycle time in some other way. Look for projects that you could work on with the developers to help solve testing problems.

In the past, I've paired with programmers to extend unit tests they've already written. I've also had them pair with me to try to get some difficult test automation working. And I've sat down with them to design testability features like tools for data management, increased logging or alternative interfaces.

After testing, focus on design and the design process the team is following when they make their changes. As a tester, it's reasonable for you to ask to be involved there. You need to know for your testing, and most likely it's a place where you can contribute by asking questions and raising concerns. (Just don't become the tester who cried wolf.) Who's involved in designing the solutions? What peer reviews are they doing? Do they consult existing design artifacts and code or make assumptions?

You can find the full posting here.