# Test Strategy

## 1. Mục đích tài liệu

Tài liệu này mô tả chiến lược kiểm thử cho bộ source LDA, bao gồm website public, backend API và admin/CDP. Mục tiêu không chỉ là “mở được trang”, mà là xác nhận hệ thống đủ điều kiện vận hành, release và bàn giao QA.

**Ghi chú:** Test Strategy trả lời câu hỏi “chúng ta kiểm thử theo hướng nào, kiểm ở đâu, kiểm sâu tới mức nào, tiêu chí pass/fail là gì”. Các bước kiểm thử chi tiết nằm ở tài liệu `Test Cases`.

## 2. Phạm vi kiểm thử

| Khu vực | Thành phần | Phạm vi cần kiểm thử | Ghi chú |
|---|---|---|---|
| Website public | `website-v2-master` | Trang chủ, danh mục, sản phẩm, giỏ hàng, thanh toán, tin tức, trang nội dung, SEO, responsive | Đây là phần khách hàng cuối sử dụng, ưu tiên cao nhất cho flow mua hàng |
| Backend API | `website-backend-go-main` | Health, catalog, collection, homepage, product enrichment, SEO, promotions, blog, user, admin routes | Đây là nguồn dữ liệu cho website và admin; cần kiểm schema và lỗi |
| Admin/CDP | `core-ops-frontend-nextjs-main` | Auth, permission, catalog CMS, product enrichment, coupon/voucher, SEO, stocktake, upload, form validation | Đây là phần vận hành; cần kiểm role và mutation kỹ |
| Non-functional | Cả hệ thống | Build, lint, type-check, responsive, accessibility, performance, security, regression | Không phải chức năng cụ thể nhưng quyết định chất lượng release |

## 3. Ngoài phạm vi kiểm thử

| Hạng mục | Lý do |
|---|---|
| Kiểm thử thanh toán thật với cổng thanh toán production | Cần tài khoản/cổng thanh toán và sandbox riêng |
| Kiểm thử ERP production | Backend catalog phụ thuộc `ERP_DB_DSN`; chỉ kiểm khi có DSN và dữ liệu được cấp |
| Kiểm thử tải lớn production | Cần môi trường staging giống production và công cụ load test |
| Kiểm thử bảo mật chuyên sâu như pentest | Nên tách thành vòng security audit riêng |

**Ghi chú:** Các mục ngoài phạm vi không có nghĩa là không quan trọng. Chúng cần được ghi thành risk/open item nếu release phụ thuộc vào chúng.

## 4. Cấp độ kiểm thử

| Cấp độ | Nội dung | Người/nhóm chịu trách nhiệm | Tiêu chí hoàn thành |
|---|---|---|---|
| Unit test | Kiểm logic nhỏ, helper, service, validation | Developer | Test pass trong CI/local |
| API contract test | Kiểm endpoint, schema, status code, validation, auth | QA/Backend | Endpoint chính pass với data hợp lệ và lỗi |
| Integration test | Kiểm FE gọi BE đúng, dữ liệu hiển thị đúng | QA/FE/BE | Không lệch field, không crash khi API lỗi |
| E2E test | Kiểm flow người dùng từ đầu tới cuối | QA | Flow mua hàng/admin chính pass |
| Regression test | Kiểm lại các chức năng không bị phá sau thay đổi | QA | Không còn bug Critical/High |
| Smoke test | Kiểm nhanh app có chạy được không | QA/DevOps | Health/build/route chính pass |

## 5. Loại kiểm thử cần thực hiện

| Loại test | Mục tiêu | Ví dụ trong LDA | Ghi chú |
|---|---|---|---|
| Smoke test | Xác nhận hệ thống chạy được | `/ping`, `/version`, `/`, `/gio-hang`, admin shell | Chạy đầu tiên sau khi setup |
| Functional test | Kiểm chức năng theo nghiệp vụ | Thêm giỏ hàng, tạo coupon, tạo redirect | Cần expected rõ ràng |
| Negative test | Kiểm input sai và case lỗi | Slug không tồn tại, voucher sai, thiếu token | Bắt buộc để tránh crash |
| Permission test | Kiểm role/quyền | QLCH không thấy nút QC, user không token không gọi admin API | Ưu tiên cao vì source đã có report role gating fail |
| Regression test | Kiểm không phá flow cũ | Cart, checkout, catalog, SEO, homepage | Chạy trước release |
| Responsive test | Kiểm layout mobile/tablet/desktop | 375px, 768px, 1440px | Không được overlap CTA |
| Accessibility test | Kiểm keyboard/focus/contrast | Menu, modal, form, checkout | Cần ít nhất mức cơ bản |
| Performance test | Kiểm tốc độ và cache | Homepage bundle, navigation, sitemap | Đặc biệt với API public |
| Security test | Kiểm secret, auth, XSS cơ bản | `.env`, admin mutation, search input | Không thay thế pentest |

## 6. Môi trường kiểm thử

| Môi trường | Mục đích | Cấu hình chính | Ghi chú |
|---|---|---|---|
| Local | Developer/QA kiểm nhanh | Node, pnpm, Go, Docker Postgres | Có thể dùng mock nếu backend chưa sẵn sàng |
| Staging | QA gần production | DB seed ổn định, API thật, config giống production | Nên là môi trường chính để sign-off |
| Production smoke | Kiểm sau deploy | Health, route chính, monitor log | Chỉ smoke, không phá dữ liệu thật |

## 7. Điều kiện dữ liệu test

| Nhóm dữ liệu | Cần có | Mục đích |
|---|---|---|
| Product | Sản phẩm active, out of stock, có discount, có nhiều ảnh, có specs | Kiểm PDP, PLP, cart |
| Collection | Root collection, child collection, collection rỗng, slug sai | Kiểm danh mục, breadcrumb, filter |
| Cart/Checkout | Sản phẩm đủ hàng, hết hàng, voucher hợp lệ/sai/hết hạn | Kiểm checkout và discount |
| SEO | Metadata override, redirect 301, path không redirect, sitemap nhiều trang | Kiểm SEO API và FE |
| Admin User | Admin đủ quyền, user thiếu quyền, token hết hạn | Kiểm permission |
| Stocktake | IMEI match, thiếu, thừa, duplicate, unknown | Kiểm kiểm kê và variance |

## 8. Tiêu chí bắt đầu test

| Điều kiện | Yêu cầu |
|---|---|
| Source | Source đã giải nén/chạy được hoặc có branch rõ ràng |
| Dependency | Cài được dependency FE/BE |
| Config | Có `.env` hoặc mock config rõ ràng |
| Database | DB local/staging có migration và seed tối thiểu |
| Account | Có account admin và account role test |
| Build | Ít nhất app có thể start dev server |

**Ghi chú:** Nếu thiếu điều kiện bắt đầu test, QA vẫn có thể review tài liệu/source nhưng không được kết luận `GO`.

## 9. Tiêu chí kết thúc test

| Điều kiện | Yêu cầu |
|---|---|
| Smoke | Tất cả smoke test pass |
| Core flow | Homepage, PLP, PDP, cart, checkout pass |
| API | Health, catalog, homepage, navigation, SEO pass |
| Admin | Auth, permission, mutation chính pass |
| Bug | Không còn bug Critical/High |
| Evidence | Có screenshot/log/API response cho các flow quan trọng |
| Report | QA Report và QC Gate đã cập nhật |

## 10. Mức độ ưu tiên kiểm thử

| Priority | Ý nghĩa | Ví dụ |
|---|---|---|
| P0 | Blocking release nếu fail | App không build, checkout fail, admin không cần quyền vẫn ghi được data |
| P1 | Rủi ro cao, cần fix trước release | Product price sai, catalog API 500, role QC/KT sai |
| P2 | Có thể conditional nếu có workaround | Một trang nội dung phụ lỗi layout nhẹ |
| P3 | Có thể backlog | Text nhỏ chưa chuẩn, spacing phụ |

## 11. Phân loại severity bug

| Severity | Định nghĩa | Ví dụ |
|---|---|---|
| Critical | Hệ thống không dùng được hoặc mất dữ liệu | Không mở được website, checkout chết, migration làm mất data |
| High | Chức năng chính sai hoặc lỗi quyền | User không quyền vẫn duyệt QC, giá/tổng tiền sai |
| Medium | Ảnh hưởng UX/nghiệp vụ nhưng có workaround | Filter sai trạng thái khi reload, modal mobile bị xấu |
| Low | Lỗi nhỏ, không ảnh hưởng flow chính | Label chưa chuẩn, spacing chưa đều |

## 12. Công cụ khuyến nghị

| Công cụ | Mục đích |
|---|---|
| Browser DevTools | Kiểm console, network, responsive |
| Playwright | E2E, screenshot evidence |
| curl/Postman/Bruno | API contract test |
| pnpm scripts | Build/lint/type-check FE |
| go test | Backend unit/integration test |
| Docker Compose | DB/Redis local |

## 13. Rủi ro hiện tại

| Rủi ro | Mức độ | Cách xử lý |
|---|---|---|
| Website public và backend đều có thể dùng port 3000 | Medium | Quy định port rõ khi test local |
| `website-v2-master` yêu cầu Node >= 24 | Medium | Kiểm Node version trước khi test |
| Backend catalog phụ thuộc ERP DSN | High | Có DSN staging hoặc mark skip có điều kiện |
| Existing stocktake report ghi nhận role gating fail | High | Bắt buộc test lại/fix nếu module stocktake nằm trong release |
| Admin có nhiều mock/fallback | Medium | Tách kết quả mock pass và real integration pass |

## 14. Ghi chú cách sử dụng tài liệu

- Dùng `Test Scenarios` để biết cần kiểm những tình huống nào.
- Dùng `Test Cases` để chạy từng bước và ghi kết quả.
- Dùng `Acceptance Criteria` để xác định chức năng có đạt yêu cầu hay không.
- Dùng `QA Report` để ghi kết quả thực tế.
- Dùng `QC Gate` để kết luận release `GO`, `CONDITIONAL GO` hoặc `NO GO`.