Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vào làm QA ở một công ty và phát hiện đội của mình vẫn đang test giống hệt cách đây ba năm: cùng bộ test case, cùng quy trình review, cùng những con bug lọt lên production mỗi lần release. Không ai ghét quy trình cũ, nhưng cũng không ai biết cách làm nó tốt hơn. Đội cứ chạy, cứ mệt, và chất lượng thì giậm chân tại chỗ.
Đó chính xác là lý do bài học này tồn tại. Test Process Improvement (cải tiến quy trình kiểm thử) không phải là chuyện "làm thêm việc", mà là chuyện làm cho quy trình hiện tại của bạn tự tốt lên theo thời gian một cách có hệ thống, có bằng chứng và có thể lặp lại. Một đội QA giỏi không phải đội không bao giờ để lọt bug — mà là đội biết học từ mỗi bug lọt để lần sau ít lọt hơn.
Trong nghề QA, người ta hay nói: "Quality is a journey, not a destination" (chất lượng là một hành trình, không phải điểm đến). Bài này dạy bạn cách đi hành trình đó một cách bài bản, thông qua chu trình cải tiến liên tục — trọng tâm là mô hình PDCA (Plan-Do-Check-Act, còn gọi là Deming Cycle). Đây là công cụ đơn giản đến bất ngờ nhưng lại là nền tảng để một Senior QA hay QA Lead nâng cấp cả đội chứ không chỉ nâng cấp bản thân.
Lưu ý: bài này tập trung vào chu trình cải tiến — cách bạn thay đổi và tối ưu quy trình. Việc đo lường bằng con số cụ thể (defect density, coverage, DDP...) hay các mô hình đánh giá độ trưởng thành (TMMi, TPI) sẽ được các bài khác đi sâu; ở đây ta dùng chúng như đầu vào cho cải tiến, không mổ xẻ chi tiết.
Khái niệm cốt lõi
Cải tiến quy trình là gì?
Test Process Improvement là hoạt động có chủ đích nhằm làm cho cách đội bạn kiểm thử hiệu quả hơn (tìm được nhiều lỗi quan trọng hơn) và hiệu suất hơn (tốn ít công sức, thời gian, chi phí hơn cho cùng kết quả). Điểm mấu chốt: nó phải liên tục và dựa trên dữ liệu, chứ không phải một lần đại tu rồi thôi.
Có hai kiểu cải tiến bạn cần phân biệt:
- Cải tiến gia tăng (incremental / Kaizen): những thay đổi nhỏ, đều đặn, rủi ro thấp — ví dụ thêm một checklist trước khi close bug, rút gọn một bước review thừa. Đây là kiểu bạn dùng hằng ngày.
- Cải tiến đột phá (breakthrough): thay đổi lớn, ví dụ chuyển từ test thủ công 100% sang có automation, hay áp dụng một mô hình trưởng thành mới cho cả tổ chức. Rủi ro cao hơn, cần đầu tư nhiều hơn.
PDCA — trái tim của chu trình cải tiến
PDCA là một vòng lặp bốn bước do W. Edwards Deming phổ biến (nên còn gọi là Deming Cycle). Bốn bước:
- PLAN (Lập kế hoạch): Xác định vấn đề cụ thể trong quy trình, phân tích nguyên nhân gốc, và đề xuất một cải tiến kèm mục tiêu đo được. Ví dụ: "Tỷ lệ bug lọt production tháng vừa rồi là 8%. Ta nghi ngờ do thiếu contract test giữa frontend và backend. Đề xuất: thêm contract test cho 3 API quan trọng nhất, mục tiêu giảm bug integration xuống dưới 4% trong sprint tới."
- DO (Thực hiện thí điểm): Triển khai cải tiến ở quy mô nhỏ, có kiểm soát — thường là một sprint, một dự án, hoặc một module. Đây là pilot, không phải rollout toàn công ty. Mục đích là học nhanh với chi phí thấp.
- CHECK (Kiểm chứng): So sánh kết quả thực tế với mục tiêu đã đặt ở bước PLAN. Số liệu có cải thiện không? Có tác dụng phụ ngoài ý muốn không? Đội cảm thấy thế nào? Đây là bước hay bị bỏ qua nhất, và cũng là bước quan trọng nhất — không đo thì không biết cải tiến có thật hay chỉ là cảm giác.
- ACT (Hành động chuẩn hóa hoặc điều chỉnh): Nếu cải tiến hiệu quả, biến nó thành chuẩn (standardize) — cập nhật quy trình, checklist, tài liệu, đào tạo cả đội. Nếu không hiệu quả, rút kinh nghiệm và quay lại PLAN với giả thuyết mới. Rồi vòng lặp lại từ đầu — đây là lý do PDCA được vẽ thành vòng tròn chứ không phải đường thẳng.
Retrospective — nơi cải tiến bắt đầu trong thực tế Agile
Trong môi trường Agile, bước PLAN thường khởi nguồn từ buổi Sprint Retrospective. Đây là buổi họp cuối sprint để cả đội nhìn lại: cái gì tốt, cái gì dở, cái gì cần thử khác đi. Với vai trò QA, đây là sân khấu của bạn để đề xuất cải tiến quy trình test. Một retrospective tốt phải kết thúc bằng action item cụ thể, có người chịu trách nhiệm và có hạn — nếu không nó chỉ là buổi than thở tập thể.
Root Cause Analysis — công cụ nuôi dưỡng bước PLAN
Bạn không thể cải tiến thứ mình không hiểu. Trước khi đề xuất giải pháp, hãy tìm nguyên nhân gốc. Hai kỹ thuật kinh điển:
- 5 Whys (Hỏi tại sao 5 lần): Cứ hỏi "tại sao" liên tiếp cho đến khi chạm nguyên nhân thật. Ví dụ: Bug lọt production → Tại sao? Vì test case không cover case đó → Tại sao? Vì requirement mơ hồ → Tại sao? Vì QA không dự họp refinement → Tại sao? Vì lịch họp trùng ca test... Đến đây bạn thấy nguyên nhân gốc không phải "QA lười" mà là "xung đột lịch họp".
- Fishbone Diagram (biểu đồ xương cá / Ishikawa): Nhóm các nguyên nhân tiềm năng theo các nhánh (Con người, Quy trình, Công cụ, Môi trường, Dữ liệu...) để nhìn toàn cảnh.
Tình huống thực tế
Ví dụ 1: Đội QA của một ví điện tử tại TP.HCM giảm bug lọt production
Một fintech giả định tên FinPay (ví điện tử, ~40 kỹ sư) gặp vấn đề nhức nhối: cứ mỗi lần release là 2–3 bug nghiêm trọng lọt lên production, thường liên quan đến luồng nạp tiền. QA Lead tên chị Trang quyết định áp dụng PDCA thay vì tiếp tục đổ lỗi.
- PLAN: Chị Trang gom dữ liệu 6 sprint gần nhất, thấy 70% bug production nằm ở tầng tích hợp giữa các service. Dùng 5 Whys, đội phát hiện nguyên nhân gốc: mỗi team backend deploy độc lập, thay đổi API mà không báo, QA không kịp cập nhật test. Đề xuất: thêm contract test cho 5 API quan trọng nhất. Mục tiêu: giảm bug integration production từ trung bình 2.5/release xuống dưới 1/release trong 2 sprint.
- DO: Không làm cho toàn bộ 30 API. Đội pilot chỉ 5 API của luồng nạp tiền trong đúng 1 sprint, để giới hạn rủi ro và công sức.
- CHECK: Sau 2 sprint, bug integration production của luồng nạp tiền giảm về 0.5/release. Nhưng phát hiện tác dụng phụ: pipeline CI chậm thêm 8 phút.
- ACT: Chuẩn hóa — mọi API thuộc luồng thanh toán bắt buộc có contract test, đưa vào Definition of Done. Đồng thời mở một vòng PDCA mới để xử lý vấn đề pipeline chậm.
Ví dụ 2: Retrospective "để làm cho có" ở một công ty outsourcing
Một công ty gia công phần mềm tại Đà Nẵng (giả định, tên DaNaSoft) có làm Sprint Retrospective đều đặn mỗi 2 tuần. Nhưng sau nửa năm, một bạn QA junior nhận ra: đội nói đi nói lại cùng những vấn đề — "test environment hay sập", "requirement đến trễ" — sprint nào cũng nêu mà chẳng bao giờ hết.
Vấn đề? Họ có bước "CHECK" (nhìn lại) nhưng thiếu bước "ACT" (chuẩn hóa) và không có root cause analysis. Mọi thứ dừng ở mức than phiền. Sau khi một mentor gợi ý, đội thay đổi cách chạy retro: mỗi buổi chỉ chọn 1 vấn đề ưu tiên cao nhất, làm 5 Whys ngay tại chỗ, ra đúng 1 action item có tên người phụ trách và hạn cụ thể, rồi sprint sau bắt buộc mở đầu retro bằng việc kiểm tra action item cũ đã xong chưa.
Sau 3 tháng, vấn đề "test environment hay sập" biến mất vĩnh viễn vì action item của nó (dựng môi trường staging riêng, có script reset dữ liệu) đã được thực thi và chuẩn hóa.
Bài học: Một retrospective không dẫn tới hành động được theo dõi thì không phải cải tiến — nó chỉ là cảm xúc. PDCA thiếu chữ A (Act) là PDCA gãy.
Ví dụ 3: Cải tiến "quá tham" khiến đội kiệt sức
Một startup thương mại điện tử ở Hà Nội (giả định) sau khi đọc về TMMi và các "best practice", quyết định trong một sprint áp dụng đồng loạt: viết test plan chuẩn IEEE, thêm automation E2E, thêm code review cho test case, và thêm daily test report. Nghe rất "trưởng thành".
Kết quả: sprint đó velocity giảm 40%, hai QA xin nghỉ việc vì quá tải, và không ai biết trong 4 thay đổi thì cái nào thực sự giúp ích. Khi mọi thứ thay đổi cùng lúc, bước CHECK trở nên vô nghĩa — không thể quy kết kết quả cho nguyên nhân nào.
Sau khi reset, đội quay lại nguyên tắc one change at a time (mỗi lần một thay đổi). Họ chọn automation cho smoke test trước (giá trị cao nhất, rủi ro thấp nhất), đo trong 2 sprint, thấy tốt mới chuẩn hóa, rồi mới tính thứ tiếp theo.
Bài học: Cải tiến liên tục nghĩa là đều đặn và nhỏ, không phải nhiều và cùng lúc. Thay đổi một biến số mỗi lần thì bạn mới học được điều gì thực sự hiệu quả.
Hướng dẫn từng bước
Đây là quy trình thực dụng để bạn chạy một vòng cải tiến, dù bạn là QA junior hay lead:
- Thu thập tín hiệu vấn đề. Lấy dữ liệu từ nhiều nguồn: bug lọt production, phàn nàn của khách hàng, thời gian test kéo dài, kết quả retrospective, feedback dev. Đừng dựa vào cảm giác — hãy có ít nhất một con số.
- Chọn đúng MỘT vấn đề để giải quyết. Ưu tiên theo tác động và tần suất. Đừng cố sửa mọi thứ cùng lúc. Nguyên tắc: vấn đề nào gây đau nhiều nhất và xảy ra thường xuyên nhất thì làm trước.
- Phân tích nguyên nhân gốc (PLAN). Dùng 5 Whys hoặc Fishbone. Viết ra giả thuyết: "Chúng tôi tin rằng nguyên nhân là X, và nếu làm Y thì chỉ số Z sẽ cải thiện."
- Đặt mục tiêu đo được. Không có mục tiêu số thì không thể CHECK. Ví dụ: "giảm thời gian regression từ 3 ngày xuống 1 ngày", "giảm tỷ lệ bug reopen từ 15% xuống 8%".
- Thiết kế pilot nhỏ (DO). Giới hạn phạm vi: một module, một sprint, một nhóm test case. Xác định rõ pilot chạy trong bao lâu và trên cái gì.
- Thực thi và ghi nhận. Chạy pilot, ghi lại cả số liệu lẫn quan sát định tính (đội thấy thế nào, có ma sát gì).
- So sánh với mục tiêu (CHECK). Kết quả đạt, vượt, hay không đạt mục tiêu? Có tác dụng phụ nào không? Trung thực với dữ liệu, kể cả khi nó nói cải tiến của bạn thất bại.
- Quyết định (ACT).
- Lặp lại. Chọn vấn đề tiếp theo. Cải tiến liên tục nghĩa là vòng lặp không bao giờ dừng, chỉ là nhịp độ có thể thay đổi.
Lỗi thường gặp & mẹo
- Bỏ qua bước CHECK. Đây là lỗi phổ biến nhất. Đội hào hứng triển khai cải tiến (DO) rồi chuyển ngay sang việc khác, không bao giờ quay lại đo xem nó có hiệu quả không. Kết quả: chồng chất "cải tiến" mà chẳng ai biết cái nào thật sự giúp. Mẹo: đặt luôn lịch cho buổi CHECK ngay khi bắt đầu DO.
- Thiếu bước ACT (không chuẩn hóa). Cải tiến thành công nhưng không được viết vào quy trình, không đào tạo. Người nghĩ ra nghỉ việc là cải tiến biến mất. Mẹo: cải tiến chỉ "xong" khi nó nằm trong tài liệu/checklist mà người mới cũng làm theo được.
- Cải tiến không có số liệu (opinion-driven). "Tôi thấy làm thế này ổn hơn" không phải cải tiến, đó là ý kiến. Luôn gắn một chỉ số. Nếu chưa đo được, bước đầu tiên chính là thiết lập cách đo.
- Thay đổi quá nhiều thứ cùng lúc. Như ví dụ startup Hà Nội, đổi 4 thứ một lúc thì bạn không học được gì. Nguyên tắc vàng: one variable at a time.
- Đổ lỗi con người thay vì sửa quy trình. Khi bug lọt, câu hỏi đúng không phải "ai làm sai" mà "quy trình nào để lỗi này lọt qua". Văn hóa blameless (không đổ lỗi) là điều kiện cần để mọi người dám phơi bày vấn đề thật.
- Cải tiến theo phong trào. Thấy công ty khác dùng công cụ gì hay là bắt chước ngay mà không xét bối cảnh của mình. Mẹo: mọi cải tiến phải xuất phát từ một vấn đề cụ thể của đội bạn, không phải từ một bài blog.
- Mẹo hay: viết cải tiến dưới dạng giả thuyết. "Chúng tôi tin rằng [thay đổi] sẽ dẫn tới [kết quả], và sẽ biết mình đúng khi [chỉ số] đạt [mục tiêu]." Cách viết này ép bạn có mục tiêu đo được ngay từ đầu.
Bài tập thực hành
- Chạy một vòng PDCA mini. Chọn một vấn đề nhỏ trong việc học/làm việc hiện tại của bạn (ví dụ: "tôi hay quên viết test case cho case âm"). Viết ra đầy đủ 4 bước PLAN-DO-CHECK-ACT cho nó, kèm ít nhất một mục tiêu đo được. Thực thi trong 1 tuần rồi tự CHECK.
- Thực hành 5 Whys. Lấy một bug mà bạn (hoặc đội) từng để lọt. Viết ra chuỗi 5 câu "tại sao" cho tới khi chạm nguyên nhân gốc thuộc về quy trình, không phải cá nhân. Đề xuất một cải tiến quy trình từ nguyên nhân đó.
- Thiết kế một improvement backlog. Liệt kê 5 vấn đề trong quy trình test của một dự án giả định, cho điểm mỗi vấn đề theo hai trục Tác động (1–5) và Tần suất (1–5), rồi sắp thứ tự ưu tiên. Giải thích vì sao bạn chọn cải tiến vấn đề đứng đầu trước.
- Phân tích ca thất bại. Đọc lại Ví dụ 3 (startup Hà Nội). Viết ra bạn sẽ tư vấn đội đó chạy lại cải tiến thế nào theo đúng PDCA và nguyên tắc "one change at a time". Chọn thay đổi nào làm trước và giải thích lý do.
Tóm tắt
- Test Process Improvement là hoạt động liên tục, có hệ thống, dựa trên dữ liệu để làm quy trình kiểm thử ngày càng hiệu quả và hiệu suất hơn.
- PDCA (Plan-Do-Check-Act / Deming Cycle) là khung xương của cải tiến: PLAN đề xuất cải tiến từ nguyên nhân gốc, DO thí điểm ở quy mô nhỏ, CHECK đo kết quả so với mục tiêu, ACT chuẩn hóa nếu thành công hoặc điều chỉnh nếu thất bại — rồi lặp lại.
- Trong Agile, Sprint Retrospective là điểm khởi phát tự nhiên cho bước PLAN, nhưng chỉ có giá trị khi kết thúc bằng action item cụ thể, có người phụ trách và được theo dõi.
- Root cause analysis (5 Whys, Fishbone) là điều kiện để cải tiến trúng đích thay vì chữa triệu chứng.
- Ba cạm bẫy chết người: bỏ qua CHECK, quên chuẩn hóa (ACT), và thay đổi quá nhiều thứ cùng lúc. Nguyên tắc sống còn: mỗi lần một thay đổi, nhỏ và đo được.
- Cải tiến là văn hóa blameless: sửa quy trình, không đổ lỗi con người. Đó là điều phân biệt một đội QA trưởng thành với một đội chỉ biết than phiền.