Bài 4 — Test Strategy vs Test Plan — Phân biệt

Mở đầu — vì sao bài này quan trọng

Nếu bạn đã đi làm QA được vài năm, gần như chắc chắn bạn từng nghe hai cụm từ "Test Strategy" và "Test Plan" được dùng lẫn lộn, đôi khi trong cùng một cuộc họp. Sếp bảo "gửi tôi cái test strategy cho sprint này", trong khi thứ họ thực sự muốn lại là một bản test plan chi tiết. Ngược lại, có bạn Fresher được giao "viết test plan cho toàn công ty" — một nhiệm vụ vốn dĩ nằm ở tầm chiến lược mà một cá nhân junior không thể gánh nổi.

Sự nhầm lẫn này không chỉ là chuyện chữ nghĩa. Nó gây ra hậu quả thật: tài liệu viết sai tầm, review sai người, tốn thời gian sửa đi sửa lại, và tệ nhất là cả team làm việc mà không rõ đâu là nguyên tắc bất biến, đâu là kế hoạch có thể điều chỉnh theo từng release. Khi bạn bước lên vai trò QA Lead hoặc QA Manager, việc phân biệt rạch ròi hai khái niệm này trở thành kỹ năng nền tảng — bởi vì bạn sẽ là người sở hữu Test Strategy và là người duyệt các Test Plan do team viết ra.

Bài học này giúp bạn phân biệt tường tận Test Strategy và Test Plan: chúng khác nhau ở tầm nào, sống lâu bao nhiêu, ai sở hữu, chứa gì, và quan trọng nhất — làm sao để hai tài liệu này ăn khớp với nhau thay vì mâu thuẫn. Đây là "hộ chiếu tư duy" để bạn không còn viết nhầm tài liệu nữa.

Khái niệm cốt lõi

Test Strategy là gì

Test Strategy (Chiến lược kiểm thử) là tài liệu ở tầm cao nhất — tầm tổ chức hoặc tầm phòng ban. Nó trả lời câu hỏi mang tính nguyên tắc: "Ở công ty/bộ phận này, chúng ta tiếp cận việc đảm bảo chất lượng theo triết lý nào?"

Test Strategy mô tả những cam kết mang tính bền vững: các cấp độ kiểm thử (test levels) mà tổ chức áp dụng, các loại kiểm thử bắt buộc (functional, performance, security...), tiêu chuẩn về công cụ, quy ước về môi trường, chuẩn báo cáo defect, tiêu chí chất lượng tối thiểu cho một sản phẩm được phép release. Nó không nói đến một dự án cụ thể nào. Chính vì vậy, một Test Strategy tốt có thể sống nhiều năm, chỉ được review lại khi có thay đổi lớn về công nghệ, quy trình hay định hướng kinh doanh.

Đặc điểm nhận diện: Test Strategy thường static (ít thay đổi), general (nói về nguyên tắc chung, không phụ thuộc dự án), và được sở hữu bởi cấp quản lý cao — Head of QA, QA Manager, hoặc Test Architect. Trong nhiều tổ chức trưởng thành, Test Strategy là một tài liệu duy nhất, dùng chung cho tất cả dự án.

Test Plan là gì

Test Plan (Kế hoạch kiểm thử) là tài liệu ở tầm dự án hoặc tầm release. Nó trả lời câu hỏi cụ thể: "Cho release này, chúng ta sẽ kiểm thử cái gì, khi nào, ai làm, bằng nguồn lực nào, và khi nào thì dừng?"

Test Plan lấy các nguyên tắc từ Test Strategy rồi cụ thể hóa chúng cho một bối cảnh nhất định. Nó chứa: phạm vi kiểm thử (scope — cái gì trong, cái gì ngoài), lịch trình (schedule), phân công nhân sự, ước lượng công sức, danh sách rủi ro cụ thể của dự án, tiêu chí bắt đầu (entry criteria) và tiêu chí kết thúc (exit criteria), các deliverable, và kế hoạch dự phòng.

Đặc điểm nhận diện: Test Plan thường dynamic (thay đổi theo dự án, thậm chí theo sprint), specific (gắn với một sản phẩm/release cụ thể), và được sở hữu bởi Test Lead hoặc QA Engineer phụ trách dự án đó. Mỗi dự án, mỗi release lớn thường có Test Plan riêng.

Bảng so sánh nhanh để khắc cốt ghi tâm

Quan hệ giữa hai tài liệu: cha và con

Cách hình dung dễ nhất: Test Strategy là hiến pháp, Test Plan là luật cụ thể cho từng tình huống. Test Plan không được phép mâu thuẫn với Test Strategy. Nếu Strategy nói "mọi sản phẩm banking phải qua penetration test trước khi release", thì Test Plan của một release banking cụ thể phải có mục pentest — người viết plan không được tự ý bỏ. Ngược lại, Strategy sẽ không bao giờ nói "test màn hình đăng nhập của app X vào tuần thứ 3" — đó là việc của Plan.

Một cách nói khác trong giới: Strategy là WHY & WHAT (ở tầm nguyên tắc), còn Plan là WHAT (cụ thể), WHO, WHEN, HOW MUCH.

Tình huống thực tế

Tình huống 1 — Ngân hàng số Timo: một Strategy, nhiều Plan

Hãy hình dung một ngân hàng số như Timo (mô hình digital banking phổ biến ở Việt Nam). Bộ phận QA của họ có một Test Strategy duy nhất, dài khoảng 20 trang, được Head of QA sở hữu và chỉ review lại mỗi năm một lần. Trong đó ghi rõ những nguyên tắc bất biến: mọi tính năng liên quan đến giao dịch tiền phải có regression test tự động; mọi release lên production phải qua security testing và tuân thủ chuẩn của Ngân hàng Nhà nước; môi trường staging phải mô phỏng gần giống production; defect mức Critical phải fix trước khi release, không có ngoại lệ.

Khi team phát triển tính năng "chuyển tiền nhanh Napas 24/7", Test Lead của dự án đó viết một Test Plan riêng: liệt kê 47 test case cụ thể, phân công 3 QA, lịch test kéo dài 2 tuần, exit criteria là "100% Critical/High pass, không quá 5 defect Medium mở". Khi team khác làm tính năng "thông báo biến động số dư", họ viết một Test Plan khác hoàn toàn — nhưng cả hai đều thừa hưởng cùng một Strategy.

Bài học: Một tổ chức thường chỉ cần một Strategy nhưng có hàng chục Plan. Khi bạn thấy công ty phải viết lại "strategy" cho từng dự án, gần như chắc chắn họ đang gọi nhầm tên — thứ họ viết thực ra là Test Plan.

Tình huống 2 — Startup fintech gọi nhầm tên, trả giá bằng thời gian

Một startup fintech giả định ở TP.HCM, khoảng 30 người, có 3 QA. Ban đầu họ không có Test Strategy, chỉ có thói quen "mỗi dự án viết một cái gọi là Test Strategy". Kết quả là mỗi QA lại tự quyết định dùng công cụ khác nhau (người dùng Postman, người dùng Insomnia), tiêu chí release mỗi lần một kiểu, và mức độ nghiêm ngặt về security thì tùy hứng.

Đến khi họ định huy động vốn vòng Series A, nhà đầu tư yêu cầu chứng minh quy trình đảm bảo chất lượng nhất quán. Team QA hoảng vì không có tài liệu nào nói được "công ty này tiếp cận chất lượng ra sao" — họ chỉ có một đống Plan rời rạc, mâu thuẫn nhau. Họ mất gần 3 tuần để lùi lại, viết một Test Strategy chung đúng nghĩa (cấp độ test, công cụ chuẩn hóa, chuẩn bảo mật theo hướng PCI-DSS, tiêu chí release tối thiểu), rồi sau đó các Plan mới bám theo.

Bài học: Thiếu Strategy khiến các Plan mọc lộn xộn, mỗi người một phách. Strategy chính là thứ tạo ra tính nhất quán xuyên suốt tổ chức — điều mà từng Plan riêng lẻ không bao giờ làm được.

Tình huống 3 — Công ty outsourcing và câu hỏi "ai sở hữu cái nào"

Một công ty outsourcing phần mềm ở Đà Nẵng nhận dự án cho khách hàng Nhật. Khách hàng đã có sẵn Test Strategy của họ (chuẩn chất lượng của tập đoàn mẹ). Team QA ở Đà Nẵng ban đầu tưởng mình phải viết lại Strategy, nhưng QA Manager kịp thời chỉ ra: "Strategy là của khách hàng, chúng ta tuân theo. Việc của chúng ta là viết Test Plan cho từng release, sao cho không vi phạm Strategy đó."

Nhờ phân định đúng, team tiết kiệm được thời gian và tránh xung đột. Khi khách hàng yêu cầu "test mức độ browser compatibility rộng hơn", đó là thay đổi ở tầm Strategy — team ghi nhận và đề xuất khách hàng cập nhật Strategy, chứ không tự sửa lén trong Plan. Còn khi cần điều chỉnh lịch test cho một release trễ, team tự quyết trong Plan mà không cần xin phép cấp cao.

Bài học: Biết ai sở hữu tài liệu nào giúp bạn giao tiếp đúng cửa, thay đổi đúng chỗ, và không vượt quyền cũng không thiếu trách nhiệm.

Hướng dẫn từng bước

Khi bạn cần tạo hoặc chỉnh sửa tài liệu kiểm thử, hãy đi theo trình tự sau để không viết nhầm tầm:

Bước 1 — Xác định bạn đang ở tầm nào. Hỏi: "Tài liệu này áp dụng cho toàn tổ chức/phòng ban hay chỉ một dự án/release cụ thể?" Nếu toàn tổ chức → Strategy. Nếu một dự án → Plan. Đây là câu hỏi phân loại quan trọng nhất.

Bước 2 — Kiểm tra tuổi thọ dự kiến. Hỏi: "Tài liệu này tôi kỳ vọng dùng được bao lâu?" Nếu câu trả lời là "nhiều năm, gần như không đổi" → Strategy. Nếu "chỉ release này, xong là bỏ" → Plan. Tuổi thọ là phép thử phân biệt cực nhanh.

Bước 3 — Nếu là Strategy, viết theo nguyên tắc. Tập trung vào: triết lý chất lượng, các cấp độ và loại kiểm thử bắt buộc, chuẩn công cụ, chuẩn môi trường, chuẩn báo cáo defect, tiêu chí release tối thiểu áp dụng cho mọi dự án. Tuyệt đối không nhắc đến tên tính năng cụ thể, lịch cụ thể, hay tên người.

Bước 4 — Nếu là Plan, kế thừa Strategy rồi cụ thể hóa. Mở Strategy ra làm nền. Sau đó điền các phần đặc thù dự án: scope (in/out), schedule, resource/nhân sự, ước lượng, rủi ro cụ thể, entry & exit criteria, deliverable, kế hoạch dự phòng. Với mỗi mục, tự hỏi: "Điều này có mâu thuẫn với Strategy không?" Nếu có, bạn hoặc viết sai, hoặc cần đề xuất sửa Strategy — chứ không âm thầm phá vỡ nó.

Bước 5 — Đối chiếu chéo (traceability). Đảm bảo mọi yêu cầu bắt buộc trong Strategy đều được phản ánh trong Plan. Ví dụ Strategy bắt buộc security testing → Plan phải có ít nhất một dòng phân công cho hạng mục đó.

Bước 6 — Giao đúng người review. Strategy trình lên Head of QA / QA Manager duyệt. Plan trình Test Lead hoặc QA Manager của dự án. Đừng bắt Head of QA duyệt từng Plan lặt vặt, cũng đừng để một QA junior tự duyệt Strategy.

Lỗi thường gặp & mẹo

Lỗi 1 — Nhồi chi tiết dự án vào Strategy. Rất nhiều người viết Strategy nhưng lại liệt kê lịch test, tên test case, tên nhân sự. Kết quả là "Strategy" đó chết yểu ngay khi dự án kết thúc, phải viết lại cho dự án sau. Mẹo: nếu trong tài liệu Strategy của bạn xuất hiện ngày tháng cụ thể hay tên người, đó là dấu hiệu bạn đã tụt xuống tầm Plan.

Lỗi 2 — Viết Plan mà bỏ qua Strategy. QA viết Plan tùy hứng, không đối chiếu Strategy, dẫn đến bỏ sót các loại test bắt buộc (như security, performance). Mẹo: luôn mở Strategy song song khi viết Plan, dùng nó như một checklist ràng buộc.

Lỗi 3 — Mỗi dự án viết lại một "Strategy" mới. Đây là lỗi phổ biến nhất ở công ty non trẻ. Mẹo: nhớ nguyên tắc "một tổ chức, một Strategy; một dự án, một Plan". Nếu bạn đang viết "strategy" thứ năm trong năm, bạn đang viết Plan.

Lỗi 4 — Nhầm chủ sở hữu. Giao Strategy cho junior, hoặc bắt QA Manager sa đà vào chỉnh từng Plan. Mẹo: Strategy đi lên, Plan đi ngang — Strategy do cấp cao sở hữu và ổn định, Plan do người phụ trách dự án sở hữu và linh hoạt.

Lỗi 5 — Coi hai tài liệu là một. Một số team gộp tất cả vào một file khổng lồ, khiến nguyên tắc bền vững và chi tiết nhất thời trộn lẫn, không tài nào bảo trì. Mẹo: tách hai file. Strategy đứng riêng, được các Plan tham chiếu đến (link tới), giữ mỗi tài liệu đúng chức năng của nó.

Mẹo vàng để nhớ: Khi ai đó nhờ bạn "viết strategy", hãy hỏi lại một câu: "Cho toàn công ty, hay cho release này?" Chỉ một câu hỏi đó thôi cũng đủ tránh 80% các vụ viết nhầm tài liệu.

Bài tập thực hành

Bài 1 — Phân loại. Dưới đây là 6 phát biểu. Hãy đánh dấu mỗi phát biểu thuộc Test Strategy (S) hay Test Plan (P):

• "Mọi ứng dụng thanh toán phải qua kiểm thử bảo mật trước khi lên production."
• "Sprint 8 sẽ test 12 test case cho màn hình giỏ hàng, do bạn Linh phụ trách."
• "Công cụ automation chuẩn của phòng QA là Playwright."
• "Exit criteria của release 2.3 là không còn defect Critical và tối đa 3 defect High."
• "Môi trường staging phải mô phỏng gần giống production ở mọi dự án."
• "Lịch test kéo dài từ 5/8 đến 19/8, mỗi ngày báo cáo lúc 5 giờ chiều."

(Gợi ý đáp án: 1-S, 2-P, 3-S, 4-P, 5-S, 6-P. Quy tắc: nói về nguyên tắc chung, dùng nhiều năm → S; gắn dự án/release, có ngày tháng/tên người → P.)

Bài 2 — Rút gọn. Lấy một dự án bạn đang hoặc từng làm. Viết ra 5 nguyên tắc mà bạn cho là nên nằm ở tầm Strategy (áp dụng cho mọi dự án của công ty), và 5 mục nên nằm ở tầm Plan (chỉ riêng dự án đó). So sánh: nếu một mục bạn xếp vào Strategy nhưng lại chứa tên tính năng cụ thể, hãy chuyển nó xuống Plan.

Bài 3 — Phát hiện mâu thuẫn. Giả sử Strategy công ty ghi "mọi release fintech phải có performance test". Nhưng Test Plan của release sắp tới không có mục performance test vì "lần này gấp quá". Với vai trò QA Lead, bạn sẽ xử lý thế nào? Viết ra 3 bước hành động (gợi ý: không âm thầm bỏ; nêu rủi ro; hoặc đề xuất sửa Strategy chính thức, hoặc bổ sung vào Plan, chứ không tạo tiền lệ phá vỡ nguyên tắc).

Tóm tắt

Test Strategy và Test Plan là hai tài liệu ở hai tầm khác nhau, và việc lẫn lộn chúng gây ra vô số phiền toái trong công việc QA thực tế. Hãy khắc ghi những điểm cốt lõi:

• Test Strategy ở tầm tổ chức/phòng ban, sống nhiều năm, tĩnh, nói về nguyên tắc chung, do cấp quản lý cao sở hữu. Nó trả lời "chúng ta tiếp cận chất lượng thế nào?".
• Test Plan ở tầm dự án/release, sống theo release, động, nói về chi tiết cụ thể (cái gì, ai, khi nào, bao nhiêu), do Test Lead sở hữu. Nó trả lời "release này test cái gì, ai làm, khi nào xong?".
• Quan hệ giữa chúng là cha–con: Plan kế thừa và cụ thể hóa Strategy, và không được mâu thuẫn với Strategy.
• Nguyên tắc ghi nhớ: một tổ chức, một Strategy; một dự án, một Plan.
• Khi được giao viết "strategy", luôn hỏi lại "cho toàn công ty hay cho release này?" để không viết nhầm tầm.

Nắm vững sự phân biệt này, bạn không chỉ tránh viết sai tài liệu mà còn bước đầu tư duy như một QA Lead thực thụ — người vừa gìn giữ nguyên tắc bền vững của tổ chức, vừa linh hoạt lập kế hoạch cho từng chiến dịch cụ thể.