Skip to content
This repository has been archived by the owner on Oct 28, 2024. It is now read-only.

Lifecycle of an issue

Jump to bottom
Ilija Lalkovski edited this page Oct 5, 2017 · 1 revision

Lifecycle of an issue

Table of Contents

Introduction

As you all might know by now, the testing process plays a huge role in delivering a high-quality solution.

Due to its importance, we're introducing new system for the lifecycle of one issue.

All team members (developers, project managers, QA engineers) must be aware of this process and follow it through so that we can have a synhronized process.

Roles

For the sake of simplicity and the current need of this company we have three roles:

  • Developer (DEV)
  • QA engineer (QA)
  • Project manager (PM)

Notes:

  • Roles are important because they will be related with the actions that each should perform given the state and the status of the issue. Note that all members can make all of the actions but they shouldn't. This is why roles are introduced.

States of an issue

One issue can be in two different states:

  • Opened
  • Closed

Notes:

  • Assign can be made separately from changing the state of an issue.
  • One issue can be without an assignee and in the same time can be opened/closed.

Status of an issue

One issue can have different status but we cannot have two active statuses for one issue. Issues can have the following statuses:

  • rejected (an issue that was rejected due to it not being relevant anymore, no matter the reason)
  • duplicated (an issue that was opened although there was a same existing issue)
  • in progress (an issue that's in development)
  • qa ready (an issue that's waiting to be tested by the QA)
  • testing in progress (an issue that's being tested)
  • reopened (an issue that was tested and the outcome wasn't positive so it's being marked as reopened)
  • deferred (an issue that's not relevant for the current version/release and it's being pushed/left for next updates)

Notes:

  • For all statuses we'll have a separate labels created.
  • Different roles can add or remove different status labels.
  • Before adding the qa ready label it's highly important for the DEV to check (test) the implemented change.

Issue Types

One issue can be of different type. For each type there will be a label and one issue can have several labels indicating the type. Every issue can be of the following type:

  • question (an issue that's opened so that a discussion can be created regarding certain topic)
  • bug (an issue that's a bug, crash or something else indicating wrong function of certain feature)
  • high priority
  • medium priority
  • low priority
  • feature (an issue that's opened as a result of specifying certain feature)
  • enhancement (an issue that's opened as an enhancement of a previous feature - example: add option for attaching extra photo on the profile)
  • optimization(an issue that's opened as an optimization of a previous feature - example: improve loading or speed up process)
  • task (an issue that's opened when certain integration should be done that can be related with a feature - example: integrate Crashlytics, integrate video call option by using some service, etc.)
  • design (an issue that's opened and it's related to a design specification and implementation)
  • ux (an issue that's opened and it's related with the user experience - example: animations, transitions, etc.)

Actions and lifecycle

Every issue has it's own lifecycle and everyone involved in the project must know the exact lifecycle. This is needed because each role can perform certain actions. Depending on your action the others can be up to date and can know whether it's their turn in the issue's lifecycle.

The lifecycle of the issue will be determined by setting and removing labels. By doing this, the person responsible for the next step of the lifecycle can get to work.

The actions are divided by Roles.

  • PM:

  • can open issue (of any type)

  • can assign issue

  • can close issue

  • can reject an issue

  • can set issue as duplicate

  • can set issue as qa ready

  • can set issue as reopened

  • can set issue as deferred

  • DEV:

  • can open issue (of any type)

  • can assign issue

  • can set issue as duplicate

  • can set issue as qa ready

  • can set issue as in progress

  • QA:

  • can open issue (of any type)

  • can assign issue

  • can close issue

  • can reject an issue

  • can set issue as duplicate

  • can set issue as testing in progress

  • can set issue as reopened

  • can set issue as deferred

Notes:

  • The DEV mustn't set qa_ready label without checking the issue himself/herself.
  • Labels for the issue types are set by the person who opens the issue. (rejected - QA/PM, duplicated - QA/PM/DEV, QA ready - DEV/PM, in progress - DEV, testing in progress - QA, reopened - QA/PM, deferred - PM/QA)
  • The DEV can open issue and can assign the issue to the PM only. The PM will revise the issue and will take appropriate actions (either reassign to the DEV or change the state of the issue along with its status).
  • When setting an issue as qa ready, the DEV won't change the assignee. The QA itself will see the issue and take appropriate actions and he/she will assign it to himself/herself.
  • An issue is being closed only by the QA or the PM once its status is being confirmed.
  • Given the fact that one label for the status of the issue can be active at one time, it's highly important to remove and add new status label so that an appropriate action can be taken.

Labels

For each project we'll have the same set of labels created, universal by color and name. The PM is responsible for creating labels with every new project and new repository. Exceptions are possible (depending on platform and purpose of repository) but overall, these labels are a must for a project where we have all roles involved.

For better visual representation of the labels and the corresponding colors check the image below:

Clone this wiki locally