TEST PLAN Fundamentalsen - Những nguyên tắc cơ bản để lên kế hoạch kiểm thử

Lần trước, tôi đã cùng các bạn tìm hiểu về nghề kiểm thử phần mềm. Ngày hôm nay, tôi xin phép được chia sẻ với các bạn về một tài liệu tôi mới đọc được. Đó chính là "Những nguyên tắc cơ bản để lên kế hoạch kiểm thử".

1. Định nghĩa về Test Plan

• Kế hoạch kiểm thử phần mềm là một tài liệu mô tả phạm vi và các hoạt động thử nghiệm. Đó là cơ sở cho việc kiểm thử chính thức bất kỳ phần mềm / sản phẩm trong một dự án.
• ISTQB định nghĩa rằng:
  • Test plan: Một tài liệu mô tả phạm vi, phương pháp, nguồn lực và lịch trình của các hoạt động kiểm thử. Nó xác định dựa theo các mục kiểm thử khác nữa, các tính năng kiểm tra, các nhiệm vụ kiểm thử, những người sẽ làm mỗi công việc, trình độ của mỗi tester độc lập, kiểm thử môi trường, kỹ thuật kiểm thử design và tiêu chuẩn nhập và xuất để được sử dụng, và lý do cho sự lựa chọn của họ, và bất kỳ rủi ro đòi hỏi phải lập kế hoạch dự phòng. Đây là báo cáo của quá trình lập kế hoạch kiểm thử.
  • Master test plan: Một kế hoạch kiểm thử mà thường đề cập nhiều mức độ kieẻm thử.
  • Phase test plan: Một kế hoạch kiểm thử mà thường đề cập đến một giai đoạn kiểm thử.

2. Các loại Test Plan Test plan có các loại chính sau:

• Master test plan: Một kế hoạch kiểm thử cấp cao duy nhất cho một dự án / sản phẩm mà thống nhất từ tất cả các kế hoạch kiểm thử khác.
• Test ting Level Specifix Test Plans (Kiểm tra tra mức độ Kế hoạch kiểm thử cụ thể): Kế hoạch cho từng mức độ kiểm thử

• Kế hoạch Kiểm thử đơn vị
• Kế hoạch kiểm thử tích hợp
• Kế hoạch kiểm thử hệ thống
• Kế hoạch kiểm thử chấp nhận

• Testing Type Specific Test Plans: (oại Kế hoạch kieemrr thử cụ thể): Kế hoạch cho những công việc chính cũng như kế hoạch kiểm thử hiệu suất và kiểm thử bảo mật

3. Mẫu Test Plan (Test plan template): Các định dạng và nội dung của một kế hoạch kiểm thử phần mềm sẽ khác nhau tùy thuộc vào các quy trình, tiêu chuẩn và cấc công cụ quản lý công cụ test được thực hiện. Tuy nhiên, theo định dạng, nó dựa trên tiêu chuẩn IEEE cho tài liệu kiểm thử phần mềm, cung cấp một bản tóm tắt những gì mà một bản kế hoạch kiểm thử có thể/nên chứa.

4. Test Plan Identifier (Kế hoạch kiểm thử nhận dạng): Cung cấp một định danh duy nhất cho tài liệu. (Tuân thủ hệ thống quản lý cấu hình nếu bạn có một).

5. Giới thiệu:

• Cung cấp một cái nhìn tổng quan về kế hoạch kiểm thử
• Xác định các mục tiêu/đối tượng
• Xác định các ràng buộc

6. Tài liệu tham khảo Liệt kê các tài liệu liên quan, có liên hệ nếu có sẵn, bao gồm những điều sau:

• Kế hoạch dự án
• Kế hoạch quản lý cấu hình

7. Các mục kiểm thử: Liệt kê các hạng mục kiểm thử (phần mềm/sản phẩm) và các phiên bản.

8. Các tính năng đã được kiểm thử:

• Danh sách các tính năng của phần mềm / sản phẩm đã được kiểm tra.
• Cung cấp tài liệu tham khảo cho các yêu cầu và/hoặc thông số kỹ thuật thiết kế trong những tính năng đã được kiểm thử

9. Các tính năng Không Được kiểm thử:

• Danh sách các tính năng của phần mềm / sản phẩm đó sẽ không được kiểm tra.
• Xác định nguyên nhân các tính năng này không được kiểm tra.

10. Tiếp cận:

• Đề cập đến các phương pháp tiếp cận tổng thể để kiểm thử.
• Xác định mức độ kiểm thử [nếu đó là một kế hoạch test tổng thể], các loại kiểm thử, và các phương pháp thử [Manual / tự động; hộp trắng / Hộp đen / Hộp xám]

11. Tiêu chí mục pass/fail: Xác định các tiêu chí đó sẽ được sử dụng để xác định xem mỗi mục kiểm tra (phần mềm / sản phẩm) đã được thông qua hay không kiểm thử.

12. Tiêu chuẩn hệ thống treo và các yêu cầu kiểm tra lại:

• Xác định tiêu chí được sử dụng để ngừng các hoạt động kiểm thử.
• Xác định các hoạt động kiểm thử phải được chạy lại khi kiểm thử quay lại.

13. Kiểm thử phân phối: Danh sách kiểm thử phân phối, và liên kết nếu có, bao gồm những điều sau đây:

• Test Plan (tài liệu của chính nó)
• Test Cases
• Kiểm thử Scripts
• Defect / Enhancement Logs
• Báo cáo kiểm thử

14. Môi trường kiểm thử:

• Chỉ định các yêu cầu đối với môi trường kiểm thử: phần cứng, phần mềm, mạng, vv...
• Liệt kê các loại kiểm thử hoặc các công cụ liên quan.

15. Estimate: Cung cấp một bản tóm tắt của việc kiểm thử (chi phí hoặc thời gian) và / hoặc cung cấp một liên kết để lập dự toán chi tiết.

16. Schedule: Cung cấp một bản tóm tắt về lịch trình, xác định mốc thời gian kiểm thử quan trọng, và / hoặc cung cấp một liên kết đến lịch trình chi tiết.

17. Nhân sự và nhu cầu đào tạo:

• Xác định nhu cầu, vai trò và kỹ năng cần thiết của nhân sự
• Xác định rằng đào tạo là cần thiết để cung cấp những kỹ năng.

18. Trách nhiệm:

• Liệt kê những trách nhiệm của mỗi đội / vai trò / cá nhân.

19. Rủi ro:

• Liệt kê các rủi ro đã được xác định.
• Xác định kế hoạch giảm nhẹ và các kế hoạch dự phòng cho mỗi rủi ro.

20. Giả định và phụ thuộc:

• Liệt kê những giả định đã được thực hiện trong việc chuẩn bị kế hoạch này.
• Danh sách các phụ thuộc.

21. Phê duyệt:

• Chỉ định tên và vai trò của tất cả những người phải chấp thuận kế hoạch.
• Cung cấp khoảng trống cho chữ ký và ngày tháng. (Nếu tài liệu được in.)

22. Hướng dẫn kế hoạch thực thi

• Xây dựng kế hoạch ngắn gọn. Tránh dư thừa và không cần thiết. Nếu bạn nghĩ rằng bạn không cần một phần đã được đề cập trong các mẫu ở trên, táo bạo và xóa phần trong kế hoạch kiểm tra của bạn.
• Hãy cụ thể. Ví dụ, khi bạn chỉ định một hệ điều hành như một tài sản của một môi trường kiểm thử, đề cập đến các hệ điều hành Edition / Version là tốt, không chỉ tên hệ điều hành.
• Hãy sử dụng danh sách và bảng bất cứ nơi nào có thể. Tránh các đoạn văn dài dòng.
• Có các kế hoạch kiểm tra xem xét lại một số lần trước khi baselining nó hoặc gửi nó. Chất lượng của kế hoạch kiểm thử của bạn đã nói lên chất lượng của các kiểm thử bạn hoặc nhóm của bạn sẽ thực hiện.
• Cập nhật các kế hoạch khi cần thiết. Một tài liệu lỗi thời và không sử dụng tài liệu stinks và còn tệ hơn các tài liệu đầu tiên.

Nguồn dịch: http://softwaretestingfundamentals.com/test-plan/

Chúc các bạn có một ngày cuối tuần vui vẻ!!! ^_^