Big Bang Testing

Best used in conjunction with doing all the Design first (BigDesignUpFront?). Also fits well with strategies with lots of work ThrownOverTheWall; since that is exactly how the customer is going get the system.

BigBangTesting is left very late in the project, and should be done using the tools you have already built. Invite the Customer to have real humans sit down with the system and test it. That's the best way to find out how good it really is.

For best results, do lots of testing beforehand. To do so will improve the coverage of BigBangTesting. No one likes bad news.

In this situation, a period of time marked "testing" on the project plan is in reality the slack time. It's never intended for real development, because if you design at the very end, you cannot possibly have the time to fix or change the broken pieces.

[BigBangTesting leads to IntegrationHell.] or Nirvana (it's your choice)

Typical argument:

• We have to test the system once, at the end, in one big test, because if we test intermediate versions, we'll have to run the same tests over and over again (manually), and that will be very time consuming and expensive.

• We can't use automated regression testing tools: That would require investment and planning. Therefore, you must build your "test tools" using the same process you use to build your "production" code at the same time.
• We intend to not find any bugs when testing for which there is no Customer accepted work-around. If testers find bugs, then a "defect" in the automated regression testing tools has been found, and you must apply your process to correct it.

 "EVERYBODY KNOWS HOW TO DO THEIR JOBS, BUT NOBODY KNOWS HOW TO DO THE OTHER GUY'S JOB"

Is this an Unavoidable AntiPattern? Absolutely not; TestDrivenDevelopment and ExtremeProgramming expresses each code ability and functional requirement as a test, first. This leads to a flat bug rate, very little debugging, and easy project steering.

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006