Build the Installation Program Immediately
Begin developing the installation program immediately after you start developing your project. The installation program is the first part of your product that your users see. Too many products give a poor first
impression
, showing that the installation program was left to the last minute. By getting the installation program started as early as possible, you have sufficient time to test and debug it. If the installation program is done early, you can also
incorporate
it into your smoke test. This way, you're always testing it and your tests will be one step closer to simulating how the users will be running your program.
Earlier in the chapter, I recommended that you should build both release and debug versions of your product. You also need to have an installation program that allows you to install either version. Even though managed applications have the vaunted XCOPY installation, that's only for baby programs. Real-world managed applications are going to have to initialize databases, put assemblies in the global assembly cache, and handle other operations that just can't be done with a simple copy. Of course for native applications, don't forget that COM is still
alive
and kicking; COM needs so much stuff in the registry that it's almost
impossible
to properly use an application without running its installation program. By having a debug build installation program, developers can easily get a debug version on a machine so that they can quickly start debugging a problem.
One extra benefit of having the installation program done as early as possible is that others in your company can start testing your program that much sooner. With the installation program done, the technical support
engineers
can start using your program and providing you with feedback early enough in the cycle so that you can actually do something about the problems they find.
QA Must Test with Debug Builds
If you follow my recommendations in Chapter 3, you'll have some
excellent
diagnostics in your code base. The problem is that,
generally
, only the developers benefit from the diagnostics. To better help debug problems, the quality
engineers
need to be using the debug builds as well. You'll be amazed at how many problems you'll find and fix when the QA folks do their testing with debug builds.
One key point is that any assertions you add to the code can have their output disabled so that they do not mess up any automated tests the QA department runs. In the
next
chapter I discuss assertions for managed and native code. Both the managed code and my
SUPERASSERT
for native code have ways of turning off any popup message boxes or other interrupting output that cause automated tests to fail.
In the initial stages of the product cycle, the quality engineers should be alternating between debug and release builds. As the product progresses, they should gradually start
concentrating
more on the release builds. Until you reach the alpha release milestone, at which point you have enough of the features implemented to show customers the product, you should have the quality engineers use the debug build two to three days a week. As you approach beta 1, they should drop to two days a week. After beta 2, when all features and major
bugs
are fixed, they should drop to one day a week. After the release candidate milestone, they should be on the release build exclusively.
