Web Design Ethiopia

Develop a formalized system for recording and making bug fixes. You can either record the errors and changes in a database (for larger projects) or simply keep forms and checklists of the required changes.

Whatever you do, you must keep a record of the changes. Why? Having a history of the changes you’ve made and why will keep you from going in circles, making changes and then changing them back.

It also provides you with details of who found the problems and who made the corrections. While it may seem like an unnecessary extra effort at the time, you’ll appreciate it a year later when you encounter a similar bug.

You’ll have the error recorded and know who fixed it and how, saving you repeat effort. In addition, documentation will provide you with data that can be used to examine the efficiency of your processes and give you a baseline for measurement and estimation of future projects.

The Problem Report and Resolution Form (Form 11-1; download from http://www.mkp.com/uew/) can be used to track problems. While using this detailed form may not be cost-efficient for everyday HTML problems, it is appropriate for complex system such as database-driven portions of sites. You can also track this information in a database.

The Problem Summary Report (Form 11-2; download from http://www.mkp.com/uew/) lists all outstanding problems (any that haven’t been resolved) for quick reference. Totals at the bottom allow for quick status checking about the number of problems of each type.
Who Needs To Make The Fixes?

There are a couple of reasons you need to take the bug report back to the person who originally made the mistake. The first reason is to make the person aware of his or her mistakes so similar mistakes will be prevented in the future. Second, that person will have a better idea than anyone else of how the changes may affect the rest of the site.
 

Report This Post