Test Strategy Document

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

Hãy tưởng tượng bạn vừa gia nhập một startup fintech ở Sài Gòn. Ngày đầu tiên, bạn hỏi anh QA lead: "Team mình test như thế nào? Cái gì automate, cái gì test tay? Ai chịu trách nhiệm khâu nào? Bao nhiêu phần trăm coverage thì được release?" Anh ấy gãi đầu: "Ờ... thì mỗi người làm theo kinh nghiệm, có gì hỏi trong nhóm chat." Bạn vừa gặp một team không có Test Strategy Document — và bạn sắp hiểu vì sao đó là một vấn đề nghiêm trọng.

Trong suốt khóa học này, chúng ta đã học rất nhiều kỹ thuật cụ thể: từ Selenium, Cypress, đến API automation, CI/CD, flaky test management. Đó là các "chiến thuật" (tactics). Nhưng nếu ví toàn bộ hoạt động testing của một sản phẩm như một trận đánh, thì tất cả các kỹ thuật đó chỉ là vũ khí. Test Strategy Document là bản đồ chiến dịch — nó nói cho cả đội biết đánh vào đâu, dùng vũ khí gì, ai giữ vị trí nào, và khi nào coi là thắng.

Bài học này khác với các bài kỹ thuật trước ở chỗ: chúng ta không viết code. Chúng ta viết tài liệu. Và với nhiều bạn QA/SDET, đây lại là kỹ năng bị xem nhẹ nhất nhưng lại quyết định việc bạn có được thăng lên vai trò lead hay không. Một tester giỏi biết viết test case; một QA lead giỏi biết viết chiến lược để cả team cùng test hiệu quả. Đây là bài học đưa bạn từ vai trò "người thực thi" sang vai trò "người định hướng".

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

Test Strategy Document là gì?

Test Strategy Document (tài liệu chiến lược kiểm thử) là tài liệu master ở cấp product hoặc release lớn, mô tả cách một tổ chức/đội tiếp cận việc kiểm thử một sản phẩm cụ thể. Nó trả lời câu hỏi "CHÚNG TA TEST NHƯ THẾ NÀO" ở tầm bao quát, chứ không đi vào từng test case chi tiết.

Nó phục vụ ba mục đích chính:

• Align (đồng bộ) cả team về cách test. Không còn cảnh mỗi người hiểu một kiểu. Từ dev, QA, DevOps đến PM đều nhìn vào cùng một tài liệu và hiểu chung một ngôn ngữ.
• Onboard (đào tạo) QA mới nhanh chóng. Người mới đọc tài liệu là hiểu được ngay bức tranh tổng thể, thay vì mất hàng tuần "hỏi mò" từng người.
• Communicate (giao tiếp) với stakeholder. PM, khách hàng, ban lãnh đạo có thể hiểu được mức độ rủi ro, phạm vi kiểm thử, và tại sao team cần thời gian/nguồn lực như vậy.

Phân biệt Test Strategy với Test Plan

Đây là chỗ rất nhiều bạn nhầm lẫn, nên tôi muốn làm rõ ngay. Hai tài liệu này thường bị dùng lẫn lộn, nhưng chúng khác nhau về tầm và tuổi thọ:

Nói ngắn gọn: Test Strategy là "hiến pháp", Test Plan là "kế hoạch tác chiến cụ thể" tuân theo hiến pháp đó. Bài học này tập trung vào Test Strategy — tài liệu tầm cao, sống lâu.

Các thành phần bắt buộc của một Test Strategy Document

Một Test Strategy Document tốt thường gồm các mục sau. Tôi sẽ giải thích từng mục theo góc nhìn "vì sao cần":

1. Scope & Objectives (Phạm vi và mục tiêu). Test cái gì và KHÔNG test cái gì. Phần "không test" (out of scope) quan trọng không kém phần "có test" — nó bảo vệ team khỏi kỳ vọng vô lý của stakeholder.

2. Test Levels & Types (Cấp độ và loại kiểm thử). Ở đây bạn tuyên bố chiến lược ở tầm cao: chúng ta áp dụng Test Automation Pyramid ra sao, tỷ lệ unit/integration/E2E thế nào, có làm performance/security/visual testing không.

3. Test Approach — Automation vs Manual. Nguyên tắc quyết định cái gì automate, cái gì test tay. Ví dụ: "Mọi smoke test và regression core flow phải automate; test khám phá (exploratory) và UX thì làm tay."

4. Tools & Frameworks (Công cụ). Danh sách công nghệ chuẩn của team: Selenium/Cypress/Playwright cho UI, REST Assured/pytest cho API, Jenkins/GitHub Actions cho CI, Allure cho báo cáo. Điều này ngăn tình trạng mỗi dev tự chọn tool khác nhau gây phân mảnh.

5. Environments & Test Data (Môi trường và dữ liệu test). Có bao nhiêu môi trường (dev, staging, UAT, prod), dữ liệu test lấy từ đâu, xử lý dữ liệu nhạy cảm ra sao.

6. Roles & Responsibilities (Vai trò và trách nhiệm). Ai viết test, ai review, ai chịu trách nhiệm khi test fail trên CI. Thường dùng ma trận RACI.

7. Entry & Exit Criteria (Tiêu chí vào và ra). Khi nào bắt đầu test được (entry), khi nào đủ điều kiện release (exit). Ví dụ exit: "0 bug severity Critical/High tồn đọng, pass rate của regression suite ≥ 98%".

8. Risk Management (Quản lý rủi ro). Những rủi ro chính (thanh toán sai, mất dữ liệu, downtime) và cách kiểm thử ưu tiên theo rủi ro (risk-based testing).

9. Metrics & Reporting (Chỉ số và báo cáo). Đo cái gì (defect density, test coverage, flaky rate) và báo cáo cho ai, tần suất nào.

Bạn không cần tất cả mọi lúc — với sản phẩm nhỏ, một tài liệu 3-4 trang tập trung vào scope, approach, tools, và exit criteria là đủ. Điều quan trọng là tài liệu được đọc và được dùng, chứ không phải dài mấy chục trang rồi để mốc.

Tình huống thực tế

Ví dụ 1: Sàn TMĐT "Chợ Việt" và chiến lược cứu vãn mùa sale

Một công ty thương mại điện tử tầm trung (gọi là "Chợ Việt", khoảng 40 kỹ sư) chuẩn bị cho đợt sale 12/12. Năm trước, họ release mà không có Test Strategy rõ ràng: mỗi squad tự test phần của mình, không ai nắm luồng end-to-end. Kết quả là đúng đêm sale, luồng áp mã giảm giá kết hợp với ví điện tử bị lỗi, khiến khoảng 3.000 đơn hàng tính sai giá trong 2 giờ đầu, thiệt hại ước tính hơn 400 triệu đồng và một cơn bão phàn nàn trên fanpage.

Sau sự cố, QA lead mới về đã viết một Test Strategy Document cho các release lớn. Điểm mấu chốt trong đó: một mục Risk-Based Testing liệt kê các luồng "chết người" (payment, tính giá, tồn kho) phải có E2E automation chạy trên staging giống production, và một Exit Criteria ghi rõ: "Không release mùa sale nếu 100% E2E của luồng thanh toán chưa pass trên môi trường tải giả lập 5x traffic thường ngày."

Bài học: Test Strategy không phải thủ tục giấy tờ. Nó là nơi bạn ghi lại "chúng ta đã trả giá cho bài học nào và sẽ không lặp lại". Một dòng exit criteria đúng có thể đáng giá vài trăm triệu.

Ví dụ 2: Startup fintech và câu chuyện onboard QA mới

Một startup ví điện tử ở Đông Nam Á tăng trưởng nóng, tuyển 6 QA trong 3 tháng. Vấn đề: mỗi QA mới mất trung bình 3-4 tuần mới thực sự đóng góp được, vì không có tài liệu nào mô tả "cách team test". Họ phải hỏi từng người, và mỗi người trả lời một kiểu vì bản thân team cũng chưa align.

QA manager quyết định đầu tư 3 ngày viết một Test Strategy Document, trong đó có sơ đồ Automation Pyramid của team, danh sách tool chuẩn, quy ước đặt tên test, ma trận RACI (ai review PR test, ai fix flaky test), và link tới các repo mẫu. Sau đó, thời gian onboard giảm từ 3-4 tuần xuống còn khoảng 1 tuần. Quan trọng hơn, các cuộc tranh cãi kiểu "sao anh lại automate cái này bằng tay" gần như biến mất, vì mọi người có một "nguồn sự thật chung" để trỏ tới.

Bài học: Chi phí viết tài liệu (3 ngày) nhỏ hơn rất nhiều so với chi phí không có nó (mỗi QA mới lãng phí 2-3 tuần, cộng vô số giờ tranh cãi). Test Strategy là một khoản đầu tư có ROI đo được.

Ví dụ 3: Team outsource và bài toán giao tiếp với stakeholder

Một công ty gia công phần mềm ở Đà Nẵng nhận dự án cho khách hàng Nhật. Khách hàng liên tục hỏi: "Tại sao release chậm? Các anh test có kỹ không?" Team QA làm việc rất chăm nhưng không có cách nào trình bày công sức của mình một cách hệ thống.

Họ soạn một Test Strategy Document song ngữ, trong đó phần Scope ghi rõ những gì được test và những gì nằm ngoài phạm vi (out of scope), phần Metrics & Reporting cam kết gửi báo cáo Allure hằng tuần với các chỉ số coverage và defect trend. Từ đó, mỗi khi khách hàng thắc mắc, team chỉ cần trỏ vào tài liệu và báo cáo. Niềm tin của khách hàng tăng rõ rệt, và những yêu cầu "test thêm cái này ngoài hợp đồng" được xử lý êm đẹp vì đã có ranh giới scope minh bạch từ đầu.

Bài học: Với stakeholder không rành kỹ thuật, Test Strategy là ngôn ngữ chung giúp họ hiểu và tin tưởng công việc của bạn. Nó biến testing từ "hộp đen bí ẩn" thành thứ có thể thảo luận và ra quyết định.

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

Đây là quy trình thực tế để bạn tự viết một Test Strategy Document cho sản phẩm của mình.

Bước 1 — Xác định đối tượng đọc. Trước khi viết chữ nào, hỏi: ai sẽ đọc tài liệu này? Nếu chỉ có dev/QA đọc, bạn có thể dùng thuật ngữ kỹ thuật thoải mái. Nếu có PM và ban lãnh đạo, cần một mục tóm tắt (executive summary) không kỹ thuật ở đầu.

Bước 2 — Viết Scope & Objectives. Liệt kê rõ ràng phạm vi. Đừng ngại viết phần "Out of Scope" — ví dụ "Bản release này không kiểm thử tương thích với trình duyệt IE11" hay "Không test hiệu năng vượt 10.000 user đồng thời".

Bước 3 — Quyết định Test Approach. Vẽ Automation Pyramid cho team và ghi nguyên tắc automate vs manual. Đây là nơi bạn tổng hợp lại tinh thần của cả khóa học: nhiều unit test ở đáy, ít E2E ở đỉnh.

Bước 4 — Chốt Tools, Environments, Test Data. Liệt kê stack công cụ chuẩn. Mô tả các môi trường và cách sinh/quản lý dữ liệu test (đặc biệt lưu ý dữ liệu nhạy cảm như số CCCD, thông tin thanh toán — phải được che/giả lập).

Bước 5 — Lập ma trận Roles & Responsibilities (RACI). Với mỗi hoạt động (viết test, review, fix flaky, quyết định release), ghi rõ ai Responsible, ai Accountable, ai Consulted, ai Informed.

Bước 6 — Định nghĩa Entry & Exit Criteria. Đây là phần được stakeholder quan tâm nhất. Viết tiêu chí đo được, không mơ hồ. Thay vì "test đầy đủ", hãy viết "regression pass rate ≥ 98%, 0 bug Critical/High tồn đọng".

Bước 7 — Thêm Risk Management & Metrics. Liệt kê rủi ro chính và chỉ số theo dõi. Điều này thể hiện bạn nghĩ như một người quản lý rủi ro, không chỉ là người bấm nút chạy test.

Bước 8 — Review với team và stakeholder. Tài liệu chiến lược mà chỉ một người viết rồi cất tủ thì vô nghĩa. Tổ chức một buổi review, thu thập phản hồi, để mọi người "ký nhận" đồng thuận. Chính quá trình thảo luận này mới tạo ra sự align — tài liệu chỉ là kết tinh của nó.

Bước 9 — Đặt lịch review định kỳ. Ghi ngày review lại (ví dụ mỗi quý). Một chiến lược lỗi thời còn nguy hiểm hơn không có chiến lược, vì người ta tin nhầm vào nó.

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

Lỗi 1 — Viết tài liệu quá dài rồi không ai đọc. Nhiều bạn nghĩ tài liệu càng dày càng chuyên nghiệp. Sai. Một Test Strategy 5 trang được cả team đọc và tuân theo tốt hơn 50 trang để mốc. Mẹo: viết ngắn, dùng bảng biểu và sơ đồ thay cho đoạn văn dài.

Lỗi 2 — Copy template trên mạng mà không tùy biến. Tôi từng thấy tài liệu ghi "test tương thích IE6" trong khi sản phẩm là app mobile — vì copy nguyên template cũ. Template chỉ là khung; nội dung phải phản ánh đúng sản phẩm và rủi ro thực tế của bạn.

Lỗi 3 — Lẫn lộn giữa Strategy và Plan. Nhét lịch trình chi tiết từng ngày, tên từng test case vào Test Strategy. Kết quả là tài liệu "sống lâu" bị thay đổi liên tục, mất đi giá trị định hướng. Mẹo: nếu một nội dung thay đổi mỗi sprint, nó thuộc về Test Plan, không phải Strategy.

Lỗi 4 — Exit criteria mơ hồ. "Test kỹ càng rồi mới release" là câu vô nghĩa vì không đo được. Luôn viết tiêu chí có con số: pass rate, số bug tồn đọng theo severity, coverage tối thiểu.

Lỗi 5 — Viết xong không review lại. Sản phẩm thay đổi, tool thay đổi, nhưng tài liệu đứng yên. Mẹo: đặt reminder review định kỳ, và ghi ngày cập nhật gần nhất ở đầu tài liệu.

Mẹo vàng: Coi Test Strategy là một sản phẩm sống. Lưu nó trong wiki/Confluence có version, cho phép comment, và biến việc cập nhật nó thành một phần của định nghĩa "hoàn thành" khi có thay đổi lớn về công nghệ hay kiến trúc test.

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

• Phân biệt khái niệm. Lấy một dự án bạn từng tham gia (hoặc dự án tưởng tượng). Viết 3 câu chỉ thuộc về Test Strategy và 3 câu chỉ thuộc về Test Plan. Tự kiểm tra bằng tiêu chí "tuổi thọ": nội dung nào sống lâu là Strategy.

• Soạn khung tài liệu. Chọn một sản phẩm quen thuộc (một app đặt đồ ăn, một ví điện tử). Viết một Test Strategy Document rút gọn 2-3 trang, bắt buộc có đủ: Scope (kèm Out of Scope), Test Approach, Tools, Entry/Exit Criteria.

• Viết Exit Criteria đo được. Viết 5 tiêu chí exit cho một release thanh toán, mỗi tiêu chí phải có con số hoặc điều kiện kiểm chứng được. Ví dụ mẫu để bạn tham khảo phong cách: "Pass rate của E2E payment suite = 100%".

• Lập ma trận RACI. Cho 4 hoạt động (viết automation test, review PR test, xử lý flaky test, quyết định go/no-go release), điền ai là R-A-C-I trong một team giả định gồm QA, Dev, DevOps, PM.

• Nâng cao — bảo vệ chiến lược. Viết một đoạn 150 từ trả lời một PM đang hỏi "Tại sao chúng ta phải automate luồng thanh toán mà không test tay cho nhanh?", sử dụng lập luận từ chính Test Strategy của bạn (rủi ro, tần suất regression, chi phí lỗi production).

Tóm tắt

Test Strategy Document là tài liệu master ở cấp product/release lớn, đóng ba vai trò cốt lõi: align cả team về cách test, onboard QA mới nhanh, và communicate với stakeholder. Nó khác Test Plan ở chỗ sống lâu và mang tính định hướng, trong khi Test Plan chi tiết và thay đổi theo từng release.

Một tài liệu tốt gồm các thành phần: Scope & Objectives (đừng quên Out of Scope), Test Approach (automation vs manual, Automation Pyramid), Tools, Environments & Test Data, Roles & Responsibilities (RACI), Entry & Exit Criteria đo được, Risk Management, và Metrics. Qua ba tình huống — sàn TMĐT tránh thảm họa mùa sale, startup fintech rút ngắn onboard, team outsource xây niềm tin với khách Nhật — bạn thấy rõ giá trị thực tế và ROI đo được của tài liệu này.

Hãy nhớ ba điều: viết ngắn gọn và có người đọc quan trọng hơn viết dài; tiêu chí phải đo được, không mơ hồ; và tài liệu là một sản phẩm sống cần review định kỳ. Khi bạn thành thạo việc viết Test Strategy, bạn không còn chỉ là người thực thi test — bạn đã bước sang vai trò định hướng cách cả tổ chức đảm bảo chất lượng. Đó chính là bước chuyển từ tester sang QA lead thực thụ.