Trang chủ Kho kiến thức Lý thuyết kiểm thử phần mềm: Lập kế hoạch và chiến lược test

Lý thuyết kiểm thử phần mềm: Lập kế hoạch và chiến lược test

Khám phá khái niệm, quy trình 8 bước lập kế hoạch và sự khác biệt với chiến lược kiểm thử phần mềm giúp quản lý dự án hiệu quả. Xem ngay mẫu test plan chuẩn.

kế hoạch kiểm thửchiến lược kiểm thửtest plan là gìquy trình test plansự khác biệt giữa test plan và test strategymẫu kế hoạch kiểm thử

 
Infographic Kế Hoạch và Chiến Lược Kiểm Thử Phần Mềm

1. Kế Hoạch Kiểm Thử (Test Plan)

description

1.1. Khái Niệm Kế Hoạch Kiểm Thử Là Gì?

Kế hoạch kiểm thử (Test Plan) là một tài liệu vô cùng chi tiết, được soạn thảo cẩn thận để mô tả toàn diện về phạm vi kiểm thử, phương pháp tiếp cận, nguồn tài nguyên và lịch trình của các hoạt động kiểm thử dự kiến.

Tài liệu này không chỉ đơn thuần là một danh sách các công việc, mà nó còn xác định rõ các hạng mục cần kiểm thử (test items), các tính năng sẽ được kiểm thử, các nhiệm vụ cụ thể cần thực hiện, người chịu trách nhiệm cho từng nhiệm vụ, cũng như mọi rủi ro tiềm ẩn đòi hỏi việc lập kế hoạch dự phòng. Kế hoạch kiểm thử thường được xây dựng bởi các Quản lý Kiểm thử (Test Managers) hoặc Trưởng nhóm Kiểm thử (Test Leads) có nhiều kinh nghiệm.

1.2. Tầm Quan Trọng Của Kế Hoạch Kiểm Thử

Việc thiết lập một kế hoạch kiểm thử bài bản mang lại những giá trị cốt lõi, tác động trực tiếp đến sự thành bại của dự án phần mềm. Các vai trò chính bao gồm:

map

Đóng vai trò như Bản Đồ Định Hướng

Kế hoạch kiểm thử đóng vai trò như một bản thiết kế chi tiết (blueprint) hoặc sách hướng dẫn cho toàn bộ đội ngũ. Nó định hướng các bước đi rõ ràng để quy trình kiểm thử diễn ra trơn tru, đi đúng hướng và hoàn thành mục tiêu chất lượng cuối cùng.

forum

Công cụ Giao Tiếp Hiệu Quả

Giúp các bên liên quan (stakeholders) bên ngoài nhóm kiểm thử, bao gồm nhà phát triển, quản lý dự án, đối tác kinh doanh và khách hàng, có thể hiểu rõ chi tiết về cách thức phần mềm của họ sẽ được kiểm tra và đánh giá.

shield

Kiểm Soát Nhịp Độ & Rủi Ro

Cung cấp cơ sở vững chắc để kiểm soát sự thay đổi, theo dõi tiến độ dự án. Nó xác định trước các rủi ro có thể xảy ra trong quá trình phát triển, từ đó nhóm có thể đề ra các biện pháp phòng ngừa và kế hoạch dự phòng (contingency plans) kịp thời.

inventory_2

Quản Lý Phân Bổ Tài Nguyên

Đảm bảo rằng thiết bị phần cứng, môi trường phần mềm, công cụ hỗ trợ và đặc biệt là nguồn nhân lực được phân bổ một cách hợp lý. Ước tính trước chi phí, nỗ lực và thời gian cần thiết để đội ngũ không bị quá tải hoặc thiếu hụt công cụ làm việc.

1.3. Các Loại Kế Hoạch Kiểm Thử

Tùy thuộc vào quy mô và cấp độ của dự án, kế hoạch kiểm thử được phân chia thành ba cấp độ chính để dễ dàng quản lý:

account_tree

Kế Hoạch Kiểm Thử Tổng Thể

Master Test Plan

Là tài liệu ở cấp độ cao nhất. Nó bao gồm nhiều kế hoạch kiểm thử nhỏ khác. Tài liệu này cung cấp cái nhìn toàn cảnh về mọi cấp độ kiểm thử trong hệ thống, thường được áp dụng cho các dự án lớn với nhiều phân hệ phức tạp.

view_timeline

Kế Hoạch Kiểm Thử Giai Đoạn

Phase Test Plan

Tài liệu tập trung chi tiết vào một giai đoạn kiểm thử duy nhất. Ví dụ, thiết lập kế hoạch riêng biệt chỉ dành cho Kiểm thử Tích hợp (Integration Testing), Kiểm thử Hệ thống (System Testing), hoặc Kiểm thử Chấp nhận (Acceptance Testing).

troubleshoot

Kế Hoạch Kiểm Thử Chuyên Biệt

Specific Test Plan

Tài liệu được thiết kế đặc biệt cho các loại hình kiểm thử phi chức năng hoặc kỹ thuật chuyên sâu. Các ví dụ điển hình bao gồm Kế hoạch Kiểm thử Hiệu năng (Performance Test Plan) và Kế hoạch Kiểm thử Bảo mật (Security Test Plan).

1.4. Quy Trình 8 Bước Viết Kế Hoạch Kiểm Thử

Để tạo ra một kế hoạch hiệu quả và thực tế, quy trình soạn thảo thường tuân theo 8 bước cơ bản sau đây. Việc bỏ qua bất kỳ bước nào cũng có thể dẫn đến sai sót trong quá trình kiểm thử.

1

Phân Tích Sản Phẩm (Analyze the Product)

  • Đội ngũ kiểm thử cần nghiên cứu sâu sắc về sản phẩm. Mục đích là để hiểu rõ phần mềm này phục vụ ai, giải quyết vấn đề gì.
  • Tìm hiểu đối tượng người dùng cuối (end-users) là ai, độ tuổi, hành vi sử dụng của họ để có góc nhìn kiểm thử thực tế.
  • Nắm vững cả thành phần phần cứng và phần mềm cấu thành nên hệ thống. Việc hiểu cấu trúc giúp việc kiểm thử kỹ thuật chính xác hơn.
  • Làm rõ mục tiêu cốt lõi của sản phẩm phần mềm, những giá trị kinh doanh mà nó mang lại cho khách hàng.
2

Thiết Kế Chiến Lược Kiểm Thử (Design Test Strategy)

  • Bước này đòi hỏi việc vạch ra các định hướng cấp cao. Nó là nền tảng chỉ đạo cho toàn bộ quy trình kiểm thử tiếp theo.
  • Xác định giới hạn của phạm vi kiểm thử (Scope of Testing). Cần liệt kê rõ những tính năng nào sẽ được kiểm thử và đặc biệt, những tính năng nào không nằm trong phạm vi kiểm thử.
  • Ước tính sơ bộ về ngân sách và thời gian để đảm bảo chiến lược khả thi với nguồn lực hiện có của tổ chức.
3

Xác Định Mục Tiêu Kiểm Thử (Define the Test Objectives)

  • Mục tiêu không chỉ là "tìm lỗi". Nó bao gồm nhiều yếu tố để đánh giá chất lượng phần mềm một cách toàn diện.
  • Xác định mục tiêu rà soát tất cả các lỗi phần mềm (software defects) có thể ảnh hưởng đến trải nghiệm người dùng.
  • Đảm bảo rằng phần mềm không có lỗi lầm nghiêm trọng trước khi phát hành. Phát hành phần mềm không lỗi (bug-free) là ưu tiên hàng đầu.
  • Xác minh xem sản phẩm cuối cùng có thực hiện đầy đủ các tính năng như đã được mô tả trong tài liệu đặc tả yêu cầu hay không.
4

Định Nghĩa Các Tiêu Chí Kiểm Thử (Define Test Criteria)

  • Tiêu chí giúp chuẩn hóa việc ra quyết định trong kiểm thử. Có hai loại tiêu chí vô cùng quan trọng cần thiết lập rõ ràng.
  • Tiêu chí Tạm dừng (Suspension Criteria): Quy định rõ các điều kiện bắt buộc nhóm kiểm thử phải tạm dừng công việc. Ví dụ: Khi môi trường thử nghiệm bị sập, hoặc khi phát hiện một lỗi chặn (blocker bug) khiến 40% các trường hợp kiểm thử bị thất bại. Tiếp tục kiểm thử lúc này là vô ích và tốn kém.
  • Tiêu chí Thoát (Exit Criteria): Các điều kiện tiên quyết chứng minh giai đoạn kiểm thử đã hoàn thành xuất sắc và phần mềm sẵn sàng ra mắt. Ví dụ: 100% các trường hợp kiểm thử đã được chạy, 95% tỷ lệ vượt qua (pass rate), không còn lỗi nghiêm trọng cấp 1 hoặc cấp 2.
5

Lập Kế Hoạch Tài Nguyên (Resource Planning)

  • Tài nguyên là mọi thứ cần thiết để thực thi kiểm thử, không chỉ dừng lại ở con người.
  • Liệt kê chi tiết số lượng nhân sự, phân bổ nhiệm vụ, vị trí vai trò (như Tester tự động, Tester thủ công, Quản lý). Đánh giá kỹ năng hiện tại của nhân sự.
  • Liệt kê các yêu cầu về hệ thống như máy chủ ảo (VM), cơ sở dữ liệu, chứng chỉ bảo mật (SSL) cần thiết cho dự án.
6

Thiết Lập Môi Trường Kiểm Thử (Plan Test Environment)

  • Môi trường kiểm thử phải mô phỏng chính xác, hoặc gần chính xác nhất, với môi trường thực tế (production) mà người dùng sẽ sử dụng.
  • Chuẩn bị các cấu hình phần cứng cần thiết, giả lập cấu hình mạng, băng thông internet.
  • Xác định các nền tảng hệ điều hành (Windows, Linux, macOS) và trình duyệt (Chrome, Safari, Firefox) cần kiểm thử để đảm bảo tính tương thích chéo.
7

Lập Lịch Trình & Đánh Giá (Schedule and Estimation)

  • Thiết lập mốc thời gian rõ ràng giúp quản lý tiến độ và kiểm soát sự chậm trễ.
  • Áp dụng các kỹ thuật phân rã công việc. Chia nhỏ toàn bộ dự án thành các nhiệm vụ nhỏ hơn, dễ quản lý hơn để ước lượng chính xác nỗ lực cần bỏ ra.
  • Xây dựng một lịch trình biểu diễn chi tiết thời gian bắt đầu và kết thúc của từng tác vụ kiểm thử (như viết kịch bản, chạy kịch bản, báo cáo lỗi).
8

Xác Định Sản Phẩm Chuyển Giao (Determine Test Deliverables)

  • Test Deliverables là danh sách toàn bộ các tài liệu, kết quả, báo cáo và công cụ được tạo ra trong vòng đời kiểm thử để chuyển giao cho các bên liên quan.
  • Trước kiểm thử: Kế hoạch kiểm thử (tài liệu này), Tài liệu thiết kế kịch bản kiểm thử (Test Case documents).
  • Trong kiểm thử: Các kịch bản chạy tự động (Test Scripts), Dữ liệu kiểm thử, Báo cáo theo dõi lỗi (Bug tracking reports).
  • Sau kiểm thử: Báo cáo tổng kết toàn bộ quá trình kiểm thử (Test Summary Report), Số liệu đo lường chất lượng, Bản tin phát hành (Release notes).

2. Chiến Lược Kiểm Thử (Test Strategy)

strategy

2.1. Khái Niệm Chiến Lược Kiểm Thử

Chiến lược kiểm thử (Test Strategy) là một tài liệu ở mức cao (high-level document) xác định phương pháp tiếp cận và cách thức quản lý quy trình kiểm thử. Tùy thuộc vào quy mô tổ chức, chiến lược này có thể là một tài liệu riêng biệt hoặc được nhúng dưới dạng một phần nhỏ trong Kế hoạch Kiểm thử tổng thể.

Khác với Kế hoạch Kiểm thử có thể linh hoạt thay đổi theo từng đợt chạy (sprint) hoặc dự án, Chiến lược Kiểm thử thường là một tài liệu mang tính tĩnh (static document), áp dụng xuyên suốt cho toàn bộ dự án hoặc thậm chí toàn bộ công ty, định hình các tiêu chuẩn và nguyên tắc thiết kế việc kiểm thử.

2.2. Các Thành Phần Của Chiến Lược Kiểm Thử

Một bản Chiến lược Kiểm thử tốt cần phác thảo đầy đủ các thành phần ở mức hệ thống để mọi dự án tuân theo. Dưới đây là các thành phần chủ chốt:

track_changes

Phạm Vi & Mục Tiêu

Quy định ranh giới hệ thống, ai có quyền phê duyệt, thay đổi tài liệu. Nêu rõ mục tiêu tối thượng của việc kiểm thử trong toàn bộ vòng đời ứng dụng.

route

Cách Tiếp Cận

Xác định các phương pháp thiết kế kịch bản, các cấp độ kiểm thử bắt buộc (Unit, Integration, System, Acceptance), vai trò của từng thành viên trong tổ chức.

dns

Tiêu Chuẩn Môi Trường

Định nghĩa kiến trúc mạng tối thiểu, các thông số kỹ thuật bắt buộc để thiết lập môi trường (như yêu cầu về bảo mật, số lượng máy chủ).

build

Công Cụ Sử Dụng

Lựa chọn các công cụ tự động hóa tiêu chuẩn hóa cho công ty (ví dụ: Selenium, Cypress), công cụ quản lý lỗi (Jira), và các thư viện mã nguồn mở được phép dùng.

new_releases

Kiểm Soát Phát Hành

Đảm bảo việc thay đổi mã nguồn được quản lý chặt chẽ qua hệ thống quản lý phiên bản. Quy trình quản lý lịch sử kiểm thử trước mỗi lần phát hành (release).

warning

Phân Tích Rủi Ro & Đánh Giá

Chỉ đạo cách thức phân tích rủi ro hệ thống. Đồng thời thiết lập cơ chế xem xét lại (review) chiến lược định kỳ bởi đại diện dự án và đội quản lý.

2.3. Sự Khác Biệt Giữa Kế Hoạch & Chiến Lược Kiểm Thử

Rất nhiều người thường nhầm lẫn giữa hai khái niệm này. Bảng so sánh dưới đây phân tích các khía cạnh đối lập cốt lõi để làm rõ sự khác biệt của chúng.

Kế Hoạch Kiểm Thử
(Test Plan)

  • check_circle

    Định nghĩa cốt lõi: Mô tả chi tiết việc kiểm thử cái gì (What), khi nào (When), ở đâu (Where) và ai thực hiện (Who).

  • check_circle

    Cấp độ áp dụng: Hoạt động chủ yếu ở Cấp độ Dự án (Project Level). Mỗi dự án có một kế hoạch riêng biệt.

  • check_circle

    Tính linh hoạt: Là tài liệu linh hoạt, có thể thay đổi thường xuyên khi yêu cầu dự án cập nhật.

  • check_circle

    Động lực chi phối: Được định hình (driven) bởi các Phương pháp luận phát triển hiện hành và các quy định quản lý chất lượng.

  • check_circle

    Tồn tại độc lập: Thường là một tài liệu độc lập và rất chi tiết. Đôi khi có thể bao gồm phần tóm tắt của chiến lược bên trong nó.

Chiến Lược Kiểm Thử
(Test Strategy)

  • stars

    Định nghĩa cốt lõi: Hướng dẫn những nguyên lý ở mức cao về việc kiểm thử được thực hiện như thế nào (How).

  • stars

    Cấp độ áp dụng: Hoạt động mạnh mẽ ở Cấp độ Tổ chức (Organization Level). Áp dụng quy chuẩn chung cho mọi dự án công ty.

  • stars

    Tính linh hoạt: Là tài liệu tĩnh (static). Hầu như không bị thay đổi trong quá trình thực hiện dự án trừ khi có sự thay đổi lớn về công nghệ nền tảng.

  • stars

    Động lực chi phối: Nó là nhân tố chi phối (drives) ngược lại Kế hoạch Kiểm Thử. Kế hoạch phải dựa trên Chiến lược để viết.

  • stars

    Tồn tại độc lập: Thường được tìm thấy như một phân mục (section) quan trọng nằm bên trong các tài liệu thiết kế quy trình chung của tổ chức.

3. Cấu Trúc/Mẫu Của Một Kế Hoạch Kiểm Thử

Theo chuẩn IEEE 829, một tài liệu Test Plan toàn diện cần chứa 16 thuộc tính cụ thể. Để dễ hình dung, chúng ta chia chúng thành 4 nhóm chính. Đây là khuôn mẫu (template) tiêu chuẩn công nghiệp được áp dụng rộng rãi cho mọi quy mô dự án.

info Nhóm A: Thông Tin Định Danh

  • 1. Định danh Kế hoạch (Test Plan Identifier) Một mã định danh duy nhất do công ty quy định để phân biệt tài liệu này với các tài liệu dự án khác. Có thể bao gồm số phiên bản, ngày tháng tạo và cập nhật tài liệu (Ví dụ: TP-CRM-V1.2).
  • 2. Giới thiệu (Introduction) Phần này cung cấp bản tóm tắt ngắn gọn nhưng súc tích về đối tượng phần mềm sẽ được kiểm thử. Nêu bật mục tiêu tổng quan của dự án, bối cảnh ra đời sản phẩm.
  • 3. Hạng mục kiểm thử (Test Items) Định nghĩa cụ thể phiên bản phần mềm. Liệt kê rõ ràng danh sách các phân hệ phần mềm (modules) hoặc các thành phần chức năng sẽ là mục tiêu của quá trình kiểm thử này.

fact_check Nhóm B: Phạm Vi & Tiêu Chí Đánh Giá

  • 4. Tính năng cần kiểm thử (Features to be tested) Một danh sách rõ ràng, liệt kê mọi tính năng, chức năng chi tiết mà nhóm tester bắt buộc phải lên kịch bản để chạy và xác minh độ chính xác.
  • 5. Tính năng KHÔNG kiểm thử (Features not to be tested) Liệt kê các tính năng nằm ngoài phạm vi. Rất quan trọng để tránh lãng phí thời gian. Đồng thời, bắt buộc phải nêu rõ lý do tại sao không kiểm thử chúng (ví dụ: API do bên thứ 3 cung cấp, hoặc tính năng thuộc giai đoạn 2).
  • 6. Tiêu chí Đạt/Trượt (Item Pass/Fail Criteria) Xác định các chỉ số định lượng. Khi nào một tính năng hoặc một tập hợp kịch bản được coi là thành công (Pass) hay thất bại (Fail). Dựa vào đây để đưa ra đánh giá chính thức.
  • 7. Tiêu chí Tạm dừng (Suspension Criteria) Điều kiện kỹ thuật hoặc lỗi nghiêm trọng nào xảy ra khiến toàn bộ quá trình kiểm thử phải lập tức đóng băng (Ví dụ: Server sập liên tục, lỗi đăng nhập hệ thống).

engineering Nhóm C: Thực Thi & Yêu Cầu Nguồn Lực

  • 8. Phương pháp tiếp cận (Approach) Mô tả cụ thể dòng chảy công việc (workflow). Nêu rõ kiến trúc hệ thống tổng thể, ứng dụng các phương pháp luận (như Agile/Scrum), chiến thuật kiểm thử hồi quy, tự động hóa như thế nào.
  • 9. Nhiệm vụ kiểm thử (Testing Tasks) Danh sách mọi công việc cần làm: từ khâu phân tích yêu cầu ban đầu, chuẩn bị dữ liệu, thiết kế kịch bản, chạy kịch bản thực tế, ghi nhận lỗi, đến báo cáo nghiệm thu.
  • 10. Nhu cầu môi trường (Environmental Needs) Đặc tả yêu cầu phần cứng (RAM, CPU), phần mềm (OS version, trình duyệt), thiết lập cơ sở dữ liệu và cấu hình mạng thiết yếu để môi trường kiểm thử vận hành hoàn hảo.
  • 11. Yêu cầu Nhân sự & Đào tạo (Staffing & Training) Liệt kê số lượng tester cần thiết. Yêu cầu bộ kỹ năng cụ thể cho dự án (ví dụ: cần chứng chỉ ISTQB, biết lập trình Python). Kế hoạch tổ chức khóa đào tạo nếu nhân sự chưa đáp ứng đủ công nghệ mới.

calendar_month Nhóm D: Quản Lý, Rủi Ro & Phê Duyệt

  • 12. Phân công Trách nhiệm (Responsibilities) Gán tên và vai trò rõ ràng. Trách nhiệm của Quản lý Kiểm thử (lập kế hoạch), của Kỹ sư Kiểm thử (thực thi), của Developer (sửa lỗi) được phân tách bạch, không chồng chéo.
  • 13. Lịch trình (Schedule) Timeline chi tiết mô tả rõ ngày tháng bắt đầu, ngày dự kiến hoàn thành, các cột mốc (milestones) quan trọng cần đạt được trong từng giai đoạn phát triển.
  • 14. Sản phẩm chuyển giao (Test Deliverables) Cam kết các tài liệu đầu ra như: Danh sách Test Cases, Báo cáo tiến độ (Daily report), Log lỗi (Defect log), Báo cáo Tổng kết (Summary report) sẽ được bàn giao khi kết thúc dự án.
  • 15. Rủi ro & Kế hoạch dự phòng (Risks & Contingencies) Tiên lượng các rủi ro có thể gặp phải (VD: nhân sự nghỉ việc đột xuất, yêu cầu từ khách hàng thay đổi giờ chót). Đi kèm là các phương án đối phó (contingencies) chi tiết nhằm giảm thiểu thiệt hại.
  • 16. Phê duyệt (Approvals) Tên, chức vụ và chữ ký xác nhận của những người có thẩm quyền cao nhất (Project Manager, Khách hàng) đồng ý với toàn bộ Kế hoạch Kiểm thử trước khi nó được đưa vào triển khai thực tế.
done_all

Việc áp dụng đầy đủ mẫu cấu trúc trên giúp quy trình Đảm bảo chất lượng (QA) đạt chuẩn, chuyên nghiệp và có thể kiểm toán dễ dàng.

Mục lục
1. Kế Hoạch Kiểm Thử (Test Plan)
1.1. Khái Niệm Kế Hoạch Kiểm Thử Là Gì?
1.2. Tầm Quan Trọng Của Kế Hoạch Kiểm Thử
1.3. Các Loại Kế Hoạch Kiểm Thử
1.4. Quy Trình 8 Bước Viết Kế Hoạch Kiểm Thử
2. Chiến Lược Kiểm Thử (Test Strategy)
2.1. Khái Niệm Chiến Lược Kiểm Thử
2.2. Các Thành Phần Của Chiến Lược Kiểm Thử
2.3. Sự Khác Biệt Giữa Kế Hoạch & Chiến Lược Kiểm Thử
3. Cấu Trúc/Mẫu Của Một Kế Hoạch Kiểm Thử
info Nhóm A: Thông Tin Định Danh
fact_check Nhóm B: Phạm Vi & Tiêu Chí Đánh Giá
engineering Nhóm C: Thực Thi & Yêu Cầu Nguồn Lực
calendar_month Nhóm D: Quản Lý, Rủi Ro & Phê Duyệt
Khoá học liên quan
Khóa học Tester: Lý thuyết Kiểm thử phần mềm cơ bản từ A-Z

2.371 xem 12 kiến thức 5 đề thi

Kiến thức tương tự
img
Lý thuyết Kiểm thử Phần mềm: Bảng quyết định Decision Table

21.092 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: KT Cặp (Pairwise Testing)

21.150 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử phần mềm: Quy trình & Vòng đời SDLC STLC

20.973 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử phần mềm: Các thuật ngữ quan trọng

20.945 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: KT Phân tích Giá trị Biên BVA

21.038 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: PP phân vùng tương đương

21.068 lượt xem 11/04/2026

img
Lý thuyết kiểm thử phần mềm: Test Case & Test Data

21.011 lượt xem 11/04/2026

img
Lý thuyết Kiểm thử: KT theo ca sử dụng (Use Case Testing)

21.122 lượt xem 11/04/2026

img
Lý thuyết Kiểm Thử: KT CD Trạng Thái (State Transition Test)

21.100 lượt xem 11/04/2026