The Art Of Software Development (part 4): Delivering Quality - Bug-bustin' (
Page 5 of 7 )
Software defects encountered during the unit and system testing phases
are noted in a software problem report. This report contains a detailed
description of each problem, complete with information on where it
occurred, the data input or procedure that caused it, its classification
(fatal, major or minor), and its impact and suggested resolution. This
report is then returned to the development team for evaluation and
software rectification where required.
Every organization needs a sound defect management process, in order to
manage and resolve software defects found during testing. The best
process is still the simplest: the project manager assigns every bug a
unique number in a so-called "defect log", and updates the status
(assigned/resolved/verified/deferred) of each on a daily basis. This
provides a fast snapshot of all the bugs found during a particular test
cycle, and makes it easy to see the current disposition of each.
Once all the bugs found during a particular testing cycle have been
resolved and verified, the software may be returned to the test team for
another round of testing. This process continues until no further bugs
are found. Care should be taken at each stage to ensure that bug fixes
do not slip through the cracks, that all test cases relevant to the bugs
found are fully re-executed, and that the resolution of a particular bug
does not introduce new bugs.
Use of bug tracking systems like Bugzilla can play an important role in
managing these software fixes, but are not sufficient by themselves;
tools must go hand in hand with a clear and error-free process flow,
such as the one described above, to ensure that all detected problems
are corrected and deltas sent back to the test team for re-verification.
Once the test plan has been completely executed and the test team has
verified that the product has zero defects, the project manager(s) can
begin organizing the acceptance test. Typically, this involves notifying
the customer that the software is ready for release, setting a date for
the acceptance test, providing the customer (or the acceptance test
team) with training and sample data for the test, and closing all open
items related to the project. In case the acceptance test is to be
conducted on-site, the final release code, together with all tools and
related assets, needs to be checked out of the project repository and
placed on appropriate storage media for delivery to the customer's site.
It is very important that the code tested during the final acceptance
phase be identical to the code released by the project's development and
QA team, and that no undocumented changes to the code tree take place
during the closure of system testing and the beginning of acceptance
testing.
In case problems are reported during the acceptance test, the same need
to be communicated back to the development team for resolution. At this
time, each problem reported by the acceptance test team needs to be
clearly classified as a bug or a change; bugs should be rectified, while
changes need to be processed as per the process laid down for change
requests (more on this in the next article). Once all open issues are
closed and all bugs fixed, the software can be re-tested and - assuming
no further errors - formally accepted for release.
/ 4 
