IQAA: Integration Testing

Dr. Hanna's Practice #3: Test for both functional and quality requirements. I would have thought state charts and truth tables were familiar to everyone, but I think the typical Indianapolis tester has a lot less experience than, say, one in San Jose, so there were a lot of people who they weren't familiar to. But Dr. Hanna had some good advice on turning a requirement, written in English, into a model by splitting it up into actions and results. He took a typical requirement statement, teased four predicates and four consequences out of it, and showed the truth table that it resulted in, with the 16 possible states of the predicates and the expected consequences of each. I was a bit itchy here, because I always feel that you can go through and test your application like this, but then go through and test a separate bit of your application which contradicts it. To help my understanding, I went on the second day to a talk on integrations testing, which I thought would more or less cover my confusion. You've got one requirement, you've got another requirement, testing them both is integration testing, right?

Well, no. Integration testing is the actual bit where you take two components of the system and make sure they talk to each other properly. Testing the input/output of one component is mostly a unit test, since they usually are easily testable and verifiable based on the automated testing that should have been written by the developer. But you need integration testing to avoid the "operation was successful but the patient died" phenomenon, where the interface of component A is not clearly understood by the developer of component B, so he writes and tests a very nice component that doesn't do at all what component A expects.

But with that clarification, I guess I see the real issue: the thing that is worrying me are two contradictory requirements. Given a clear requirements document, it is no longer the tester's problem, and it is no longer the developer's problem. It's a business problem, and someone with knowledge of the problem domain is required to clarify the contradictory requirements, which allows us to update the requirements doc, and guess what - now the testers can redesign their test plan and the developers can redo their code.

Here's a list of books recommended at the conference.