Testplan theo chuẩ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.