Issue ? or Bug or Improvement or Feature or Requirement, this is a question – question often asked by non IT people, why ?

First of all we must define the name for all objects in our bug tracking system, the name and the meaning. Issue for developer, for tester, for helpdesk guy, for business analyst, for salesman, for our director, etc. You may say that we can track issues only in our production environment, IT team, all of us know what the issue is, but in the mid and huge companies but also in small ones we want/must trace an issue in all departments and that is a challenge.

How to define an issue ?

• Break one word into issue types
  Look at what objects You must store in bug tracker and create them.
• Assign types to user groups
  Give users chance to see and understand only small set of issue types
• Provide different issue adding forms
  Don’t attack user with huge count of form fields, he must see fields, that are proper to his level of knowledge.
• Describe
  Add description to every issue type, status, priority not too long.
• Workflow it
  If Your bug tracker supports workflow definition we are at home, if not write a procedure and move workflow from IT do people.

Typical issue types, in my opinion:

• Request
  Only developers, testers and people that are near software production can say that this is a bug or new feature for sure. All others are guessing and that fact is not very good for next steps in out life cycle. So I propose give them a chance to not choose :) Help desk guy, salesman, business analytic can only add Request and wait until someone from IT take an action and change issue type.
• Bug
  Let’s minimize bugs appearance :) of course but, as You know, bugs are often a good thing – not delayed critical ones. These insects are strictly connected with priorities, described below.
• New feature
  At or after project meeting, meeting with business owner we have huge amount of and improvements, I we don’t have separate requirements / project management software, let’s drop it to bug tracker. Naturally it flows with issue life cycle.
• Task
  Next thing to do if we don’t have any project/task management system – drop it and flow.

Typical issue priorities, in my opinion (People from business always try to assign highest one:) ):

• Critical
  Bug: Application crashes, hangs, user cannot do important business actions, data corruption.
  Business request: High business need, in example: our software is not law compatible.
  Task: Do it now !
• Major
  Bug: In some circumstances user can loose data or core functionality doesn’t work and there is no workaround.
  Business request: We must have this functionality it is our core and our market ruff.
  Task: Do it after current task.
• Medium
  Bug: Important functionality crash but there is workaround.
  Business request: End-user will be very happy if we add it.
  Task: You can plan it to next patch.
• Minor
  Bug: Some functionality does not work properly but there is another simple way to have good results.
  Business request: We have an idea but lets do it in future.
  Task: Plan it for next version release.
• Cosmetic
  Bug: Typographic error or wrong control position or bad color.
  Business request: Someone thinks “it will be good to have”
  Task: Do it later…

Having bug tracker with workflow designer we can arrange our process to always begin from Request (for business people) and then through improvement, bug, etc.

In summary I would say that, for sure it is not complete design to implement, but few loose thoughts which might help someone.

Share

• Tester Types – Free e-Book Review