Integration Testing, part 5 More than one test may be needed

In my last post I mentioned a test that we can run on the specifications for the engine and muffler.  This is notionally a check we write a script for the computer to run and validate that the components will work with each other.

That is probably not enough, though.  Just checking the data sheets is no guarantee the actual muffler and engine will work together.  Imagine a scenario in which the redline (the top speed) of the engine is given.  Then imagine that, for whatever reason, the engine we are using exceeds that speed.  In this case, the engine will start to output more exhaust than the ratings sheet indicates and our muffler may not be able to handle that much extra, unexpected exhaust.

One possibility for this is an emergency.  Suppose the driver needs to get to a hospital and doesn't care about the damage the car may take.  In this case, we need to verify the behavior of the engine + muffler even when it goes out of specification.

The testing here is mechanical in nature.  We create a fake engine of some sort that outputs more than we expect the real engine to produce and test with the muffler.  At this point, we document the behavior of the muffler.  Some reasonable expectations are:

1. The muffler fails immediately and simply does not process the exhaust.  Instead, it simply passes through with no catalytic converter and no sound reduction.
2. The muffler fails more catastrophically.  It could break, overheat or worse, even explode.
3. There is also a case that the muffler designers built a safety margin into their specification and did not document it.  In this case, the muffler may work, perhaps only for a short duration.

We don't know what we should do if the muffler + engine do not work together in this scenario.  At this point, the testing organization is in exploratory testing mode and simply needs to determine the behavior.  Once we have a clear understanding of what is likely to occur we can apply that knowledge to making a decision. 

I'll cover that next.

Questions, comments, concerns and criticisms always welcome,

John

Integration testing, part 4. The type of test to create

Now that I have generally covered the task at hand - ensuring that our engine and muffler will work together - I can finally start covering how to test that they work together.

When I last mentioned the testing challenge of validating the engine output can always we handled by the muffer, I mentioned 2 different test methods we could employ.

The first was an automated test, running on a computer, which would compare the data sheet of the engine to the data sheet of the muffler.  Specifically, it would look at the volume and pressure output of the  engine and validate that all these numbers were less than the maximum capacity of the muffler.  If we assume that we can examine the data sheets and that they are up to date then this is a terrific solution.  Once we alter the document, we find out instantly if the numbers will work for us.  If we were sitting around a design room, we could quickly look at multiple different engine and muffler combinations and rule out sets that obviously would not work.  No need to weld the engine into place or anything heavy like that.  This type of check can prevent errors down the road (so to speak), is relatively cheap to implement and gives very speedy feedback.

This is a solution I would push to implement to help with this problem.

Since I am a tester by nature, though, this is not the only check I would want to use.  We've all heard the old sayings of not putting all our eggs in one basket and I would also want a backup system in place to help me understand the operation of the engine and muffler system.

More on that next time!

Questions, comments, concerns and criticisms always welcome,

John

Integration Testing, part 3

When we last left our muffler and exhaust test, we had determined the amount of output from the engine was less than the muffler could handle.  This was a "specification" test done by inspection of the documentation and had it failed, it would have alerted us to our poor design and prevented a world of problems later.

Of course, that is not enough. Let's say we decide to use the muffler from out thought experiment and the engine as well.  We still need to design a system to validate the output of the engine does not exceed the capacity of the muffler to handle.  This may not seem critical - after all, we just validated the two pieces work together - but time goes by and specifications can change.

Let's go forward six months into our design.  We have a prototype car up and running and it has a problem on hills.  It needs more power to get up hills quickly enough to make the driver happy.  One solution to this problem would be a more powerful engine.

So we take out the original engine and replace it with a larger model.  The larger engine only needs to run at half speed to get up the hill, and it does so with no problems.  The muffler works fine as well, so we may be fooled into thinking we have no risk.

But we may.  We have not tested the engine at full speed.  Now, the actual test here is a little bit tangential to my point: we would test this in a lab with all kinds of sensors and such connected to the car, or we could have had a check on the data sheets set up and running on a computer somewhere, to provide two examples.  The point I want to make is that we need the integration test to validate changes made during the development cycle. 

And clearly, the earlier we can detect a potential error, the better we will be able to respond.  More on that, and my two example integration tests I just mentioned, next time.

Questions, comments, concerns and criticisms always welcome,

John