Checklist Static Testing

Yêu cầu có một nghĩa duy nhất không?

Không dùng từ mơ hồ như "nhanh", "dễ dùng", "phù hợp"

Yêu cầu có thể kiểm tra được (testable) không?

Có thể viết test case cụ thể để xác nhận yêu cầu đạt hay không đạt

Yêu cầu có đầy đủ thông tin không?

Input, output, điều kiện, giới hạn, trạng thái lỗi đều được mô tả rõ

Yêu cầu có nhất quán với các yêu cầu khác không?

Không mâu thuẫn hoặc xung đột với user story / requirement khác trong cùng hệ thống

Acceptance Criteria (tiêu chí chấp nhận) có được định nghĩa rõ ràng không?

Mỗi user story cần có ít nhất một AC cụ thể, đo lường được

Các luồng ngoại lệ (exception flow) và edge case có được đề cập không?

Ví dụ: nhập sai định dạng, để trống, vượt quá giới hạn ký tự

Yêu cầu có được ưu tiên (priority) và phân loại đúng không?

Must have / Should have / Nice to have hoặc mức độ tương đương

Yêu cầu có thể thực hiện được trong phạm vi dự án không?

Xem xét nguồn lực, thời gian, công nghệ hiện có của team

Có thể trace yêu cầu này ngược về business goal ban đầu không?

Traceability: yêu cầu phải có mối liên hệ rõ ràng đến mục tiêu kinh doanh

Phạm vi kiểm thử (test scope) có được xác định rõ ràng chưa?

In-scope và out-scope phải được liệt kê cụ thể, không để mơ hồ

Các loại kiểm thử cần thực hiện có được đề cập đủ không?

Functional, regression, performance, security… tùy dự án

Entry criteria và Exit criteria có được định nghĩa không?

Khi nào bắt đầu test được, khi nào được coi là xong

Môi trường kiểm thử (test environment) có được mô tả cụ thể không?

OS, browser, device, server, database version cần thiết

Rủi ro kiểm thử (test risks) có được nhận diện và có plan giảm thiểu không?

Ví dụ: thiếu tài nguyên, yêu cầu chưa ổn định, time crunch

Lịch trình và nguồn lực có thực tế và khả thi không?

Timeline, phân công nhân sự, effort estimate phù hợp thực tế

Quy trình báo cáo bug và theo dõi defect có được mô tả không?

Tool dùng để log bug, severity/priority levels, quy trình retest và close bug

Test case có ID và tiêu đề mô tả đúng mục đích không?

Tên test case ngắn gọn, đủ nghĩa, người đọc hiểu ngay sẽ test gì

Preconditions (điều kiện tiên quyết) có được liệt kê đầy đủ không?

Trạng thái hệ thống, dữ liệu, tài khoản cần chuẩn bị trước khi chạy test

Các bước thực hiện (test steps) có đủ chi tiết và theo đúng thứ tự không?

Người khác đọc vào có thể thực hiện được ngay mà không cần hỏi thêm

Expected result (kết quả kỳ vọng) có cụ thể và đo lường được không?

Tránh ghi chung chung như "hệ thống hoạt động đúng" — phải nêu kết quả rõ ràng

Mỗi test case có kiểm tra đúng một chức năng/kịch bản duy nhất không?

Không nhồi nhiều luồng vào một test case — mỗi TC nên độc lập và tập trung

Test data (dữ liệu kiểm thử) có được chỉ định rõ ràng không?

Ghi cụ thể giá trị input cần dùng, không để người test tự đoán dữ liệu

Test case có được liên kết với requirement tương ứng không?

Traceability matrix: mỗi TC cần tham chiếu đến user story / requirement ID

Đã có test case bao phủ các trường hợp biên (boundary values) và negative test chưa?

Ví dụ: min/max value, null, empty string, ký tự đặc biệt, sai định dạng