Game Development Reference
In-Depth Information
Defect records for any bugs closed in the new release should be updated so they
can be used by testers to make decisions about how much to test in the new build.
Tests and builds should be properly version controlled, as described in the
following sidebar.
When you are sufficiently close to the end of the project, you also want to
receive the game on the media that it will ship on. Check that the media
provided contains all of the files that would be provided to your customer.
Version Control: Not Just for Developers
A fundamental principle of software development is that every build of an application should be
treated as a separate and discrete version. Inadvertent blending of old code with new is one of the
most common (and most preventable) causes of software defects. The process of tracking builds
and ensuring that all members of a development team are checking current code and assets into
the current version is known as version control.
Test teams must practice their own version control. There's nothing more time-wasting than for a
test team to report a lot of bugs on an old build. This is not only a waste of time, but it can cause
panic on the part of the programmers and the project manager.
Proper version control for the test team includes the following steps:
1. Collect all prior versions from the test team before distributing the new build. The prior
versions should be stacked together and archived until the project is complete.
2. Archive all paperwork. This includes not only any build notes you received from the develop-
ment team, but also any completed test suites, old test plans, screen shots, saved games,
notes, .AVIs, and any other material generated during the course of testing a build. It is
sometimes important to retrace steps along the paper trail, whether to assist in isolating a
new defect or determining in what version an old bug was introduced.
3. Verify the build number with the developer prior to duplicating it.
4. In cases where builds are transmitted electronically, verify the byte count, file dates, and
directory structure before building it. It's vital in situations where builds are sent via FTP or
email that the test team makes certain they are testing a version identical to the version the
developers uploaded. Confirm the integrity of the transmitted build before giving it to the
testers.
5. Renumber all test suites and any other build-specific paperwork with the current version
number.
6. Distribute the new build for smoke testing.
Search WWH ::




Custom Search