Static testing là kiểm thử mà chúng ta không cần chạy phần mềm. Tester, developer, BA hoặc công cụ sẽ đọc và phân tích requirement, thiết kế, source code, test case… để tìm vấn đề càng sớm càng tốt.
Lưu ý
Điểm dễ nhầm: Static testing không đồng nghĩa với “tester ngồi đọc tài liệu”. Code review, review test case và công cụ phân tích source code đều thuộc static testing.
Static testing kiểm tra được những gì?
Gần như mọi work product có thể đọc và hiểu đều có thể được review:
- Requirement, acceptance criteria, user story và product backlog item.
- Thiết kế hệ thống, mô hình dữ liệu, đặc tả API và hợp đồng.
- Source code, test plan, test case, test charter và tài liệu dự án.
Ví dụ
Acceptance criteria ghi “mật khẩu phải dài 8–20 ký tự”, nhưng một đoạn khác lại ghi “tối thiểu 10 ký tự”. Tester phát hiện mâu thuẫn ngay trong refinement, trước khi developer viết code. Đây là static testing.
Hai cách thực hiện Static Testing
- Review thủ công: con người đọc requirement, thiết kế, code hoặc test case; đặt câu hỏi và ghi nhận sự bất thường
- Static analysis bằng công cụ: công cụ kiểm tra work product có cấu trúc, ví dụ source code hoặc mô hình có cú pháp xác định. SonarQube có thể phát hiện code trùng lặp, biến chưa dùng hoặc độ phức tạp cao.
Vì sao Static Testing có giá trị?
- Phát hiện sớm: sửa một requirement mơ hồ thường rẻ hơn sửa code rất nhiều
- Tìm được lỗi Dynamic Testing khó thấy: tìm được những issue mà code không bao giờ được chạy tới, thiết kế module kém hoặc test basis thiếu coverage.
- Tạo hiểu biết chung: BA, Dev, Tester và PO thống nhất mình đang xây gì trước khi triển khai.
- Đánh giá chất lượng: xem work product có đầy đủ, đúng, nhất quán, dễ hiểu, dễ test và dễ bảo trì hay không.
Static Testing khác Dynamic Testing thế nào?
| Tiêu chí | Static Testing | Dynamic Testing |
|---|---|---|
| Có chạy phần mềm? | Không | Có |
| Đối tượng | Requirement, acceptance criteria, user story… | Phần mềm |
| Cách tìm defect | Phát hiện defect trực tiếp khi review hoặc phân tích | Quan sát failure, sau đó phân tích để tìm defect liên quan |
| Thời gian diễn ra | Từ rất sớm | Muộn hơn nhiều |
| Ví dụ | Thấy acceptance criteria mâu thuẫn | Chạy thử và thấy hệ thống tính sai tiền |
Cảnh báo
Static và Dynamic Testing không thay thế nhau. Review có thể thấy đặc tả API khai báo sai kiểu tham số; tuy nhiên vẫn phải chạy test thật mới phát hiện ra hệ thống chậm khi 5.000 người dùng truy cập đồng thời.
Những bug mà Static Testing thường bắt tốt
- Requirement thiếu, mơ hồ, mâu thuẫn hoặc lặp lại.
- Thiết kế database kém hiệu quả, chia module chưa hợp lý.
- Biến chưa khai báo, code không thể chạy tới, code trùng hoặc quá phức tạp.
- Sai số lượng, kiểu hoặc thứ tự tham số trong interface specification. (đặc tả kỹ thuật)
- Test case chưa cover một số acceptance criteria.
Mẹo nhớ
Static = xem xét sản phẩm công việc khi nó đang “đứng yên”.
Dynamic = cho phần mềm “chạy” rồi quan sát hành vi.
Dynamic = cho phần mềm “chạy” rồi quan sát hành vi.
Kết luận
Static testing đưa hoạt động kiểm thử về sớm hơn trong SDLC. Thay vì đợi có build mới bắt đầu tìm lỗi, team có thể review requirement, thiết kế, code và testware ngay khi chúng xuất hiện. Kết hợp static và dynamic testing giúp phát hiện nhiều loại defect hơn với chi phí hợp lý hơn.
