The Art Of Software Development (part 4): Delivering Quality - Bug-bustin' (Page 5 of 7 )
Software defects encountered during the unit and system testing phasesare noted in a software problem report. This report contains a detaileddescription of each problem, complete with information on where itoccurred, the data input or procedure that caused it, its classification(fatal, major or minor), and its impact and suggested resolution. Thisreport is then returned to the development team for evaluation andsoftware rectification where required.
Every organization needs a sound defect management process, in order tomanage and resolve software defects found during testing. The bestprocess is still the simplest: the project manager assigns every bug aunique number in a so-called "defect log", and updates the status(assigned/resolved/verified/deferred) of each on a daily basis. Thisprovides a fast snapshot of all the bugs found during a particular testcycle, and makes it easy to see the current disposition of each.
Once all the bugs found during a particular testing cycle have beenresolved and verified, the software may be returned to the test team foranother round of testing. This process continues until no further bugsare found. Care should be taken at each stage to ensure that bug fixesdo not slip through the cracks, that all test cases relevant to the bugsfound are fully re-executed, and that the resolution of a particular bugdoes not introduce new bugs.
Use of bug tracking systems like Bugzilla can play an important role inmanaging 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 problemsare corrected and deltas sent back to the test team for re-verification.
Once the test plan has been completely executed and the test team hasverified that the product has zero defects, the project manager(s) canbegin organizing the acceptance test. Typically, this involves notifyingthe customer that the software is ready for release, setting a date forthe acceptance test, providing the customer (or the acceptance testteam) with training and sample data for the test, and closing all openitems related to the project. In case the acceptance test is to beconducted on-site, the final release code, together with all tools andrelated assets, needs to be checked out of the project repository andplaced on appropriate storage media for delivery to the customer's site.
It is very important that the code tested during the final acceptancephase be identical to the code released by the project's development andQA team, and that no undocumented changes to the code tree take placeduring the closure of system testing and the beginning of acceptancetesting.
In case problems are reported during the acceptance test, the same needto be communicated back to the development team for resolution. At thistime, each problem reported by the acceptance test team needs to beclearly classified as a bug or a change; bugs should be rectified, whilechanges need to be processed as per the process laid down for changerequests (more on this in the next article). Once all open issues areclosed and all bugs fixed, the software can be re-tested and - assumingno further errors - formally accepted for release.
Next: The Write Stuff >>
More Practices Articles
More By icarus, (c) Melonfire
/ 4 
