# **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ý.
Sign in with Wallet
Connect another wallet