# 🐛 BUG LIFE CYCLE CHECKLIST — QA Tester Fresher

> **Mục đích:** Theo dõi và xử lý bug đúng quy trình từ A → Z
> **Cập nhật:** Dùng hàng ngày, in ra hoặc copy vào Notion/Confluence
> **Đối tượng:** QA Tester Fresher & Junior

---

## 📋 THÔNG TIN BUG

| Trường | Nội dung |
|---|---|
| **Bug ID** | \_\_\_\_\_\_\_\_\_\_\_ |
| **Tên Bug** | \_\_\_\_\_\_\_\_\_\_\_ |
| **Ngày phát hiện** | \_\_\_\_\_\_\_\_\_\_\_ |
| **Tester phụ trách** | \_\_\_\_\_\_\_\_\_\_\_ |
| **Dev được assign** | \_\_\_\_\_\_\_\_\_\_\_ |
| **Sprint / Release** | \_\_\_\_\_\_\_\_\_\_\_ |

---

---

# BƯỚC 1 — ✍️ VIẾT BUG REPORT ĐỦ THÔNG TIN

> ⏱️ **Thời gian mục tiêu:** Hoàn thành trong vòng **30 phút** kể từ khi phát hiện bug

---

## ☑️ Checklist Bước 1

### 📌 Tiêu đề Bug (Title)

- [ ] Tiêu đề **ngắn gọn, rõ ràng**, phản ánh đúng vấn đề
- [ ] Tuân theo format: **`[Module] + Hành động + Kết quả sai`**
- [ ] **Không** dùng tiêu đề mơ hồ kiểu *"Bị lỗi"*, *"Không chạy được"*
- [ ] Tiêu đề đọc xong có thể hiểu ngay mà **không cần đọc thêm**

```
✅ ĐÚNG:  [Login] Nhập đúng email/password vẫn hiển thị "Sai mật khẩu"
❌ SAI:   Login bị lỗi
❌ SAI:   Không đăng nhập được
```

---

### 🔢 Bước Tái Hiện (Steps to Reproduce)

- [ ] Liệt kê **từng bước theo thứ tự số** (1, 2, 3...)
- [ ] Mỗi bước chỉ mô tả **1 hành động duy nhất**
- [ ] Ghi rõ **dữ liệu test cụ thể** (email, password, số lượng...)
- [ ] Bước đầu tiên phải ghi rõ **điểm bắt đầu** (URL, màn hình nào)
- [ ] Bước cuối cùng là bước **trigger ra bug**
- [ ] **Bạn khác đọc và làm theo** có tái hiện được không? → Tự kiểm tra lại

```
✅ VÍ DỤ ĐÚNG:
1. Mở trình duyệt Chrome, truy cập https://app.example.com/login
2. Nhập Email: test@gmail.com
3. Nhập Password: Test@123456
4. Click button [Đăng nhập]
5. Quan sát kết quả hiển thị trên màn hình

❌ VÍ DỤ SAI:
1. Mở app
2. Đăng nhập với thông tin đúng
3. Bị lỗi
```

---

### 🎯 Expected Result vs Actual Result

- [ ] **Expected Result:** Ghi đúng theo requirement/spec (không phỏng đoán)
- [ ] **Actual Result:** Mô tả chính xác những gì **thực tế xảy ra**
- [ ] Hai mục này **phải khác nhau rõ ràng** — nếu giống nhau thì không phải bug
- [ ] Actual Result có thể kèm **error message cụ thể** (copy nguyên văn)
- [ ] Không dùng từ cảm tính: *"kỳ lạ"*, *"sai sai"*, *"hình như"*

```
✅ ĐÚNG:
Expected: Hệ thống hiển thị thông báo "Đăng nhập thành công" 
          và chuyển hướng đến Dashboard
Actual:   Hệ thống hiển thị popup lỗi "Invalid credentials" 
          mặc dù thông tin đăng nhập chính xác

❌ SAI:
Expected: Đăng nhập được
Actual:   Không đăng nhập được, bị lỗi gì đó
```

---

### 🖥️ Môi Trường (Environment)

- [ ] **OS:** Windows 10/11, macOS Ventura, Ubuntu... (ghi rõ version)
- [ ] **Browser:** Chrome 120, Firefox 121, Safari 17... (ghi rõ version)
- [ ] **App Version / Build:** v2.3.1, Build #445...
- [ ] **Device:** (nếu mobile) iPhone 14 Pro, Samsung S23...
- [ ] **Test Environment:** DEV / STAGING / UAT / PRODUCTION
- [ ] **Tài khoản test:** user role gì (admin, user thường, guest...)
- [ ] **Network:** WiFi, 3G, hay điều kiện đặc biệt nào không

```
📋 TEMPLATE MÔI TRƯỜNG:
- OS: Windows 11 Home (22H2)
- Browser: Google Chrome 120.0.6099.130
- App Version: v2.3.1 (Build #445)
- Environment: Staging
- Test Account: user_test@gmail.com (Role: Standard User)
- Network: WiFi office
```

---

### 📸 Screenshot / Video

- [ ] **Chụp screenshot** màn hình hiển thị lỗi rõ ràng
- [ ] Screenshot có **highlight/khoanh đỏ** vào vùng lỗi
- [ ] Nếu bug là **flow nhiều bước** → quay video (Loom, OBS...)
- [ ] Nếu có **error log** → attach file log hoặc paste vào bug report
- [ ] Screenshot được **đặt tên có nghĩa**: `BUG-123_login_error.png`
- [ ] **Không** chụp màn hình mờ, cắt mất nội dung quan trọng

---

> ### ⚠️ GHI CHÚ QUAN TRỌNG — BƯỚC 1
>
> 💡 **Tip 1:** Trước khi viết bug, **tái hiện lại ít nhất 2-3 lần** để chắc chắn bug không phải do thao tác sai của bạn
>
> 💡 **Tip 2:** Kiểm tra **bug đó đã được report chưa** (search Jira) trước khi tạo mới → tránh duplicate
>
> 💡 **Tip 3:** Nếu bug **không tái hiện được 100%**, ghi rõ *"Tái hiện được 3/5 lần"* và mô tả điều kiện
>
> 💡 **Tip 4:** **Đừng tự suy luận nguyên nhân** trong bug report — chỉ mô tả những gì quan sát được. Phần nguyên nhân để dev phân tích
>
> ⛔ **Lỗi phổ biến của Fresher:** Viết bug report qua loa vì nghĩ "dev sẽ hỏi thêm" → Làm mất thời gian cả team

---
---

# BƯỚC 2 — 🏷️ SET ĐÚNG SEVERITY VÀ PRIORITY

> ⏱️ **Thời gian mục tiêu:** Quyết định trong **5-10 phút**, nếu không chắc → hỏi ngay Senior/Lead QA

---

## 🔴 Severity — Mức Độ Nghiêm Trọng Về Kỹ Thuật

> *"Bug này ảnh hưởng đến hệ thống nặng đến đâu?"*

| Level | Tên | Khi nào dùng | Ví dụ |
|---|---|---|---|
| S1 | **Critical** | App crash, data mất, không dùng được | Crash khi mở app, mất data user |
| S2 | **Major** | Tính năng chính bị hỏng hoàn toàn | Không checkout được, không login được |
| S3 | **Minor** | Tính năng hoạt động nhưng sai một phần | Filter sai kết quả, tính tiền sai |
| S4 | **Trivial** | Lỗi nhỏ, UI/UX, typo | Sai font, lệch 2px, typo trong text |

---

## 🔵 Priority — Mức Độ Ưu Tiên Về Nghiệp Vụ

> *"Bug này cần fix gấp đến đâu?"*

| Level | Tên | Khi nào dùng |
|---|---|---|
| P1 | **Urgent** | Fix ngay lập tức, ảnh hưởng production |
| P2 | **High** | Fix trong sprint hiện tại, blockers |
| P3 | **Medium** | Fix trong 1-2 sprint tới |
| P4 | **Low** | Fix khi có thời gian, nice-to-have |

---

## ☑️ Checklist Bước 2

- [ ] Đã xác định **Severity** (S1/S2/S3/S4) dựa trên kỹ thuật
- [ ] Đã xác định **Priority** (P1/P2/P3/P4) dựa trên business impact
- [ ] Hiểu rõ **Severity ≠ Priority** và set 2 trường này độc lập
- [ ] Nếu bug **Severity thấp nhưng Priority cao** → đã có lý do rõ ràng
- [ ] Nếu không chắc → **đã hỏi Senior QA hoặc PM** trước khi submit

```
📊 BẢNG QUYẾT ĐỊNH NHANH:

Severity\Priority  | Business Critical | Normal | Minor
S1 Critical        |   P1 Urgent       |   P1   |  P2
S2 Major           |   P1 Urgent       |   P2   |  P2
S3 Minor           |   P2 High         |   P3   |  P3
S4 Trivial         |   P3 Medium       |   P4   |  P4

⚡ CASE ĐẶC BIỆT:
- Typo trên button "Mua ngay" của homepage → S4 nhưng P2 (business)
- Crash tính năng ẩn hiếm dùng → S1 nhưng P3 (ít user impact)
```

---

> ### ⚠️ GHI CHÚ QUAN TRỌNG — BƯỚC 2
>
> 💡 **Tip 1:** Severity do **QA quyết định** (technical), Priority do **PM/Lead quyết định** (business) — bạn có thể đề xuất Priority nhưng PM có quyền thay đổi
>
> 💡 **Tip 2:** **Đừng set tất cả là Critical/Urgent** — "Cry wolf" làm team mất tin tưởng vào đánh giá của bạn
>
> 💡 **Tip 3:** **Đừng set tất cả là Minor/Low** vì ngại conflict — bảo vệ chất lượng là trách nhiệm của QA
>
> ⛔ **Lỗi phổ biến của Fresher:** Nhầm lẫn Severity với Priority, set cả 2 đều cao hoặc đều thấp theo cảm tính

---
---

# BƯỚC 3 — 📤 SUBMIT VÀ THEO DÕI TRẠNG THÁI

> ⏱️ **Thời gian mục tiêu:** Submit trong **1 giờ** sau khi phát hiện bug. Check trạng thái **2 lần/ngày**

---

## 📊 Bug Status Flow (Jira)

```
[NEW] → [OPEN] → [ASSIGNED] → [IN PROGRESS] → [FIXED] → [RETEST] → [CLOSED]
                                    ↓                         ↓
                               [REJECTED]              [REOPENED]
                                    ↓
                              [CANNOT REPRODUCE]
```

---

## ☑️ Checklist Bước 3

### Khi Submit

- [ ] Bug report đã **hoàn chỉnh** (đã xong Bước 1 & 2)
- [ ] Đã **assign đúng người** (dev lead hoặc theo quy trình team)
- [ ] Đã set **đúng component/module** trong Jira
- [ ] Đã **link** với Story/Task/Epic liên quan (nếu có)
- [ ] Đã add **label** phù hợp (regression, ui, api, performance...)
- [ ] Bug nằm trong **đúng Sprint** hoặc Backlog theo quy định team
- [ ] Đã **notify** cho người liên quan (tag trong comment hoặc Slack)

### Sau Khi Submit — Theo Dõi Hàng Ngày

- [ ] Kiểm tra Jira **buổi sáng** (9h) để xem status update
- [ ] Kiểm tra Jira **buổi chiều** (14h-15h) trước daily sync
- [ ] Nếu sau **24h chưa được Assigned** → escalate lên QA Lead/PM
- [ ] Nếu bug bị **chuyển sang Rejected** → đọc comment và phản hồi
- [ ] Nếu bug bị **"Cannot Reproduce"** → chuẩn bị demo hoặc thêm thông tin
- [ ] Ghi chú tracking vào **bug tracking sheet** của team (nếu có)

---

## 📋 Tracking Sheet Gợi Ý

| Bug ID | Tên bug | Submit date | Status hiện tại | Dev xử lý | Ngày dự kiến fix | Ghi chú |
|---|---|---|---|---|---|---|
| BUG-001 | | | | | | |
| BUG-002 | | | | | | |

---

> ### ⚠️ GHI CHÚ QUAN TRỌNG — BƯỚC 3
>
> 💡 **Tip 1:** **Đừng submit xong là quên** — bug report của bạn là trách nhiệm của bạn đến khi nó Closed
>
> 💡 **Tip 2:** Nếu bug bị **Rejected không có lý do** → đừng im lặng, yêu cầu dev giải thích trong Jira comment (lịch sự, chuyên nghiệp)
>
> 💡 **Tip 3:** Giữ **một danh sách cá nhân** các bug bạn đang mở — đừng phụ thuộc hoàn toàn vào filter Jira của người khác
>
> ⛔ **Lỗi phổ biến của Fresher:** Submit bug xong không theo dõi, đến khi PM hỏi mới biết bug vẫn đang Open từ 2 tuần trước

---
---

# BƯỚC 4 — 💬 PHẢN HỒI DEV TRONG 2-4 GIỜ

> ⏱️ **SLA mục tiêu:** Mọi câu hỏi/yêu cầu từ dev phải được phản hồi trong **tối đa 4 giờ** (trong giờ làm việc)

---

## ☑️ Checklist Bước 4

### Khi Dev Hỏi/Tag Bạn

- [ ] **Set notification** Jira để nhận alert khi có mention/comment
- [ ] Check Jira và Slack **ít nhất mỗi 2 tiếng** trong giờ làm
- [ ] Khi nhận câu hỏi từ dev → **đọc kỹ** trước khi trả lời
- [ ] Trả lời **cụ thể, có dẫn chứng** — không trả lời chung chung
- [ ] Nếu cần thời gian kiểm tra → **báo trước** ETA cho dev

### Các Tình Huống Thường Gặp

- [ ] **Dev hỏi "tái hiện như thế nào?"**
  - Cung cấp thêm video hoặc step chi tiết hơn
  - Offer ngồi cùng demo trực tiếp nếu cần

- [ ] **Dev nói "Tôi không tái hiện được"**
  - Kiểm tra lại môi trường (dev đang test ở đâu?)
  - Cung cấp thêm thông tin môi trường
  - Thử tái hiện cùng nhau (pair debugging)

- [ ] **Dev nói "Đây không phải bug, là theo design"**
  - Yêu cầu link tới spec/requirement
  - Nếu không có spec → escalate lên PM để làm rõ
  - **Không tự ý đóng bug** khi chưa có xác nhận từ PM

- [ ] **Dev nói "Sẽ fix sau"**
  - Hỏi rõ timeline cụ thể
  - Update Priority conversation với PM nếu cần

### Cách Viết Comment Chuyên Nghiệp Trong Jira

- [ ] Comment **có ngày giờ** rõ ràng trong context
- [ ] Dùng **@mention** đúng người cần đọc
- [ ] Giọng văn **lịch sự, khách quan** — không cảm tính
- [ ] Kết thúc comment bằng **câu hỏi/action item** rõ ràng

```
✅ VÍ DỤ COMMENT TỐT:
"Hi @dev_name, cảm ơn bạn đã check. Mình vừa test lại 
trên Chrome 120 + Staging env (account: test@gmail.com) 
và vẫn tái hiện được. Mình đã attach thêm video ở trên. 
Bạn có muốn mình ngồi cùng reproduce không? 
Available từ 2h-3h chiều nay."

❌ VÍ DỤ COMMENT TỆ:
"Bug vẫn còn đó, bạn check lại đi."
```

---

> ### ⚠️ GHI CHÚ QUAN TRỌNG — BƯỚC 4
>
> 💡 **Tip 1:** **Phản hồi nhanh = tôn trọng thời gian của dev** = build trust trong team. Đây là yếu tố cực kỳ quan trọng với Fresher
>
> 💡 **Tip 2:** Nếu bạn đang bận/họp → **comment ngắn báo trước**: *"Mình đang họp, sẽ phản hồi sau 30 phút"*
>
> 💡 **Tip 3:** Mọi trao đổi về bug → **comment trong Jira** (không chỉ qua Slack/chat riêng) để có lịch sử rõ ràng
>
> 💡 **Tip 4:** Giữ thái độ **collaborative, không adversarial** — QA và Dev cùng mục tiêu là ship sản phẩm tốt
>
> ⛔ **Lỗi phổ biến của Fresher:** Để dev chờ cả ngày, hoặc trao đổi qua Slack rồi không update vào Jira → mất context

---
---

# BƯỚC 5 — 🔁 RETEST KHI BUG ĐƯỢC FIXED

> ⏱️ **Thời gian mục tiêu:** Bắt đầu retest trong **2-4 giờ** sau khi nhận thông báo Fixed. Hoàn thành retest trong **4-8 giờ**

---

## ☑️ Checklist Bước 5

### Chuẩn Bị Trước Khi Retest

- [ ] Xác nhận **build/version mới** đã được deploy lên test environment
- [ ] **Đọc lại comment** của dev — họ đã fix bằng cách nào?
- [ ] Xác nhận **đúng environment** để retest (đừng test nhầm môi trường cũ)
- [ ] **Clear cache/cookies** trình duyệt trước khi test
- [ ] Chuẩn bị **test data** cần thiết
- [ ] Đọc lại **bug report gốc** để nhớ đúng expected behavior

---

### ✅ Test Lại Đúng Steps Gốc (Happy Path)

- [ ] Thực hiện **từng bước tái hiện** y hệt như trong bug report
- [ ] Dùng **đúng môi trường đã ghi** trong bug report (hoặc ghi rõ nếu đổi)
- [ ] Verify **Expected Result** đã xuất hiện đúng như yêu cầu
- [ ] Bug gốc **đã không còn tái hiện**
- [ ] Chụp screenshot **sau khi fix** để làm bằng chứng

---

### 🔍 Test Edge Cases — Các Trường Hợp Biên

- [ ] Test với **input tối thiểu** (min value, empty string, 1 ký tự...)
- [ ] Test với **input tối đa** (max length, max value, string rất dài...)
- [ ] Test với **dữ liệu đặc biệt** (ký tự đặc biệt, emoji, tiếng Việt có dấu...)
- [ ] Test với **multiple users** hoặc **multiple sessions** (nếu liên quan)
- [ ] Test trên **browser khác** (nếu bug liên quan UI/JS)
- [ ] Test **negative case** — nhập sai rồi sửa lại, flow ngắt giữa chừng
- [ ] Test kết hợp với **các tính năng liên quan** khác

```
📋 EDGE CASE CHECKLIST THEO LOẠI BUG:

🔐 Login/Auth bugs:
□ Đúng credentials
□ Sai password
□ Email không tồn tại
□ Account bị lock
□ Sau khi reset password
□ Session expire

💰 Calculation bugs:
□ Số 0
□ Số âm
□ Số thập phân
□ Số rất lớn
□ Kết hợp nhiều discount

📝 Form/Input bugs:
□ Trống hoàn toàn
□ Chỉ spaces
□ Max length + 1 ký tự
□ Script injection: <script>alert(1)</script>
□ SQL injection: ' OR 1=1 --
□ Ký tự đặc biệt: !@#$%^&*()
```

---

### 🔄 Regression Testing — Kiểm Tra Không Phá Gì Khác

- [ ] Test **các tính năng liền kề** với phần đã được fix
- [ ] Test **happy flow chính** của module liên quan
- [ ] Test **tính năng phụ thuộc** vào component đã fix
- [ ] Kiểm tra **các bug đã Closed trước đó** không bị reopen

```
📊 SCOPE REGRESSION — QUY TẮC THUMB:

Fix ở Login     → Test: Logout, Remember me, SSO, Forgot password
Fix ở Cart      → Test: Checkout, Payment, Order history, Inventory
Fix ở API       → Test: Tất cả feature call API đó
Fix ở Database  → Test: Toàn bộ CRUD operations liên quan
Fix ở UI/CSS    → Test: Responsive, Dark mode, Print view
```

---

> ### ⚠️ GHI CHÚ QUAN TRỌNG — BƯỚC 5
>
> 💡 **Tip 1:** Nếu retest **PASS** → tiếp tục sang Bước 6
>
> 💡 **Tip 2:** Nếu retest **FAIL** (bug vẫn còn) → **đừng mở bug mới**, đổi status về **"Reopened"** và comment chi tiết
>
> 💡 **Tip 3:** Nếu retest phát hiện **bug mới liên quan** → **tạo bug report mới**, không nhồi vào bug cũ
>
> 💡 **Tip 4:** **Ghi lại thời gian retest** — nếu cần proof, bạn có timestamp rõ ràng
>
> ⛔ **Lỗi phổ biến của Fresher:** Chỉ test đúng step gốc, bỏ qua edge case và regression → Ship bug mới lên production

---
---

# BƯỚC 6 — 📝 COMMENT KẾT QUẢ RETEST VÀO JIRA

> ⏱️ **Thời gian mục tiêu:** Comment **ngay lập tức** sau khi hoàn thành retest

---

## ☑️ Checklist Bước 6

### Thông Tin Bắt Buộc Trong Comment

- [ ] **Kết quả tổng thể:** PASS hoặc FAIL (viết to, dễ thấy)
- [ ] **Ngày giờ retest** cụ thể
- [ ] **Tester thực hiện** (tên bạn)
- [ ] **Build/Version** đã test
- [ ] **Environment** đã test
- [ ] **Steps đã thực hiện** (tóm tắt hoặc link tới test case)
- [ ] **Screenshot/Video** kết quả sau fix
- [ ] **Edge cases đã test** (liệt kê ngắn gọn)
- [ ] **Regression scope đã test** (liệt kê ngắn gọn)
- [ ] Nếu FAIL: **Mô tả rõ** bug vẫn còn như thế nào

---

## 📋 Template Comment Retest

```markdown
## 🔁 RETEST RESULT

**Kết quả:** ✅ PASS / ❌ FAIL  ← (xóa cái không dùng)
**Ngày retest:** DD/MM/YYYY — HH:MM
**Tester:** [Tên bạn]
**Build/Version:** v2.3.2 (Build #446)
**Environment:** Staging

---

### ✅ Test Steps (Happy Path)
Đã thực hiện lại toàn bộ steps trong bug report gốc.
→ Kết quả: BUG ĐÃ ĐƯỢC FIX / VẪN CÒN LỖI

### 🔍 Edge Cases Đã Test
- [ ] [Mô tả edge case 1] → PASS/FAIL
- [ ] [Mô tả edge case 2] → PASS/FAIL
- [ ] [Mô tả edge case 3] → PASS/FAIL

### 🔄 Regression Test
- [ ] [Tính năng liên quan 1] → PASS/FAIL
- [ ] [Tính năng liên quan 2] → PASS/FAIL

### 📸 Evidence
[Attach screenshot/video tại đây]

---
**Action tiếp theo:** 
- Nếu PASS → Chuyển sang Verified/Closed
- Nếu FAIL → Bug Reopened, cần fix lại
```

---

### Ví Dụ Comment PASS Thực Tế

```
## 🔁 RETEST RESULT

**Kết quả:** ✅ PASS
**Ngày retest:** 15/01/2024 — 14:30
**Tester:** Nguyen Van A
**Build:** v2.3.2 (Build #446)
**Environment:** Staging

Bug gốc (không login được dù đúng thông tin) đã được fix.
Đã test lại toàn bộ steps: user login thành công, 
chuyển hướng về Dashboard đúng.

Edge cases OK:
- Login với email có chữ hoa → PASS
- Login sau khi reset password → PASS  
- Login sau 5 lần nhập sai → PASS (lock account đúng)

Regression OK:
- Logout/Login lại → PASS
- Remember me → PASS
- SSO Google → PASS

[Screenshot attached: BUG-123_retest_pass.png]

→ Chuyển status sang VERIFIED. Đề xuất CLOSE.
```

---

### Ví Dụ Comment FAIL Thực Tế

```
## 🔁 RETEST RESULT

**Kết quả:** ❌ FAIL — BUG VẪN CÒN
**Ngày retest:** 15/01/2024 — 14:30
**Tester:** Nguyen Van A
**Build:** v2.3.2 (Build #446)
**Environment:** Staging

Bug gốc VẪN tái hiện được:
1. Thực hiện steps 1-4 như bug report gốc
2. Kết quả: VẪN hiển thị "Invalid credentials" 
   (xem screenshot đính kèm)

⚠️ Lưu ý thêm: Bug chỉ xảy ra với email có ký tự "+"
   VD: test+01@gmail.com → FAIL
   VD: test@gmail.com → PASS (có thể fix một phần?)

[Screenshot: BUG-123_retest_fail.png]
[Video: BUG-123_retest_video.mp4]

@dev_name: Đang Reopen bug này. Bạn có thể check lại không?
Available để pair debug: sáng mai 9h-10h.
```

---

> ### ⚠️ GHI CHÚ QUAN TRỌNG — BƯỚC 6
>
> 💡 **Tip 1:** Comment retest là **bằng chứng pháp lý** trong dự án — viết đủ để người vào sau hiểu ngay mà không cần hỏi
>
> 💡 **Tip 2:** **Luôn attach evidence** dù bug PASS — không có hình thì như không có test
>
> 💡 **Tip 3:** Nếu FAIL → **Đổi status sang "Reopened"** và tag dev ngay, đừng để bug nằm im trạng thái "Fixed"
>
> 💡 **Tip 4:** Dùng **emoji và format rõ ràng** — comment dễ đọc = team yêu bạn hơn
>
> ⛔ **Lỗi phổ biến của Fresher:** Comment vắn tắt "đã test OK" mà không có evidence, không ghi version, không ghi scope → vô nghĩa khi cần audit

---
---

# BƯỚC 7 — ✅ VERIFY VÀ CLOSE BUG

> ⏱️ **Thời gian mục tiêu:** Close bug trong **24 giờ** sau khi retest PASS

---

## 📊 Điều Kiện Để Close Bug

```
Bug được CLOSE khi tất cả điều kiện sau đều TRUE:

✅ 1. Bug gốc không còn tái hiện
✅ 2. Expected Result đã đúng như requirement
✅ 3. Edge cases quan trọng đều PASS
✅ 4. Không có regression mới phát sinh
✅ 5. Comment retest đã đầy đủ + có evidence
✅ 6. (Nếu team yêu cầu) QA Lead đã review và approve
```

---

## ☑️ Checklist Bước 7

### Verify (Xác Nhận Cuối Cùng)

- [ ] Đọc lại **toàn bộ bug report** từ đầu đến cuối
- [ ] Đối chiếu kết quả với **requirement/acceptance criteria** gốc
- [ ] Xác nhận **không có side effect** mới từ việc fix
- [ ] Verify trên **ít nhất 2 môi trường** nếu bug là critical (S1/S2)
- [ ] Nếu bug liên quan **production** → verify cả trên prod sau khi deploy

### Close Bug Trong Jira

- [ ] Đổi status từ **"Retest" → "Verified" → "Closed"** (theo flow của team)
- [ ] **Resolution** được set đúng:
  - `Fixed` — Bug đã fix và verified
  - `Won't Fix` — Đồng ý không fix (có lý do)
  - `Duplicate` — Trùng bug khác
  - `Cannot Reproduce` — Không tái hiện được
  - `By Design` — Đúng là behavior mong muốn
- [ ] **Close date** được ghi nhận tự động hoặc update thủ công
- [ ] Notify cho **dev và PM** biết bug đã closed (comment hoặc Slack)
- [ ] Update **bug tracking sheet** của team

### Sau Khi Close

- [ ] Xem xét **thêm vào Regression Test Suite** nếu bug này quan trọng
- [ ] Viết/update **Test Case** để cover scenario này lần sau
- [ ] Ghi chú vào **learning log** cá nhân (bạn học được gì từ bug này?)

---

## 📊 Tổng Kết Lifecycle — Khi Nào Thì Kết Thúc?

```
BUG STATUS CUỐI CÙNG:

✅ CLOSED      → Bug fix thành công, verified OK
✅ CLOSED      → Duplicate (link tới bug chính)  
✅ CLOSED      → Won't Fix (PM đã approve, có documented reason)
✅ CLOSED      → By Design (PM/BA xác nhận là đúng behavior)
✅ CLOSED      → Cannot Reproduce sau 3+ lần thử

❌ KHÔNG close khi:
- Bug vẫn còn nhưng dev nói "sẽ fix sprint sau"
- Chưa có comment retest đầy đủ
- Chưa test edge cases
```

---

> ### ⚠️ GHI CHÚ QUAN TRỌNG — BƯỚC 7
>
> 💡 **Tip 1:** **Bạn là người Close bug** — không phải dev. Dev chỉ fix và set "Fixed", QA verify và set "Closed"
>
> 💡 **Tip 2:** Nếu bug bị Close với Resolution "By Design" hoặc "Won't Fix" nhưng bạn không đồng ý → **escalate lên QA Lead/PM**, đừng tự Close rồi im lặng
>
> 💡 **Tip 3:** Một bug được Close không có nghĩa là **xóa khỏi tầm nhớ** — hãy nhớ nó khi viết regression test
>
> 💡 **Tip 4:** Sau mỗi sprint/release, review **tất cả bug bạn đã close** — đây là cách học nhanh nhất để hiểu sản phẩm
>
> ⛔ **Lỗi phổ biến của Fresher:** Để dev tự close bug sau khi fix mà không có bước verify của QA → mất kiểm soát chất lượng

---
---

# 📊 TỔNG HỢP — QUICK REFERENCE CARD

> ✂️ **Cắt phần này ra và dán lên bàn làm việc**

---

```
╔══════════════════════════════════════════════════════════════╗
║              BUG LIFE CYCLE — 7 BƯỚC CƠ BẢN                ║
╠══════════════════════════════════════════════════════════════╣
║  BƯỚC 1  │ ✍️  Viết Bug Report    │ ≤ 30 phút              ║
║          │ Title + Steps + Expected/Actual                   ║
║          │ Environment + Screenshot                          ║
╠══════════════════════════════════════════════════════════════╣
║  BƯỚC 2  │ 🏷️  Set Severity+Priority│ 5-10 phút             ║
║          │ S1-S4 (kỹ thuật) + P1-P4 (business)             ║
╠══════════════════════════════════════════════════════════════╣
║  BƯỚC 3  │ 📤 Submit & Theo dõi   │ Submit ≤ 1 giờ         ║
║          │ Check Jira 2 lần/ngày: 9h và 14h                 ║
╠══════════════════════════════════════════════════════════════╣
║  BƯỚC 4  │ 💬 Phản hồi Dev        │ ≤ 4 giờ/lượt           ║
║          │ Comment trong Jira, cụ thể, có evidence           ║
╠══════════════════════════════════════════════════════════════╣
║  BƯỚC 5  │ 🔁 Retest khi Fixed    │ 4-8 giờ                ║
║          │ Steps gốc + Edge Cases + Regression               ║
╠══════════════════════════════════════════════════════════════╣
║  BƯỚC 6  │ 📝 Comment Kết Quả     │ Ngay sau retest         ║
║          │ PASS/FAIL + Version + Env + Screenshot            ║
╠══════════════════════════════════════════════════════════════╣
║  BƯỚC 7  │ ✅ Verify & Close      │ ≤ 24 giờ sau PASS      ║
║          │ QA là người Close, không phải Dev                 ║
╚══════════════════════════════════════════════════════════════╝
```

---

## 🚨 TOP 10 LỖI FRESHER CẦN TRÁNH

| # | Lỗi | Hậu quả |
|---|---|---|
| 1 | Bug title mơ hồ | Dev không hiểu bug là gì |
| 2 | Steps thiếu dữ liệu cụ thể | Không tái hiện được |
| 3 | Quên ghi môi trường | Mất thời gian debug |
| 4 | Set tất cả là Critical | Team mất tin tưởng |
| 5 | Submit xong không theo dõi | Bug nằm im hàng tuần |
| 6 | Phản hồi dev chậm >4h | Block dev, friction trong team |
| 7 | Chỉ test happy path khi retest | Bug quay lại production |
| 8 | Comment retest không có evidence | Không có bằng chứng khi cần |
| 9 | Để dev tự close bug | Mất kiểm soát chất lượng |
| 10 | Không học từ bug đã close | Lặp lại sai lầm tương lai |

---

## ⏱️ SLA Tóm Tắt

| Hoạt động | SLA |
|---|---|
| Viết và submit bug report | ≤ 1 giờ sau phát hiện |
| Phản hồi câu hỏi từ dev | ≤ 4 giờ trong giờ làm |
| Bắt đầu retest sau khi Fixed | ≤ 4 giờ sau thông báo |
| Hoàn thành retest | ≤ 8 giờ sau khi bắt đầu |
| Close bug sau khi PASS | ≤ 24 giờ |
| Escalate bug không được Assign | Sau 24h không có update |

---

## 📖 Glossary Nhanh

| Thuật ngữ | Nghĩa |
|---|---|
| **Severity** | Mức ảnh hưởng kỹ thuật của bug |
| **Priority** | Mức độ cần fix gấp về business |
| **Regression** | Bug cũ bị quay lại sau khi fix bug mới |
| **Edge Case** | Trường hợp biên, điều kiện ngoại lệ |
| **Reopen** | Mở lại bug đã fix vì chưa thực sự fix |
| **Resolution** | Cách thức kết thúc một bug |
| **SLA** | Service Level Agreement — cam kết thời gian |
| **Evidence** | Bằng chứng (screenshot, video, log) |
| **Triage** | Họp phân loại và ưu tiên bug |

---

*📅 Checklist version 1.0 — Cập nhật theo quy trình team của bạn nếu cần*
*💾 Lưu file này vào Notion, Confluence hoặc in ra A4 để dùng hàng ngày*