---
# System prepended metadata

title: '**Quy trình và Hướng dẫn Phân loại, Xử lý và Theo dõi Task và Bug**'

---

# **Quy trình và Hướng dẫn Phân loại, Xử lý và Theo dõi Task và Bug**

## **Raise các task, bugs**


- Tất cả các yêu cầu sẽ gửi lên 1 board duy nhất là board IT.
- Tất cả các yêu cầu đều phải được đặt trong Epic.
- CS sẽ gửi các lỗi, yêu cầu mới hoặc thay đổi từ khách hàng lên board IT, QA và DEV cùng phân tích để làm rõ yêu cầu. Nếu chưa rõ sẽ yêu cầu CS lấy thêm thông tin. Các yêu cầu phải cập nhật trong phần mô tả nếu có thay đổi.

## **Các yêu cầu của task/bug**

***Yêu cầu chung:***
- Yêu cầu phải được ghi rõ ràng, dễ hiểu.
- QA và SD sẽ kiểm tra yêu cầu. Nếu không rõ ràng, sẽ yêu cầu CS cung cấp đầy đủ thông tin và rõ ràng.
- Đối với Customer Bug, yêu cầu phải được tạo trên Jira trước. Sau đó, Jira ID mới được gửi qua Skype để trao đổi (nếu cần). Nếu không tạo Jira, QA/Dev có quyền từ chối trả lời qua Skype.


***Yêu cầu đối với bug khi chuyển cho DEV từ QA hoặc CS phải có các thông tin sau:***

- Version app.
- Datetime.
- Environment (Ghi rõ thông tin init ref id test của CS/QA). Còn link TMS, Gateway của tất cả các bank sẽ được gửi cho dev ở 1 file khác, dev tự duplicate ra con ref khác và tự giả lập)
- Step by step
- Result
- Expected
- Evidence (Images, log file ...)
- Types of Bugs (`New Bug`, `Regresstion Bug`, `Legacy Bug`)
- Bug Frequency (Occasional, Permanent)

***Yêu cầu đối với App, software từ DEV chuyển cho QA sau khi sửa lỗi phải có các thông tin sau:***
- Nguyên nhân lỗi.
- Cách fix lỗi.
- Phạm vi ảnh hưởng.
- Dev có test lại chưa?

## **Các flow cho `Bug`, `Task`**

***Flow đối với `bug`***

```mermaid

sequenceDiagram 
  CS ->> QA: Bug
  QA ->> QA: Verify and collect information
  alt bug
    QA ->> DEV: Ver App, Evidence...    
    DEV->> DEV: Verify and Fixed
    DEV ->> QA: New App with some infor (how to fix, effect, root cause..)
  else not a bug
    QA ->> CS: Invalid
  end
```

***Flow đối với `Task`***

```mermaid

sequenceDiagram 
  CS ->> DEV: New requirement
  DEV ->> DEV: Verify
  CS ->> QA: Mention QA to know the requirement
  QA ->> QA: Verify
  DEV->> DEV: Dev in progress
  DEV ->> QA: New App with some infor (how to fix, effect, root cause..)
  QA ->> CS: QA verify done  
```

## **Cách đặt tên và quy định đối với tên Epic, Task, Bug**

**Quy định chung về Epic,Task, Bug:**
* Epic sẽ được tạo sẵn ở các board, nếu tên Epic không tìm thấy thì request người quản lý board để tạo.
* Sử dụng chữ in hoa để đặt tên tiêu đề của Epic, Task, Bug.


**Các loại Epic:**

|Name|Ex|Description|
|---|---|--|
|NEXT RELEASE|[NEXT RELEASE] [STB-PAYMENT APP-PAX AXXX]|Tính năng mới hoặc bug cần phải sửa trong verion tiếp theo|
|RELEASED-VERSION|[RELEASED-171023A920ProVCB] [VCB-PAYMENT APP-PAX AXXX]|Ứng dụng đã được bank nghiệm thu và golive|
|TASK|[INTEGRATION] [SAIGONBANK-CMS-UTIMACO HSM], [CERTIFY] [VCB-PAYMENT APP-PAX A8500] | EPIC cho các công việc phát sinh |
|BAU|[BAU] [ZALOPAY-SOUNDBOX]|EPIC cho các công việc tốn ít thời gian, không nằm trong project lớn đang làm hoặc công việc bảo trì|
|TIME TRACKING|[TIME-TRACKING-AND-MEETINGS]|EPIC để log work lại các công việc không phải là task như: họp, nghỉ phép hoặc hỗ trợ cho team Development|



**Cách đặt tên Epic, Task**
| Type | Rule | Example|
| -------- | -------- | -------- | 
| Epic     | `[EPIC TYPE] [CUSTOMER-THIRDPARTY-PRODUCTS-MODEL]`     | [NEXT RELEASE] [VCB-PAYMENT APP-A920PRO]|
| Task     | `[TASK TYPE] [SUMMARY]`     |    [TASK] [TEST] [NEW REQUEST: CHỈNH SỬA SRS ĐÁP ỨNG YÊU CẦU PENTEST VCB]
| Bug     | `[BUG TYPE-VERSION] [SUMMARY]`     |   [INTERNAL BUG-171023A920ProVCB] [TẠI MÀN HÌNH ĐỌC THẺ, THỈNH THOẢNG KHÔNG NHẤN NÚT BACK ĐƯỢC]|


## **Các loại issue type**

| Issue type        |  Description           |
|-------------------|----------------------- |
|`Epic`             |      |
|`Customer Bug`     | Bug Khách hàng báo (CS phải raise vào 1 Epic tương ứng)    |
|`Intenal Bug`      | Bug nội bộ là child issue của 1 Epic tương ứng, CS/QA tìm ra trong quá trình test)    |
|`Intenal Bug (belog to QA's task)`      | Bug nội bộ QA tìm ra trong khi làm task test, bug này phải là subtask của 1 task tương ứng)    |
|`New Request`      | Các yêu cầu mới từ khách hàng, kể cả change request    |
|`Improvement`      | Các cải tiến từ nội bộ hoặc các yêu cầu nội bộ    |
|`Task`      | Task nội bộ với luồng đơn giản, TODO -> IN PROGRESS -> DONE    |
|`Internal QA Task`     | Task nội bộ QA    |



**Work Flow For `Customer BUG`**

```mermaid
flowchart LR
    subgraph Task Creation
        START --> |Create| TODO
        TODO --> |Not Bug| REJECT
        REJECT --> |This is Bug| TODO
        TODO --> |Plan| PLANNED
    end
    subgraph Development
        PLANNED --> |Start| DEV_IN_PROGRESS
        DEV_IN_PROGRESS --> |Done| DEV_DONE
        DEV_IN_PROGRESS --> |Clarify| WAITING_FEEDBACK
        DEV_IN_PROGRESS --> |No Fix/Deferred| REJECT
        WAITING_FEEDBACK --> DEV_IN_PROGRESS
    end
    subgraph QA & Verification
        DEV_DONE --> |Prepare| READY_FOR_QA
        READY_FOR_QA --> |Test| QA_IN_PROGRESS
        QA_IN_PROGRESS --> |Fail| PLANNED
        QA_IN_PROGRESS --> |Clarify| WAITING_FEEDBACK
        QA_IN_PROGRESS --> |Pass| READY_FOR_CS
        READY_FOR_QA --> |Incomplete| DEV_DONE
        READY_FOR_CS --> |Fail| READY_FOR_QA
        READY_FOR_CS --> |Pass| CUSTOMER_REVIEW
        CUSTOMER_REVIEW --> |Pass| DONE
        CUSTOMER_REVIEW --> |Fail| READY_FOR_CS
        WAITING_FEEDBACK --> QA_IN_PROGRESS
    end
    subgraph Overdue
        OVERDUE --> PLANNED
        OVERDUE --> READY_FOR_QA
        OVERDUE --> READY_FOR_CS
    end         
```

- **TODO**: CS tạo yêu cầu mới để xử lý.
- **REJECT**: Nếu không phải là lỗi, yêu cầu sẽ bị từ chối.
- **PLANNED**: Yêu cầu được lên kế hoạch cho quá trình xử lý.
- **DEV_IN_PROGRESS**: Nhóm phát triển bắt đầu xử lý yêu cầu.
- **WAITING_FEEDBACK**: Trong quá trình xử lý nếu cần phản hồi từ khách hàng hoặc bên khác, yêu cầu được đưa vào trạng thái chờ phản hồi.
- **DEV_DONE**: Yêu cầu đã được phát triển hoàn tất.
- **READY_FOR_QA**: Yêu cầu đã sẵn sàng cho quá trình kiểm thử của Quality Assurance (QA).
- **QA_IN_PROGRESS**: Nhóm QA bắt đầu xử lý yêu cầu
- **READY_FOR_CS**: Yêu cầu đã sẵn sàng cho CS để verify lại, sau đó gửi Bank.
- **CS_IN_PROGRESS**: Nhóm CS bắt đầu xử lý yêu cầu
- **CUSTOMER REVIEW**: Bank đã UAT xong
- **DONE**: Yêu cầu đã hoàn thành.
- **WON'T FIX**: Minor issue, nếu fix sẽ ảnh hưởng nhiều khi đó dev có thể chuyển sang status này
- **DEFERRED**: timeline gấp, dev có thể đề xuất fix ở release sau.
- **OVERDUE**: Yêu cầu đã vượt quá thời hạn dự kiến.

**Work Flow For `Internal BUG`**: Luồng giống `Customer BUG` nhưng với bug mà CS raise sẽ về lại CS để check, còn task nào QA raise thì QA có thể tự đóng yêu cầu.

```mermaid
flowchart LR
    subgraph Task Creation
        START --> |Create| TODO
        TODO --> |Not Bug| REJECT
        REJECT --> |This is Bug| TODO
        TODO --> |Plan| PLANNED
    end
    subgraph Development
        PLANNED --> |Start| DEV_IN_PROGRESS
        DEV_IN_PROGRESS --> |Done| DEV_DONE
        DEV_IN_PROGRESS --> |Clarify| WAITING_FEEDBACK
        DEV_IN_PROGRESS --> |No Fix/Deferred| REJECT
        WAITING_FEEDBACK --> DEV_IN_PROGRESS
    end
    subgraph QA & Verification
        DEV_DONE --> |Prepare| READY_FOR_QA
        READY_FOR_QA --> |Test| QA_IN_PROGRESS
        QA_IN_PROGRESS --> |Fail| PLANNED
        QA_IN_PROGRESS --> |Clarify| WAITING_FEEDBACK
        QA_IN_PROGRESS --> |Pass| READY_FOR_CS
        READY_FOR_QA --> |Incomplete| DEV_DONE
        READY_FOR_CS --> |Fail| READY_FOR_QA
        READY_FOR_CS --> |Pass| DONE
        QA_IN_PROGRESS --> |Pass| DONE
    end
    subgraph Overdue
        OVERDUE --> PLANNED
        OVERDUE --> READY_FOR_QA
        OVERDUE --> READY_FOR_CS
    end 
```



**Work Flow For `New Request` and `Improvement`**


```mermaid
flowchart LR
    subgraph Planning
        START --> TODO
        TODO --> PLANNED
        TODO --> REJECT
        REJECT --> TODO
    end
    subgraph Development
        PLANNED --> DEV_IN_PROGRESS
        DEV_IN_PROGRESS <--> WAITING_FEEDBACK
        DEV_IN_PROGRESS --> DEV_DONE
    end
    subgraph QA
        DEV_DONE --> READY_FOR_QA
        READY_FOR_QA --> QA_IN_PROGRESS
        QA_IN_PROGRESS <--> WAITING_FEEDBACK
        QA_IN_PROGRESS --> READY_FOR_CS
    end
    subgraph Customer Review
        READY_FOR_CS --> CUSTOMER_REVIEW
        CUSTOMER_REVIEW --> DONE
    end
    subgraph Overdue
        OVERDUE --> PLANNED
        OVERDUE --> READY_FOR_QA
        OVERDUE --> READY_FOR_CS
    end
```

- **TODO**: CS tạo một yêu cầu mới.
- **PLAN**: CS chuyển yêu cầu đã tạo cho nhóm phát triển để tiến hành.
- **DEV_IN_PROGRESS**: Nhóm phát triển nhận yêu cầu và bắt đầu phát triển mã nguồn.
- **DEV_DONE**: Nhóm phát triển đã hoàn thành phát triển mã nguồn, nhưng chưa hoàn thành các công việc liên quan đến build ứng dụng hoặc môi trường test.
- **READY_FOR_QA**: Cập nhật các thông tin để test như ứng dụng, môi trường... Và sẵn sàng quá trình kiểm thử của Quality Assurance (QA).
- **QA_IN_PROGRESS**: Nhóm QA bắt đầu xử lý yêu cầu
- **READY_FOR_CS**: Yêu cầu đã sẵn sàng cho CS để verify lại, sau đó gửi Bank.
- **CS_IN_PROGRESS**: Nhóm CS bắt đầu xử lý yêu cầu
- **WAITING_FEEDBACK**: Nếu có bất kỳ vấn đề nào không rõ ràng trong quá trình phát triển, SD sẽ yêu cầu thêm thông tin từ CS.
- **OVERDUE**: Công việc bị trễ hạn và gán về lại cho người trước đó.
- **TO_VALIDATE**: QA đã xong quá trình kiểm thử và chuyển cho CS để chuyển cho khách hàng.




**Work Flow For `Internal task`**

```mermaid
flowchart LR   
     START-->|Create|TODO           
     TODO --> |Select for sprint|PLANNED          
     PLANNED --> |Start|IN_PROGRESS          
     IN_PROGRESS --> |To validate|TO_VALIDATE
     TO_VALIDATE --> |Validate Fail|PLANNED
     TO_VALIDATE --> |Valified|Done
     ALL --> OVERDUE
     OVERDUE --> PLANNED
     OVERDUE  --> TO_VALIDATE   
```

- **TODO**: Nội bộ tạo một yêu cầu mới.
- **PLAN**: Yêu cầu được đưa vào kế hoạch chuẩn bị làm.
- **IN_PROGRESS**: Yêu cầu đang được làm.
- **OVERDUE**: Công việc bị trễ hạn và gán về lại cho người trước đó.
- **TO_VALIDATE**: Yêu cầu được kiểm tra nội bộ đã đạt yêu cầu và đóng.

## **Các Board**

Tất cả các task sẽ được raise chung trên 1 project trên Jira. Tuy nhiên mỗi bộ phận sẽ có các board riêng theo trạng thái của từng bộ phận

| Board        |  Link           |
|-------------------|----------------------- |
|`DEV`             |  [https://bccardvn.atlassian.net/jira/software/c/projects/ITB/boards/78](https://bccardvn.atlassian.net/jira/software/c/projects/ITB/boards/78)    |
|`QA`             |  [https://bccardvn.atlassian.net/jira/software/c/projects/ITB/boards/80](https://bccardvn.atlassian.net/jira/software/c/projects/ITB/boards/80)    |
|`CS`             |  [https://bccardvn.atlassian.net/jira/software/c/projects/ITB/boards/81](https://bccardvn.atlassian.net/jira/software/c/projects/ITB/boards/81)    |

## **Phân loại mức độ ưu tiên của lỗi**

Trong quá trình xử lý lỗi, việc phân loại và ưu tiên các lỗi là rất quan trọng để đảm bảo rằng các vấn đề quan trọng nhất được giải quyết đầu tiên. Dưới đây là hướng dẫn về cách phân loại mức độ ưu tiên của lỗi:


### Mức độ ưu tiên

#### 1. Highest

- **Đặc điểm**:
    - Lỗi có ảnh hưởng nghiêm trọng và nguy hiểm đến hệ thống, dữ liệu hoặc an ninh.
    - Làm gián đoạn hoạt động kinh doanh hoặc gây mất mát tài chính lớn cho các bên liên quan.

- **Hướng dẫn**:
    - Ưu tiên cao nhất trong việc giải quyết và triển khai bản vá.
    - Liên hệ ngay với các bộ phận liên quan để triển khai biện pháp khẩn cấp.

#### 2. High

- **Đặc điểm**:
    - Lỗi gây ra sự không ổn định hoặc gián đoạn trong hoạt động hệ thống, dịch vụ.
    - Có tiềm năng gây mất mát tài chính hoặc uy tín.

- **Hướng dẫn**:
    - Ưu tiên cao trong việc giải quyết lỗi và triển khai bản vá.
    - Cần giải quyết ngay sau khi phát hiện để tránh tác động tiêu cực đến người dùng và doanh nghiệp.

#### 3. Medium

- **Đặc điểm**:
    - Lỗi gây ra khó khăn hoặc không thuận tiện cho người dùng, nhưng không làm gián đoạn hoạt động chính của hệ thống.
    - Có thể có ảnh hưởng nhỏ đến trải nghiệm người dùng hoặc hiệu suất hệ thống.

- **Hướng dẫn**:
    - Xác định và giải quyết lỗi trong thời gian hợp lý, không gấp gáp nhưng cũng không chậm trễ.
    - Ưu tiên cao trong việc giải quyết sau khi hoàn thành các nhiệm vụ ưu tiên cao hơn.

#### 4. Low

- **Đặc điểm**:
    - Lỗi không ảnh hưởng đến hoạt động chính của hệ thống hoặc trải nghiệm người dùng.
    - Có thể xử lý trong thời gian không gấp gáp.

- **Hướng dẫn**:
    - Xác định và giải quyết lỗi trong thời gian hợp lý, có thể chờ đợi cho đến khi các ưu tiên cao hơn được xử lý.
    - Triển khai các bản vá và cải tiến khi có thể, nhưng không cần phải ưu tiên cao.

#### 5. Lowest

- **Đặc điểm**:
    - Lỗi có ảnh hưởng rất nhỏ hoặc không đáng kể đối với hoạt động của hệ thống hoặc trải nghiệm người dùng.

- **Hướng dẫn**:
    - Xác định và giải quyết lỗi khi có thể, nhưng không cần phải ưu tiên cao.
    - Có thể chờ đợi để giải quyết sau khi các ưu tiên cao hơn được xử lý.

