FLYER Product · QA & Chất lượng

Báo cáo chất lượng sản phẩm

Team đã có Automation Tester Leader và Manual Tester — trang này có dashboard sống đọc từ report.flyer.vn (kèm lịch sử tự lưu), đối chiếu coverage với 32 tính năng đã có PRD, và trả lời câu hỏi có check được database bug không.

Phiên bản
2.1
Cập nhật
08/09/2026
Owner
Tùng (Product)
Trạng thái
Dashboard sống + lịch sử tự lưu — lần chạy mới nhất 08/09, có 3 fail trở lại
Cần
Xác minh hồi quy Kiểm tra đầu vào (2 case fail); thêm test cho 10/20 tính năng GV chưa có coverage; bật lại 4 case IELTS đang bị skip
🔗 Đang chạy thậtreport.flyer.vn ↗Kiểm tra từng hệ thống: exam & teacher ↗Allure Report 2.33.0 — Playwright trên production
Tổng quan hệ thống · sống

Tình hình automation test

Đọc trực tiếp từ report.flyer.vn mỗi lần mở trang; mỗi lần chạy mới được lưu lại thành một điểm lịch sử để vẽ xu hướng.

Đang tải…
Theo khu vựcpassed · failed · broken · skipped của lần chạy đang hiển thị
Xu hướng qua các lần chạytỉ lệ pass (%) và số case failed — mỗi điểm là một lần chạy đã lưu

Lỗi đang mở, gộp theo nguyên nhân gốc

Nguyên nhân gốcSố caseKhu vựcAllure xếp loại
Bảng số liệu (table view) & coverage theo spec file
Khu vựcTổngPassedFailedBrokenSkippedPass %
Spec fileTổngPassedFailedSkipped
Lần chạyTổngPassedFailedBrokenSkippedPass %Ghi chú

1Bối cảnh & mục tiêu

Team hiện đã có Automation Tester Leader và Manual Tester, nhưng chưa có một hệ thống báo cáo chất lượng sản phẩm thống nhất để trả lời đều đặn: sản phẩm đang ổn định hay có nhiều bug tồn đọng, team fix bug nhanh hay chậm, automation đang che phủ được bao nhiêu phần trăm rủi ro thật.

Trả lời nhanh Có, xem được tình hình — nhưng không phải bằng một database SQL duy nhất. Phần automation (report.flyer.vn) là dữ liệu JSON có thể gọi trực tiếp qua HTTP, không cần đăng nhập — số liệu ở mục 2 lấy trực tiếp từ đó. Phần bug thủ công track trong Jira là SaaS đa khách hàng, Atlassian không cấp quyền SQL — phải qua JQL filter, REST/GraphQL API, hoặc đồng bộ về một Postgres riêng. Chi tiết ở mục 8.

2report.flyer.vn — tỉ lệ bug

Bảng dashboard ở đầu trang luôn là số mới nhất. Phần này chốt lại lần chạy gần nhất tại thời điểm viết, 08/09/2026, 02:02–02:59 (57 phút) — so sánh với lần liền trước 06/09:

Chỉ sốGiá trịSo với 06/09
Tổng test case416Không đổi. (Trước đó 24/08 → 06/09 đã tăng +118 nhờ bộ Khiên (Shields) 89 case và Study profile/nav 36 case phía học sinh.)
Passed389 · 93,5%−2. Pass rate gần như giữ nguyên (94% → 93,5%), vẫn trên ngưỡng 90%.
Failed (bug thật)3+3, tất cả đều ở phía giáo viên và đều được Allure xếp Product defects — xem bảng ngay dưới.
Broken (lỗi test)0−1. ONBOARDING_138 lần này không còn timeout, nhưng chuyển thành failed vì sai số liệu — tức là lộ ra bug thật thay vì lỗi hạ tầng.
Skipped24 · 6%Không đổi — vẫn gồm toàn bộ 4 case IELTS và 16 case pending-approval (xem cảnh báo).

Ba lỗi của lần chạy 08/09 — đều là Product defects

Test caseThông báo lỗiĐọc là gì
ONBOARDING_138
Teacher walks through the Quick Start milestones
expect(received).toBe(expected) — kỳ vọng 3, nhận về số khác Số mốc Quick Start hoàn thành không khớp. Lần 06/09 case này chỉ broken (timeout 300s), nay chạy được hết nên lộ ra sai số liệu.
PLACEMENT_060
Student can submit placement test and sees result with 3 correct answers (Pre A1)
Placement test should navigate to result page after submit Nộp bài kiểm tra đầu vào xong không chuyển sang trang kết quả.
PLACEMENT_059
Teacher views placement test result after student submits
expect(locator).toBeVisible() thất bại Giáo viên không thấy kết quả sau khi học sinh nộp — cùng gốc với case trên.
Hai trong ba lỗi nằm ở Kiểm tra đầu vào PLACEMENT_059PLACEMENT_060 là hai đầu của cùng một luồng: học sinh nộp bài rồi giáo viên xem kết quả. Cả hai cùng fail nghĩa là bước chuyển sang trang kết quả sau khi nộp đang hỏng, không phải lỗi hiển thị lặt vặt. Đây là tính năng đã được nghiệm thu PASS ngày 03/09 (trang nghiệm thu) — nên nhiều khả năng là hồi quy mới, cần dựng lại thủ công để xác nhận trước khi báo dev.
Skip vẫn đang che mất lỗi 4 case IELTS Guru từng fail 100% ở lần 24/08 (nút "Đăng nhập / Đăng ký" không bấm được) giờ chuyển sang skipped, không phải passed — tức là bị tắt đi chứ chưa được sửa. Kết quả là IELTS hiện không có case nào đang chạy. Ngoài ra 16 case AssignedHomework.pending-approval-approved phía giáo viên cũng đang skip trọn bộ. Cần Automation Lead xác nhận lý do skip và lịch bật lại.

Chuỗi 4 lần chạy đã lưu: 16/08 pass 78% → 24/08 87% → 06/09 94% → 08/09 93,5%; failed 40 → 8 → 0 → 3. Xu hướng dài hạn vẫn tốt (pass rate tăng 15 điểm trong 3 tuần), nhưng chuỗi "0 failed" chỉ giữ được đúng một lần chạy. Mỗi lần chạy mới tự được lưu thành một điểm trong biểu đồ xu hướng ở đầu trang (mục 8 giải thích cơ chế).

3Lượng test case đã đủ chưa

Chưa đủ, nhưng đang tăng đúng hướng. Đối chiếu 416 test case (08/09) với 32 tính năng đã có PRD chi tiết trên roadmap.flyer.vn (20 giáo viên + 12 học sinh): phía học sinh vừa phủ thêm 3 tính năng lớn trong 2 tuần, phía giáo viên vẫn còn một nửa chưa có automation nào chạm tới.

Giáo viên — 200 test case / 20 tính năng đã có PRD

Đã có coverageChưa có coverage nào
Giao bài tự động/bài tập (65 case, 17 đang skip), Quản lý lớp (20), Quản lý kỳ thi (17), Kiểm tra đầu vào (27), Học sinh/chấm điểm chi tiết (34, chấm AI Speaking/Writing chỉ 1–2 case mỗi loại), Báo cáo (15), Trợ giảng AI/Call Bingo (4), Onboarding (7)Khám phá đề, Chương trình học, Tạo đề, Thư viện của tôi, Khen thưởng, Điểm danh, Quà tặng, Thách đấu, Dạy trực tuyến, Tài chính, Thiết lập — 10/20 tính năng, chưa case nào
Đáng chú ý Điểm danh — tính năng vừa làm PRD ở sprint 110 — vẫn chưa có spec test nào; số case giáo viên gần như đứng yên (201 → 200) trong khi học sinh tăng 93 → 212.

Học sinh (exam) — 212 test case / 12 tính năng đã có PRD

Đã có coverageChưa có coverage nào
Làm bài thi (21 + Starters 28), Học tập/Study (36), Kết quả chấm AI / Khiên (89 — mới), Bingo AI (BingoTalk 5 — mới), Nói/Viết AI (qua Shields Speaking/Writing), Tài khoản (auth 32 + Study profile), Trang chủ (1)Bài tập lớp, Gamification, Thách đấu, Kết quả & tiến độ, Gói Premium — 5/12 tính năng, gồm cả Premium (monetization)

IELTS Guru — 4 test case, cả 4 đang skip

Chỉ có login/logout được viết (so với PRD 14 phần, 207.767 lượt làm bài, 28.195 learner thật), và cả 4 hiện đang bị skip sau khi fail ở lần 24/08. Coverage chức năng thực tế của IELTS = 0.

Đề xuất ưu tiên bổ sung Theo mức rủi ro kinh doanh: (1) Điểm danh — vừa launch, chưa test; (2) Gói Premium phía học sinh — ảnh hưởng doanh thu trực tiếp; (3) IELTS Guru — sửa selector login rồi bật lại 4 case, sau đó mở rộng ra luồng làm bài vì hiện không có coverage chức năng thật; (4) bật lại 16 case pending-approval-approved đang skip phía giáo viên.

4Ai cần loại báo cáo gì

Vai tròCâu hỏi cần trả lờiBáo cáo phù hợp
Product / FounderRelease tuần này có an toàn không, có bug nghiêm trọng nào chưa fix?Release Readiness
Automation LeadAutomation đang che phủ bao nhiêu %, test nào hay bị flaky?Automation Coverage
Manual TesterBacklog đang test còn bao nhiêu, bug nào quá hạn?Bug Digest / Aging
Dev LeadBug nào ưu tiên fix trước, ai đang bị nghẽn?Bug Digest theo mức độ / người phụ trách
CS / Vận hànhBug này ảnh hưởng bao nhiêu học sinh / trường?Escaped Defect + đối chiếu usage

5Các dạng báo cáo chất lượng

Loại báo cáoNội dungTần suấtTrạng thái
Test ExecutionTest case chạy, pass/fail/broken/skipped, theo khu vực (teacher/exam/ielts).Mỗi lần chạyĐã có — Allure
Visual RegressionSo ảnh chụp màn hình giữa các lần chạy, bắt lỗi UI lệch layout/màu.Mỗi lần chạyĐã có — plugin screen-diff
Bug Digest (theo mức độ)Bug mới mở / đã đóng / quá hạn xử lý, nhóm theo mức nghiêm trọng.Hàng ngày / tuầnCần build
Automation Coverage% test case đã tự động hoá / tổng số cần test theo từng tính năng (mục 3), tỉ lệ flaky.Hàng tuầnCần bổ sung — số liệu thô đã có, chưa tổng hợp thành báo cáo
Release Readiness (Go/No-Go)Checklist trước release: 0 bug nghiêm trọng mở, regression pass đạt ngưỡng.Mỗi releaseCần build
Escaped DefectBug do CS/khách hàng phát hiện sau release, so với bug QA tìm trước.Hàng thángĐề xuất
Bug Aging & TrendBiểu đồ bug mở/đóng theo thời gian, backlog tồn đọng theo mức độ.Hàng tuầnĐề xuất
Root Cause / Post-mortemCho incident production nghiêm trọng — nguyên nhân gốc, hành động khắc phục.Sau mỗi incidentĐề xuất

6Tần suất & luồng báo cáo

  1. Sau mỗi lần automation chạy — report.flyer.vn tự cập nhật, không cần thao tác thêm. Nên thêm bước Manual Tester lướt qua các case failed để gộp theo nguyên nhân gốc như mục 2, tách "bug thật" khỏi nhiễu.
  2. Hàng ngày — Bug Digest: bug mới mở trong 24h, bug nghiêm trọng còn mở, bug quá hạn xử lý.
  3. Cuối mỗi sprint — tổng hợp coverage theo từng tính năng (mục 3), đính kèm trong sprint review.
  4. Trước mỗi release — Release Readiness: Automation Lead + Manual Tester cùng ký duyệt go/no-go dựa trên báo cáo regression mới nhất.
  5. Hàng tuần — Automation Coverage + Bug Aging, Automation Lead tổng hợp gửi Product.
  6. Hàng tháng — Escaped Defect: đối chiếu bug CS báo với bug QA tìm được trước release.
  7. Sau incident nghiêm trọng — Post-mortem trong vòng 48 giờ.

7Định nghĩa & ngưỡng

Khái niệmĐịnh nghĩa
BlockerChặn hoàn toàn tính năng chính hoặc hệ thống, không có cách né. Xử lý trong ≤ 24 giờ.
CriticalSai dữ liệu/nghiệp vụ nghiêm trọng, cách né khó dùng. Xử lý trong ≤ 3 ngày.
MajorẢnh hưởng chức năng nhưng có cách né. Xử lý trong sprint hiện tại.
MinorUI/UX nhỏ, không ảnh hưởng nghiệp vụ. Xử lý ở release kế tiếp.
Tỉ lệ escaped defectBug do CS/khách hàng phát hiện ÷ (Bug do CS phát hiện + Bug QA tìm trước release). Càng thấp càng tốt — chỉ số chất lượng cốt lõi.
MTTRThời gian trung bình từ lúc mở bug đến lúc đóng, tính riêng theo từng mức độ nghiêm trọng.
Automation coverageSố test case đã tự động hoá ÷ tổng test case có thể tự động hoá (loại trừ case cần mắt người, ví dụ thẩm mỹ UI tinh tế).
Tỉ lệ reopenBug bị mở lại ÷ tổng bug đã đóng. Cao bất thường là tín hiệu fix chưa kỹ hoặc thiếu test coverage.

8Dữ liệu & tool — check "database" bằng cách nào

Phần automation (report.flyer.vn / Allure)

Đây thực chất đã "check được" theo đúng nghĩa: Allure xuất toàn bộ số liệu ra file JSON tĩnh, gọi thẳng bằng HTTP, không cần token, không cần SQL — toàn bộ số liệu mục 2 và 3 lấy trực tiếp từ đây:

GET https://report.flyer.vn/widgets/summary.json     → tổng passed/failed/broken/skipped
GET https://report.flyer.vn/data/categories.json     → danh sách lỗi, đã chia Product defects / Test defects
GET https://report.flyer.vn/data/suites.json         → chi tiết theo khu vực (teacher/exam/ielts) và từng spec file
GET https://report.flyer.vn/history/history-trend.json → xu hướng qua các lần chạy (nguồn nay giữ 6 điểm, nhưng bị ghi đè mỗi lần deploy nên vẫn dùng lịch sử tự lưu ở D1 — mục 9)

Nghĩa là một script nhỏ (giống cách dashboard-cron đang kéo Pipedrive về b2b.flyer.vn) hoàn toàn có thể gọi định kỳ các endpoint này, gộp với dữ liệu bug thủ công, rồi tự đẩy con số vào Slack hoặc một trang tổng hợp riêng.

Phần bug thủ công (Jira)

Nếu bug được track trong Jira: Jira Cloud là SaaS đa khách hàng (multi-tenant) — Atlassian không cấp quyền truy vấn SQL trực tiếp vào database chứa dữ liệu, kể cả cho admin workspace. Khác với các bảng Postgres/Hasura read-replica mà Product đang query trực tiếp cho dữ liệu usage.

Cách lấy dữ liệuPhù hợp khiCần gì
JQL filter + Dashboard có sẵn trong JiraCần xem nhanh, không cần codeKhông cần dev — ai có quyền Jira cũng tạo được
Jira REST/GraphQL APICần tự động hoá, đẩy về Slack/Sheet/dashboard nội bộ1 script + API token, chạy cron
Đồng bộ vào Postgres riêng (Airbyte/Fivetran hoặc tự viết)Cần JOIN bug với dữ liệu sản phẩm khác (ví dụ bug ảnh hưởng bao nhiêu học sinh)Một ETL job định kỳ, thêm schema riêng trong DB nội bộ

9Giới hạn & rủi ro cần lưu ý

10KPI đề xuất theo dõi

KPINgưỡng mục tiêuTần suất
Bug Blocker/Critical còn mở quá hạn xử lý0Hàng ngày
Tỉ lệ escaped defect< 15%Hàng tháng
MTTR bug Critical≤ 3 ngàyHàng tháng
Automation pass rate (08/09: 93,5%)≥ 90%Mỗi lần chạy
Tính năng có PRD đã có automation coverage (08/09: 17/32 = 53%)100%Hàng tháng
Case đang bị skip (08/09: 24, trong đó 4 IELTS + 16 pending-approval)< 5% tổngMỗi lần chạy
Regression pass rate trước release≥ 95%Mỗi release
Tỉ lệ reopen< 5%Hàng tháng

11Ngoài phạm vi / hướng tiếp theo

  1. Giai đoạn 1 — gần như không cần code: bật lại 4 case IELTS + 16 case pending-approval đang skip (sửa selector login IELTS), gắn severity vào automation script, thêm curl roadmap.flyer.vn/api/autotest/summary vào cuối pipeline để lịch sử luôn được lưu, quyết định có gate report.flyer.vn hay không.
  2. Giai đoạn 2: viết thêm test cho 10 tính năng giáo viên và 8 tính năng học sinh đang chưa có coverage (ưu tiên theo mục 3), script tự động đẩy Bug Digest + số liệu Allure vào Slack mỗi sáng theo pattern dashboard-cron đã dùng cho Pipedrive.
  3. Giai đoạn 3 (nếu cần): đồng bộ Jira → Postgres nội bộ để JOIN bug với dữ liệu usage/churn thật — ví dụ bug nào đang ảnh hưởng nhiều học sinh nhất — tái dùng hạ tầng read-replica Product đang có.
  4. Ngoài phạm vi tài liệu này: chốt cụ thể nơi track bug thủ công (Jira) và công cụ quản lý test case cho Manual Tester (Xray/Zephyr/TestRail).