Bài 11 — Test Strategy Document — Template

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

Trong các bài trước, bạn đã học cách thiết kế một test strategy, cách phân biệt nó với test plan, và cách áp dụng tư duy risk-based. Nhưng có một sự thật phũ phàng mà tôi đã chứng kiến ở rất nhiều đội QA tại Việt Nam: chiến lược nằm trong đầu QA Lead thì không phải là chiến lược — nó chỉ là ý định cá nhân. Chiến lược chỉ thực sự tồn tại khi nó được viết ra thành một tài liệu (document) mà bất kỳ ai trong team — từ Dev, PM, đến bạn QA mới vào — đều có thể mở ra, đọc trong 5 phút, và hiểu "chúng ta test cái gì, test như thế nào, và ai chịu trách nhiệm cái gì".

Bài này tập trung vào một thứ rất cụ thể và rất thực dụng: Test Strategy Document — cái template, cái khung xương để bạn viết ra chiến lược đó. Không phải lý thuyết về strategy nữa (bạn đã học ở Bài 1 và Bài 4), mà là câu hỏi: "Tôi mở một file Google Docs / Confluence trống, tôi phải gõ những mục gì vào đó?"

Tại sao điều này quan trọng đến mức đáng cả một bài học? Vì phần lớn QA Lead khi được sếp yêu cầu "viết test strategy đi" thì hoặc là copy một template 40 trang từ trên mạng về (rồi không ai đọc), hoặc là viết một đoạn văn chung chung ("chúng tôi sẽ test kỹ lưỡng"). Cả hai đều thất bại. Một Test Strategy Document tốt phải ngắn, sống động, được cập nhật, và được cả team ký nhận về mặt tinh thần. Trong bài này tôi sẽ đưa bạn một template one-page thực chiến, giải thích từng phần vì sao có mặt, và cho bạn thấy nó khác nhau thế nào giữa một startup 8 người và một ngân hàng.

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

Test Strategy Document là gì và không là gì

Test Strategy Document (TSD) là tài liệu cấp cao, ổn định theo thời gian, mô tả cách tiếp cận tổng thể của tổ chức/sản phẩm đối với chất lượng: chúng ta test ở những tầng nào, dùng công cụ gì, tiêu chí ra vào (entry/exit) ra sao, vai trò trách nhiệm thế nào. Nó không phải là danh sách test case, không phải lịch chạy test của sprint này, không phải bug report. Những thứ chi tiết và hay thay đổi đó thuộc về test plan và các artifact cấp thấp hơn.

Một cách dễ nhớ: TSD trả lời câu hỏi "How & Why" (chúng ta tiếp cận chất lượng thế nào và vì sao chọn cách đó), còn test plan trả lời "What & When" (test cái gì, khi nào, ai làm ở sprint/release cụ thể).

Vì sao nên viết dạng "one-page strategy"

Có hai trường phái. Trường phái IEEE 829 truyền thống tạo ra tài liệu dày cộp, đầy đủ mục nhưng nặng nề, thường bị bỏ xó sau khi ký duyệt. Trường phái hiện đại — mà tôi khuyến khích cho đa số team Việt Nam — là one-page strategy: cô đọng toàn bộ chiến lược vào một trang (hoặc một wiki page cuộn được vài màn hình). Triết lý ở đây là: nếu chiến lược không đủ ngắn để cả team đọc và nhớ, thì nó sẽ không định hình được hành vi hằng ngày của họ. Tài liệu càng dài, xác suất được đọc càng thấp.

Bộ khung 8 mục của một Test Strategy Document

Dưới đây là template cốt lõi. Bạn không nhất thiết phải có đủ 8 mục, nhưng đây là bộ khung đầy đủ để bạn "trừ đi" chứ đừng "thêm vào".

1. Vision (Tầm nhìn chất lượng). Một đến hai câu tuyên ngôn về triết lý chất lượng của team. Ví dụ kinh điển: "Quality is everyone's responsibility. QA owns the test strategy." (Chất lượng là trách nhiệm của mọi người; QA sở hữu chiến lược kiểm thử.) Câu này rất quan trọng về mặt văn hóa: nó nói rõ QA không phải là "chốt chặn cuối" gánh mọi lỗi, mà là người điều phối và làm chủ cách tiếp cận, còn chất lượng thì cả team cùng chịu.

2. Scope (Phạm vi). Liệt kê rõ In-scope (test cái gì: sản phẩm web, mobile app, các API công khai...) và Out-of-scope (không test cái gì: hệ thống bên thứ ba, môi trường của đối tác...). Phần out-of-scope thường bị bỏ quên nhưng lại cực kỳ giá trị — nó giúp bạn tránh bị đổ lỗi cho những thứ ngoài tầm kiểm soát.

3. Test Levels & Types (Tầng và loại kiểm thử). Chúng ta test ở những tầng nào — unit, integration, API, E2E, UI? Ai chịu trách nhiệm tầng nào (thường Dev lo unit, QA lo integration trở lên)? Có làm non-functional (performance, security) không? Đây là nơi bạn thể hiện tư duy test pyramid.

4. Test Approach (Cách tiếp cận). Chúng ta ưu tiên automation hay manual? Áp dụng risk-based ở đâu? Shift-left tới mức nào? Đây là phần "chất xám" của chiến lược.

5. Tools & Environments (Công cụ và môi trường). Framework automation (Playwright, Cypress...), quản lý test case (TestRail, Xray...), CI/CD chạy test ở đâu, có mấy môi trường (dev/staging/UAT/prod).

6. Entry & Exit Criteria (Tiêu chí ra vào). Khi nào được bắt đầu test (entry) và khi nào coi là "test xong, đủ điều kiện release" (exit). Ví dụ exit: 100% test case P1 pass, không còn bug Critical/High mở, code coverage tối thiểu 70%.

7. Roles & Responsibilities (Vai trò & trách nhiệm). Ai làm gì. Nên dùng dạng bảng RACI ngắn gọn để tránh cảnh "tưởng người kia làm".

8. Metrics & Reporting (Chỉ số & báo cáo). Chúng ta đo chất lượng bằng chỉ số nào (defect density, escape rate, pass rate...) và báo cáo cho ai, tần suất nào. (Chi tiết về metric bạn đã và sẽ học ở các bài chuyên đề, ở đây chỉ cần chốt danh sách dùng cho tài liệu này.)

Một tài liệu "sống" chứ không phải "chết"

Điểm mấu chốt cuối cùng: TSD phải có owner (thường là QA Lead/QA Manager), ngày cập nhật gần nhất, và lịch review định kỳ (ví dụ mỗi quý). Một tài liệu ghi "cập nhật lần cuối: 2 năm trước" tự nó đã mất hết uy tín. Hãy để nó ở nơi cả team đi qua hằng ngày — Confluence, Notion, hoặc file README trong repo test.

Tình huống thực tế

Ví dụ 1 — Startup fintech "MoMoni" (giả định), 8 kỹ sư, không ai chịu đọc tài liệu

MoMoni là một startup ví điện tử ở TP.HCM, đội engineering 8 người, mới có 1 QA duy nhất tên Hà. Sếp bảo Hà: "Em viết cái test strategy cho anh." Hà lên mạng tải một template IEEE 829 dài 38 trang, điền hùng hục 3 ngày, gửi cho team. Kết quả: không một ai đọc quá trang 2. Sau đó mỗi lần có bug lọt lên production, Dev vẫn đổ cho Hà "sao không test kỹ", còn Hà thì ấm ức vì đã "có strategy rồi".

Sau khi được mentor tư vấn, Hà xóa hết và viết lại một trang duy nhất trên Notion. Vision: "Chất lượng là việc của cả team; QA sở hữu chiến lược, Dev sở hữu unit test." Scope: chỉ web app + API thanh toán; out-of-scope: SDK của cổng thanh toán VNPay. Approach: risk-based, ưu tiên automation cho luồng nạp/rút tiền, còn lại test manual. Exit criteria: không còn bug Critical/High ở luồng tiền. Roles: bảng 6 dòng ghi rõ Dev viết unit test, Hà làm integration + E2E.

Bài học: với team nhỏ, độ dài của tài liệu tỉ lệ nghịch với xác suất nó được dùng. Một trang được cả team đọc và đồng thuận có giá trị gấp trăm lần 38 trang bị bỏ xó. Và mục Roles đã cứu Hà: từ đó khi bug unit-level lọt ra, mọi người nhìn lại bảng và hiểu đó là phần Dev cam kết.

Ví dụ 2 — Ngân hàng "VietBank" (giả định) — vì sao ở đây one-page là chưa đủ

VietBank triển khai hệ thống core banking mới. QA Manager Tuấn cũng thích one-page, nhưng khi làm việc với bộ phận tuân thủ (compliance) và kiểm toán nội bộ, anh nhận ra: trong môi trường ngân hàng chịu quy định của Ngân hàng Nhà nước (SBV) và chuẩn PCI-DSS, tài liệu chiến lược phải để lại dấu vết audit — ai phê duyệt, phiên bản nào, tiêu chí ra vào chi tiết ra sao.

Giải pháp của Tuấn là cấu trúc hai lớp: một trang "Strategy on a Page" đặt ở đầu Confluence để mọi kỹ sư đọc nhanh, và bên dưới là các trang con chi tiết (entry/exit đầy đủ, ma trận rủi ro, danh mục môi trường, lịch sử phê duyệt có chữ ký điện tử của Head of QA và Compliance). Bản one-page phục vụ sự thấu hiểu hằng ngày; các trang con phục vụ nghĩa vụ tuân thủ và audit.

Bài học: template không phải "một cỡ vừa tất cả". Bối cảnh quy định (regulated industry) quyết định độ dày và tính trang trọng của tài liệu. Nhưng ngay cả ở ngân hàng, phần cốt lõi dễ hiểu vẫn nên gói gọn một trang — phần dày cộp là phụ lục để tuân thủ, không phải để đọc mỗi ngày.

Ví dụ 3 — Công ty gia công phần mềm ở Đà Nẵng, chiến lược per-project

Một công ty outsourcing ở Đà Nẵng nhận nhiều dự án cho khách châu Âu và Nhật. QA Lead Linh gặp vấn đề: mỗi khách hàng có một bối cảnh chất lượng khác nhau (khách Nhật cực kỹ về UI pixel, khách EU quan tâm accessibility và GDPR), nên không thể có một strategy chung. Linh tạo một template chuẩn của công ty (8 mục như trên) rồi mỗi dự án fork ra một bản, điền phần đặc thù. Khi kick-off dự án mới, việc đầu tiên team làm là ngồi cùng nhau điền template trong 90 phút — biến nó thành một hoạt động đồng thuận chứ không phải văn bản một người viết.

Bài học: template chuẩn hóa giúp mọi dự án có cùng "bộ xương", giảm thời gian khởi động và đảm bảo không bỏ sót mục quan trọng (như out-of-scope hay exit criteria). Và việc cùng nhau điền template biến tài liệu từ "văn bản hành chính" thành "cam kết tập thể".

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

Đây là quy trình tôi khuyên bạn dùng để viết một Test Strategy Document từ con số không:

• Chọn nơi ở cho tài liệu. Đặt nó ở nơi team đi qua hằng ngày: Confluence, Notion, hoặc TEST_STRATEGY.md trong repo. Tránh file Word gửi qua email — nó sẽ chết ngay.

• Bắt đầu bằng Vision, viết bằng chính giọng của team. Một hai câu. Đừng chép nguyên xi câu mẫu; hãy điều chỉnh cho hợp văn hóa team bạn. Câu Vision tốt là câu mà team tin chứ không phải câu nghe kêu.

• Chốt Scope, đặc biệt là Out-of-scope. Ngồi với PM và Dev Lead, liệt kê rõ cái gì test, cái gì không. Viết out-of-scope ra giấy trắng mực đen — đây là "áo giáp" của bạn sau này.

• Vẽ Test Levels và gán chủ sở hữu. Dùng test pyramid làm khung: unit (Dev) → integration/API (QA + Dev) → E2E (QA). Ghi rõ tầng nào ai lo.

• Viết Approach ngắn gọn. Trả lời 3 câu: Ưu tiên automation hay manual, ở đâu? Risk-based áp dụng thế nào? Shift-left tới đâu?

• Điền Tools & Environments. Liệt kê thẳng: framework, tool quản lý test, CI, số môi trường.

• Định nghĩa Entry & Exit Criteria đo được. Tránh câu chung chung. "Test kỹ" là vô nghĩa; "0 bug Critical/High mở, 100% test P1 pass, coverage ≥70%" mới dùng được.

• Lập bảng Roles (RACI mini). 5–8 dòng, mỗi dòng một hoạt động và người chịu trách nhiệm.

• Chốt Metrics & Reporting. Chọn 3–5 chỉ số, ghi báo cáo cho ai, tần suất nào.

• Gán Owner, ngày cập nhật, lịch review. Ghi tên người sở hữu, ngày hôm nay, và "review lại vào cuối quý". Rồi đưa cả team đọc và xin đồng thuận — đây là bước biến tài liệu thành cam kết.

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

• Lỗi: Viết quá dài. Template 40 trang gần như chắc chắn không ai đọc. Mẹo: nếu không gói được phần cốt lõi trong một trang, bạn chưa đủ rõ về chiến lược của mình. Dày chỉ dành cho phụ lục tuân thủ.

• Lỗi: Copy template có sẵn mà không tùy biến. Tải một strategy của công ty khác về rồi đổi tên. Mẹo: template chỉ là bộ xương; phần thịt (scope, approach, criteria) phải sinh ra từ bối cảnh thật của team bạn.

• Lỗi: Bỏ quên Out-of-scope. Chỉ ghi "test cái gì" mà không ghi "không test cái gì". Mẹo: out-of-scope là công cụ bảo vệ bạn khỏi kỳ vọng phi lý và khỏi bị đổ lỗi oan.

• Lỗi: Exit criteria mơ hồ. Viết "khi chất lượng ổn thì release". Mẹo: mọi tiêu chí phải đo được bằng con số hoặc trạng thái nhị phân (đạt/không đạt).

• Lỗi: Tài liệu chết. Viết một lần rồi bỏ. Mẹo: gán owner + ngày review định kỳ. Không có owner thì không có ai chịu trách nhiệm giữ nó sống.

• Lỗi: QA viết một mình rồi thông báo. Mẹo: biến việc viết TSD thành workshop đồng thuận với Dev và PM — người ta chỉ tuân theo cái mà họ tham gia tạo ra.

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

• Viết one-page strategy cho một sản phẩm bạn biết. Chọn một app quen thuộc (ví dụ một app đặt đồ ăn). Mở một trang trống và điền đủ 8 mục: Vision, Scope (kèm Out-of-scope), Test Levels, Approach, Tools & Environments, Entry/Exit Criteria, Roles, Metrics. Giới hạn đúng một trang.

• Viết Exit Criteria đo được. Với sản phẩm ở bài 1, viết 4 điều kiện exit, mỗi điều kiện phải là một con số hoặc trạng thái đạt/không-đạt. Tự kiểm tra: nếu một điều kiện không thể trả lời "đạt hay chưa" chỉ bằng dữ liệu, hãy viết lại.

• So sánh hai bối cảnh. Viết một đoạn ngắn giải thích: nếu sản phẩm đó là của một ngân hàng thay vì một startup, ba mục nào trong template sẽ thay đổi nhiều nhất và thay đổi ra sao?

• Lập bảng RACI mini. Tạo bảng Roles với ít nhất 6 hoạt động (viết unit test, viết integration test, duyệt exit criteria, chạy performance test, phê duyệt release, báo cáo metrics) và gán người chịu trách nhiệm cho từng dòng.

Tóm tắt

Test Strategy Document là thứ biến chiến lược từ "ý định trong đầu QA Lead" thành "cam kết chung của cả team". Bài này tập trung vào cái template cụ thể: bộ khung 8 mục — Vision, Scope, Test Levels & Types, Approach, Tools & Environments, Entry/Exit Criteria, Roles & Responsibilities, và Metrics & Reporting. Nguyên tắc vàng là one-page strategy: cô đọng, sống động, được cập nhật và được cả team đọc; phần dày cộp chỉ dành cho phụ lục tuân thủ trong môi trường bị quy định như ngân hàng. Qua ba tình huống — startup fintech, ngân hàng, và công ty gia công — bạn thấy template không phải "một cỡ vừa tất cả", nhưng phần cốt lõi dễ hiểu thì luôn nên gọn gàng. Cuối cùng, một TSD chỉ thực sự có giá trị khi nó có owner, có ngày review, và được sinh ra từ sự đồng thuận chứ không phải từ một người viết đơn độc. Hãy nhớ: tài liệu ngắn được cả team đọc luôn thắng tài liệu dài bị bỏ xó.