Bug for the executor

During the quality assurance stage, a reviewer may discover errors in the completed task. They are registered in the system as separate entities and have rules and limitations for their successful correction by the executor.

A bug is a defect or an error in implementation, or an inconsistency between the actual result and the expected result.

A bug created by the reviewer during the Review stage when submitting a task that requires further work becomes a subtask for the executor.

Lifecycle:

• Proposed - suggested. When a bug is created, it receives this status by default.
• Rejected - declined. If a bug is proposed by a reviewer, sent back for re-review, but not fixed, it is moved to the rejection status to be returned to the performer. The completion of the subtask created to fix this bug is canceled.
• Fixed - corrected. Accepted by the reviewer.

Possibilities and limitations for the executor during the "Doing" stage upon return:

✅ Edit the title and description of the corresponding subtask, but editing the title and description by the executor does not change the corresponding data in the bug.

✅ Mark the subtask (bug) as completed.

✅ Leave a comment.

❌ Create a new bug.

❌ Change the status of the bug.

❌ Delete a bug and its associated subtask.

Actions of the executor:

• Task execution:
• Receive a task for revision with an identified bug.
• Start working.

1. If necessary, review the details of the bug on the "Bugs" screen.
2. Mark the subtask as completed
3. Finish working on the task.

 

•  A bug in the "Rejected" status cancels a completed subtask if the task is returned for revision for the second time (unchecking the checkbox for the executor).