CodeStar Academy > Kiến Thức Kiểm Thử > Test plan là gì? Cách viết Test plan theo chuẩn IEEE 829

Test plan là gì? Cách viết Test plan theo chuẩn IEEE 829

Không có phản hồi

Trong mọi dự án phần mềm, để xây dựng nên một sản phẩm chất lượng thì không thể thiếu “bản thiết kế” cho quá trình kiểm thử. Tài liệu đó chính là Test Plan. Nó không chỉ là một danh sách công việc, mà là kim chỉ nam chiến lược giúp toàn bộ đội ngũ đi đúng hướng, tránh lãng phí nguồn lực và không bỏ sót các lỗi quan trọng. Vậy Test Plan là gì và làm thế nào để viết Test Plan theo chuẩn IEEE 829? Bài viết hôm nay của CodeStar sẽ hướng dẫn bạn chi tiết từng bước.

Test plan là gì?

Test Plan (Kế hoạch kiểm thử) là một tài liệu chi tiết mô tả toàn bộ phạm vi, mục tiêu, chiến lược, nguồn lực và lịch trình của các hoạt động kiểm thử phần mềm. Test Plan trả lời các câu hỏi cốt lõi như:

  • Cái gì cần kiểm thử?
  • Làm thế nào để kiểm thử?
  • Khi nào kiểm thử?
  • Ai sẽ kiểm thử?
  • Khi nào thì dừng lại?

Tại sao Test Plan lại quan trọng trong kiểm thử phần mềm?

Việc tạo ra một Test Plan không chỉ là một thủ tục. Nó mang lại những giá trị cốt lõi cho dự án:

  • Định hướng rõ ràng: Giúp đội ngũ kiểm thử (Tester), nhà phát triển (Developer) và các bên liên quan (Stakeholder) hiểu rõ mục tiêu và quy trình kiểm thử.
  • Quản lý phạm vi: Xác định rõ ràng các tính năng sẽ được kiểm thử (in-scope) và không được kiểm thử (out-of-scope), tránh lãng phí nguồn lực.
  • Cơ sở giao tiếp: Là tài liệu chính thức để quản lý dự án, khách hàng nắm bắt tiến độ và chiến lược đảm bảo chất lượng.
  • Quản lý rủi ro: Giúp nhận diện sớm các rủi ro tiềm ẩn (VD: thiếu thiết bị, môi trường không ổn định) và lên kế hoạch dự phòng.
  • Nền tảng cho Test Case: Test Plan là tài liệu mẹ, định hướng cho việc viết các tài liệu chi tiết hơn như Test Case, Test Scenario.

Hướng dẫn cách viết Test Plan theo chuuẩn IEEE 829

Testplan là thành phần không thể thiếu được trong các dự án có phase test, sau đây là các thành phần trong testplan theo chuẩn IEEE 829.

1. Test Plan Identifier

• Phần cung cấp thông tin định danh cho tài liệu testplan. Đặt tên tài liệu theo hướng dẫn cấu hình quy định trong tài liệu quy trình đã ban hành
• Chính là 1 phần của sheet Cover

2. Introduction

• Cung cấp thông tin tổng quan về test plan
• Mục đích/ mục tiêu của dự án
• Ràng buộc/ giả định(nếu có)

3. References

• Các tài liệu liên quan mà test plan tham chiếu đến, ví dụ:
o Kế hoạch dự án
o Kế hoạch quản lý cấu hình
o Tài liệu kiểm soát thay đổi

4. Test Items/ Features to be Tested

• Các hạng mục, chức năng cần test
• Phần này thường là các chức năng cần thực hiện có trong sheets “Schedule”.
• Trong phần này, tùy thuộc vào mức độ phức tạp của từng dự án, mà từng function/module có thể chia nhỏ thành mức detail hơn để tránh miss chức năng và dễ quản lý hơn.
• Danh sách các chức năng cần test cần được chia theo độ ưu tiên(High, Normal, Low)

5. Features Not to Be Tested

• Danh sách các tính năng/ sản phẩm không cần test, và kèm theo lý do vì sao không test.
• Lý do không test có thể là:

  • Chức năng đó không có trong đợt release này
  • Chức năng thuộc phần phát triển của khách hàng or bên khác #6. Approach • Mô tả phương pháp tiếp cận trong kiểm thử của dự án • Chiến lược xây dựng testcase(Phân tích giá trị biên, phân vùng tương đương, trạng thái…) • Các level test cần thực hiện
  • Unit test
  • Integration test
  • System test
  • Acceptance test • Test types
  • Functions
  • Non-function
  • Regression test
  • Smoke test… • Loại metrics cần đo lường(ví dụ: tổng số testcase, số bug… phần này sẽ quy định trong test report)

6. Item Pass/Fail Criteria

Tiêu chí pass/Fail phụ thuộc vào từng level cụ thể.
Đối với unit test

  • Hoàn thành all testcases
  • Mức độ bao phủ của sc

Đối với master testplan, tiêu chí pass có thể là:

  • Hoàn thành tất cả các testplan level con
  • Một kế hoạch ở level con nào đó được chỉ định đã hoàn thành không có lỗi, hoặc có bao nhiêu % lỗi nhỏ.

Đối với level testplan, tiêu chí pass có thể

  • Done hết các testcases
  • Done hết 100% case high and normal, and done 90% case low…

Thường tiêu chí pass không đánh giá dựa theo total number defects, do việc phán đoán tổng số defect trong 1 ứng dụng là không thể, vì có 1 số defect gần như không bao giờ được tìm thấy, or ở thời điểm test chưa thể tìm thấy được

7. Suspension Criteria and Resumption Requirements

Tiêu chí tạm dừng và tiêu chí bắt đầu lại

  • Thông thường chúng ta không thể test mãi được, cần phải cân nhắc giữa Quality – Time và Cost, nên cần phải xác định test đến bao giờ thì dừng. Đây chính là tiêu chí đặc biệt để dừng hoạt động test(Đôi lúc nó hơi giống với tiêu chí pass ở mục trên),
  • Và đối với 1 hệ thống/ ứng dụng không chỉ test duy nhất 1 lần, có thể do CR, do maintain, do có feedback… thì lúc đó cần phải bắt đầu lại hoạt động test

8. Test Deliverables

Tài liệu test cần bàn giao

  • Danh sách các loại tài liệu test cần phải bàn giao trong dự án, có thể bao gồm: . Test plan . Test case . Test data . Check list . List bug . Test report

9.Test Environment

Môi trường test
Là môi trường về phần cứng, phần mềm, cơ sở hạ tầng… phục vụ cho công việc test trong dự án.
Danh sách tool liên quan
Trong phần này, đối với dự án thực tế, copy thông tin trong project plan là đủ.

10. Estimate

Cung cấp thông tin liên quan tới công số tổng thể và công số chi tiết của tất cả các hoạt động test trong dự án

11. Schedule

Cung cấp thông tin lịch trình của các milestones, sprins, tasks.
Staffing and Training Needs:
• Training kỹ năng, nghiệm vụ cần thiết cho tester
• Training có thể tham gia training bên ngoài hoặc training nội bộ

12. Responsibilities

• Danh sách nhân sự tester tham gia, vai trò, trách nhiệm trong dự án

13. Risks

• Liệt kê rủi ro có thể xảy ra trong dự án, rủi ro có thể là cơ hội or nguy cơ, nếu là cơ hội thì tìm cách tăng khả năng đạt được cơ hội, , nếu là nguy cơ, đưa ra kế hoạch dự phòng, phương án ứng phó kịp thời.
• Một số rủi ro thường gặp

  • Tài liệu không rõ ràng, không đầy đủ
  • Chức năng khó, phức tạp
  • Kỹ thuật mới, kỹ thuật khó
  • Nhân sự yếu
  • Nhân sự nghỉ ốm
  • Risk về mặt quản lý
  • Khách hàng phản hồi Q&A chậm

• Đối với từng dự án cụ thể, cần xác định được danh sách các rủi ro, sau khi đã xác định danh sách rủi ro, phân tích giải pháp, đưa ra phương án ứng phó cho từng rủi ro cụ thể

14. Approvals

• Tên, chức vụ của người phê duyệt test plan.
• Thông tin chữ ký, ngày ký (Nếu lưu trữ bản cứng)

Các bạn lưu ý đối với testplan là cần phải baseline và update khi có thay đổi trong quá trình thực hiện.

Tóm lại, Test Plan chính là tài liệu xương sống, là kim chỉ nam định hướng toàn bộ quá trình kiểm thử phần mềm. Việc nắm vững cách xây dựng một bản kế hoạch chi tiết, đầy đủ theo chuẩn IEEE 829 không chỉ giúp bạn kiểm soát chất lượng dự án một cách hiệu quả mà còn thể hiện rõ năng lực và sự chuyên nghiệp của một Software Tester.

Tuy nhiên, từ lý thuyết đến thực hành là một quá trình cần sự hướng dẫn và kinh nghiệm thực chiến. Nếu bạn muốn biến những kiến thức này thành kỹ năng vững chắc, tự tin xây dựng Test Plan cho các dự án thực tế và bắt đầu sự nghiệp kiểm thử phần mềm, hãy tham khảo ngay Khóa học Tester cho người mới bắt đầu tại CodeStar. Chúng tôi sẽ đồng hành cùng bạn, biến kiến thức nền tảng thành lợi thế cạnh tranh trên con đường sự nghiệp!

Trả lời