Issue reporting and management is very important to any product, but in the world of computer software, it’s even more important. To keep it simple, software engineers should use only two kind of issue: bug and improvement. You may call them defect and enhancement, but there is no point in complicating the names with very minor difference: “defect, bug, fault, error, failure, mistake, issue”; or “enhancement, improvement, new feature, task, risk, dependency, issue” ; unless everyone’s already familiar to the basic two and ready to approach more advanced classifications.
IMHO, the most important factors to the usability of an issue management system is the reporting templates: bug-report template and improvement-request template.
+ Because it makes the request more effective and more efficient to both requestors (users/QA) and assignees (developers/supporters) .
Why effective/efficient requests are neccessary to assignees?
+ Because they help assignees understand the expectation and implement the improvement much easier and in less time .
Why effective/efficient requests are neccessary to requestors?
+ Because they help requestors write in less time, express the expectation easier, thus reduce the possibility of request-reject (or even worse, silent ignorance) from assigners. Hence it gets the improvement applied quicker and protect the reporters from moral/ego hurt .
Ok, any sample template for improvement-request ?
+ Normally, the requestors do NOT CARE about system-management attributes of the issue such as assignee, ID-number, storage, classification, etc… So, an effective template should just focus on the Summary and Description of the improvement. Or better, just a Description with bundled Summary and a few essential information such as the below:
SUMMARY: (one-line) ACTUAL RESULT: EXPECTED RESULT: REASONS TO CHANGE: 1. 2. ADDITIONAL INFORMATION: Product version: Environment: Notes: (recommendation, references, ...)
Is it that short ? I’ve worked with templates that include 20 items at least…
Repeat, keep it simple ! Otherwise requestors will eventually get frustrated and not bother requesting anything nor reporting bugs. No one wants to carry a whole burden just to request an improvement, even if it’s his/her job . The assigners also wants to save time and not reading a whole essay for every issue. Unless that’s what you really want, just follow K.I.S.S .
Pingback: Bug report template | DucQuoc's Blog
Pingback: Software tester objectives | DucQuoc's Blog
fixed link :