new issue:

  • set components to indicate the kind of issue, for example 'D-RainfallRunoff' and 'UndoRedo'.
  • mandatory settings: 'Affects version(s)' (indicates the version(s) in which the issue occurs), 'Priority', 'Build Number' (indicates the build in which the issue occured for the first time or the build in which it was noticed the first time)
  • optional settings: 'Fix version(s)', 'Customer'

assign issue:

  • this state can be reached in 4 situations:
    • developer assigns issues to her/himself
    • someone assigns issue to other person. That person will be notified by e-mail.
    • issue is reopened after review. The developer will be notified by e-mail.
    • issue is reopened after testing. The developer will be notified by e-mail.
  • start progress:
    • developer indicates when (s)he starts working on the issue. Developer should also check if mandatory fields are properly specified, and if field story points is set. If not, developer should notify report of issue of this and not start progress on the issue.
  • stop progress:
    • developers indicates when (s)he stops working on the issue. This step is optional if development is done and the issue is put up for review immediately by the developer.

review:

  • if developer is finished with development, (s)he puts the issue up for review. Field 'Code Reviewer' must be left empty (*). Field 'Fixed in Version(s)' must be set. The developer also must check if all subversion commits are reflected properly in the issue.
  • reviewer picks up issue and assigns herself/himself as reviewer.
  • start progress:
    • reviewer indicates when (s)he starts working on reviewing the issue.
  • stop progress:
    • reviewer indicates when (s)he stops working on reviewing the issue. This step is optional is (s)he decides immediately on the next state for the issue, see below.

(*) exception to this rule: in case issue was solved in pair programming effort, developer should enter pair programmer as code reviewer, and when applicable (i.e., no further reviews are necessary) resolve the issue immediately.

resolve:

  • this state can be reached in 4 situations:
    • review was okay.
    • issue was resolved as a result of a pair programming effort.
    • issue is not reproducable.
    • developer is waiting for client (with reason as described in the comments of the issue).
  • an e-mail will be sent to the reporter of the issue

closed:

  • this state can be reached in 2 situations:
    • testing was successful.
    • issue is a duplicate.
  • tester must not reassign the issue.
  • an e-mail will be sent to the reporter of the issue and to the product owner(s).
  • No labels

Disclaimer