Review trong Kiểm thử Phần mềm

1. Khái niệm & Mục tiêu của Review

  • Review = Đánh giá một sản phẩm phần mềm hoặc tình trạng dự án để phát hiện sai sót, so sánh với kế hoạch và đề xuất cải tiến.

MỤC TIÊU CỦA KIỂM THỬ PHẦN MỀM ĐỂ LÀM GÌ?

  • Mục tiêu:

    • Tìm lỗi càng sớm càng tốt (trước khi chạy phần mềm).

    • Giúp tiết kiệm chi phí.

    • Chia sẻ kiến thức, nâng cao kỹ năng đội ngũ.

    • Cung cấp thông tin cho việc ra quyết định.

    • Thu thập dữ liệu để cải tiến quy trình.

2. Các loại Review

  • Education Review

  • Prepare Review

  • Peer Review (thường dùng nhất)

  • State Review

Trong thực tế, Peer Review là phổ biến nhất.

3. Các loại Peer Review

Sắp xếp từ formality cao → thấp:

  1. Inspection (hình thức chính thống nhất, nhiều bước, tìm được nhiều lỗi nhưng tốn kém).

  2. Team Review (nhẹ hơn inspection, bỏ giai đoạn phân tích).

  3. Walkthrough (tác giả có thể dẫn dắt, không quá chính thức).

  4. Peer Desk Check (1 người review).

  5. Ad Hoc Review (tự phát, trao đổi nhanh giữa đồng nghiệp).

Quy tắc: Deliverable càng quan trọng → càng cần review formal (ví dụ: SRS, design, critical code). Deliverable ít rủi ro → review informal.

4. Inspection (quan trọng nhất)

  • Quy trình 7 bước: Planning → Overview → Preparation → Meeting → Rework → Follow-up → Analysis.

  • Vai trò:

    • Moderator: điều phối

    • Reader: đọc tài liệu/code

    • Recorder: ghi lỗi

    • Inspector: tìm lỗi

    • Author: người viết sản phẩm

  • Nguyên tắc:

    • Author không kiêm vai trò khác.

    • Nhóm nhỏ (3–7 người).

    • Họp ≤ 2h, tốc độ hợp lý (150–200 SLOC/h).

    • Mục tiêu: tìm lỗi, không giải quyết lỗi trong meeting.

5. Review Specification

High-level review

  • Phát hiện vấn đề lớn: thiếu sót, mâu thuẫn, không đáp ứng user needs.

  • Kỹ thuật: đứng ở góc nhìn user, tham chiếu chuẩn mực/tiêu chuẩn, so sánh với phần mềm tương tự.

Low-level review

  • Một specification tốt cần:

    • Đầy đủ, Chính xác, Rõ ràng, Nhất quán, Liên quan, Khả thi, Không chứa code, Testable.

  • Từ ngữ dễ gây lỗi: “always, never, some, usually, clearly, obviously…”

6. Review Code

Code Review

  • Mục tiêu: tìm lỗi sớm, tăng testability, giúp tester hiểu app.

  • Cách tiếp cận: Static white-box testing (Inspection cho core code, Walkthrough/Desk check cho code thường).

  • Cần tuân theo standards & guidelines, sử dụng checklist để review code.

7. Nguồn tiêu chuẩn

  • ANSI, ISO, IEC, NCITS

  • Tổ chức nghề nghiệp: ACM, IEEE

  • Vendor standards

  • Lưu ý: mỗi dự án/ngôn ngữ có chuẩn riêng → cần chọn phù hợp và cập nhật sau mỗi dự án.

8. Kết luận

  • Review là phương pháp mạnh để tìm lỗi trước khi chạy phần mềm, tiết kiệm chi phí và nâng chất lượng.

  • Peer Review là phổ biến, trong đó Inspection là formal nhất cho deliverables quan trọng.

  • Specification và code cần được review ở cả cấp cao & chi tiết, dựa trên checklist, chuẩn mực và thực tế.

Tin khác: