Static Testing Là Gì? Kỹ Thuật Kiểm Thử Tĩnh Trong ISTQB
5 tháng trước · 11 phút đọc
Static testing là gì và tại sao tester mới hay bỏ qua?
Mình nhớ hồi mới vào nghề, mỗi khi nghe "testing" là mình nghĩ ngay đến việc mở app lên, bấm vào từng nút, rồi xem có lỗi không. Đó là dynamic testing - kiểm thử động - tức là phải chạy phần mềm mới test được.
Static testing thì ngược lại hoàn toàn. Bạn kiểm tra tài liệu, code, hoặc bất kỳ work product nào mà không cần chạy phần mềm. Nghe có vẻ đơn giản, nhưng đây là kỹ thuật được ISTQB đưa vào chương trình học chính thức vì lý do rõ ràng: lỗi tìm được sớm, chi phí fix thấp hơn nhiều.
Phát hiện lỗi ở tài liệu rẻ hơn fix bug production gấp nhiều lần
Hãy nghĩ thế này: bạn đang build tính năng đăng nhập. Developer code xong, bạn mới test, phát hiện requirement viết sai - hệ thống không xử lý email hoa/thường đúng cách. Lúc này dev phải sửa code, bạn test lại, có thể phát sinh bug mới. Mất cả ngày.
Nếu static testing được thực hiện từ đầu - review requirement trước khi dev code - lỗi đó bị bắt trong 10 phút đọc tài liệu. Đó là lý do tại sao ISTQB nhấn mạnh static testing là một phần không thể thiếu trong quy trình kiểm thử.
Các loại kỹ thuật static testing trong ISTQB
Static testing không chỉ là "đọc tài liệu rồi nhận xét". ISTQB phân loại cụ thể thành các kỹ thuật có quy trình rõ ràng.
Mỗi kỹ thuật phù hợp với một loại work product khác nhau
Review (Rà soát tài liệu)
Đây là kỹ thuật phổ biến nhất trong static testing. Bạn đọc và kiểm tra các tài liệu như requirement, test plan, user story, design document. ISTQB chia review thành 4 loại chính:
Informal review - Rà soát không chính thức: không cần quy trình cứng nhắc. Ví dụ: bạn nhờ đồng nghiệp đọc qua test case của mình, xem có bước nào bị thiếu không. Nhanh, linh hoạt.
Walkthrough - Người viết tài liệu tự trình bày cho nhóm nghe, mọi người đặt câu hỏi và góp ý. Thường dùng với requirement hoặc design doc.
Technical review - Nhóm kỹ thuật (dev, tester, BA) cùng kiểm tra document theo tiêu chí xác định. Có chuẩn bị trước, có biên bản.
Inspection - Kỹ càng nhất. Có checklist, có moderator chủ trì, có entry/exit criteria rõ ràng. Mình sẽ nói kỹ hơn ở phần sau.
Static analysis (Phân tích tĩnh code)
Kỹ thuật này kiểm tra code mà không chạy nó. Thường dùng tool tự động như SonarQube, ESLint, Checkstyle để tìm:
- Code không theo chuẩn (coding standard)
- Biến khai báo nhưng không dùng
- Logic có thể gây lỗi (null pointer, chia cho 0)
- Bảo mật: SQL injection, XSS tiềm ẩn
Với tester mới, bạn không cần tự chạy static analysis. Nhưng cần biết nó tồn tại và đôi khi dev sẽ yêu cầu bạn review kết quả tool báo cáo.
Quy trình inspection - kỹ thuật review kỹ nhất
Bao nhiêu lần bạn review tài liệu xong nhưng vẫn bỏ sót lỗi nghiêm trọng? Thường là do review không có cấu trúc. Inspection giải quyết vấn đề đó.
ISQTB định nghĩa inspection có 6 bước rõ ràng. Mình sẽ giải thích theo kiểu thực tế, không theo sách:
6 bước inspection - mỗi bước đều có vai trò cụ thể, không bỏ được
Bước 1: Planning (Lên kế hoạch) Xác định tài liệu nào cần inspect, ai tham gia, bao giờ họp. Quan trọng: phải có entry criteria - tài liệu đã đủ điều kiện để review chưa? Nếu requirement còn đang viết dở, đừng inspect vì mất thời gian.
Bước 2: Kick-off (Khởi động) Phân chia tài liệu cho từng người, giải thích mục tiêu review. Mỗi người nhận phần riêng để chuẩn bị.
Bước 3: Individual preparation (Chuẩn bị cá nhân) Mỗi người tự đọc phần được giao, ghi lại defect và câu hỏi theo checklist. Bước này quan trọng - nếu ai đến họp mà chưa đọc, buổi inspection sẽ loạn.
Bước 4: Review meeting (Họp review) Trình bày defect tìm được, thảo luận, ghi nhận. Moderator điều phối. Không tranh luận dài ở đây - chỉ ghi nhận, fix sau.
Bước 5: Rework (Chỉnh sửa) Tác giả tài liệu sửa lại các defect được ghi nhận.
Bước 6: Follow-up (Kiểm tra lại) Moderator verify rằng tất cả defect đã được xử lý. Nếu đạt exit criteria, inspection kết thúc.
Nhìn 6 bước có vẻ nhiều, nhưng thực tế trong team nhỏ, bước 1-2 thường gộp lại, bước 5-6 cũng vậy. Quan trọng là có checklist và có người chịu trách nhiệm theo dõi.
Static testing áp dụng thực tế cho tester mới
Lý thuyết rõ rồi. Câu hỏi thực tế: bạn - tester mới - áp dụng static testing vào công việc hàng ngày như thế nào?
Thật ra bạn không cần chờ team tổ chức inspection chính thức. Static testing có thể bắt đầu từ những việc rất nhỏ.
Ba work product tester mới review được ngay từ ngày đầu đi làm
Review requirement/user story
Mỗi khi nhận user story hoặc requirement mới, trước khi viết test case, hãy đọc kỹ và tự hỏi:
- Yêu cầu này có rõ ràng không? Có thể hiểu theo 2 nghĩa không?
- Thiếu thông tin gì? Ví dụ: "hệ thống gửi email thông báo" - gửi khi nào? Nội dung email là gì?
- Có mâu thuẫn với requirement khác không?
- Edge case nào chưa được đề cập?
Viết những câu hỏi này ra, trao đổi với BA hoặc PO. Đây chính là informal review - đơn giản nhưng hiệu quả.
Review test plan và test case
Nếu team có test plan, đọc kỹ trước khi bắt đầu test. Kiểm tra:
- Scope có cover đủ tính năng cần test không?
- Resource và timeline có hợp lý không?
- Risk đã được liệt kê chưa?
Với test case của chính mình hoặc đồng nghiệp: nhờ ai đó cross-review. Hai người đọc một test case tìm ra nhiều gap hơn một người đọc một mình.
Checklist đơn giản để bắt đầu
Bạn không cần tool phức tạp. Một checklist đơn giản trên Google Docs hoặc Notion là đủ:
| Tiêu chí | Câu hỏi kiểm tra |
|---|---|
| Rõ ràng | Yêu cầu có một nghĩa duy nhất không? |
| Đầy đủ | Không thiếu thông tin gì? |
| Nhất quán | Không mâu thuẫn với tài liệu khác? |
| Khả thi | Có thể implement và test được không? |
| Có thể kiểm chứng | Có tiêu chí accept rõ ràng không? |
Mình đã tổng hợp checklist này thành file để bạn tải về và dùng ngay: Tải checklist static testing
Lợi ích và giới hạn của static testing
Static testing không phải thuốc tiên. Mình thấy nhiều bạn mới học xong lý thuyết rồi nghĩ "review kỹ requirement là đủ, khỏi cần test nhiều". Sai.
Static và dynamic testing bổ trợ nhau - không thay thế được
Lợi ích rõ ràng:
Phát hiện lỗi sớm là lợi ích lớn nhất. Theo các nghiên cứu về software engineering, chi phí fix lỗi tăng theo cấp số nhân qua từng giai đoạn phát triển. Lỗi trong requirement nếu bị bắt ở giai đoạn review chỉ mất vài phút fix. Lỗi tương tự nếu lọt đến production có thể mất vài ngày và ảnh hưởng đến user thật.
Static testing cũng giúp cải thiện chất lượng tài liệu về lâu dài. Khi team quen review requirement kỹ, BA và PO tự nhiên sẽ viết rõ ràng hơn vì biết sẽ bị hỏi.
Một lợi ích ít ai nhắc: tester hiểu sâu hơn về system. Đọc kỹ requirement và design trước khi test giúp bạn viết test case chính xác hơn, không bỏ sót edge case.
Giới hạn cần thừa nhận:
Static testing không thể tìm được runtime error - lỗi chỉ xảy ra khi chạy phần mềm trong điều kiện thực tế. Ví dụ: memory leak, race condition, performance issue dưới tải cao. Những lỗi này bắt buộc phải dùng dynamic testing.
Static analysis tool cũng báo false positive - tức là tool cảnh báo lỗi nhưng thực ra không phải lỗi. Developer hoặc tester phải lọc thủ công, tốn thêm thời gian.
Cuối cùng: hiệu quả của review phụ thuộc rất nhiều vào kỹ năng và kinh nghiệm của người review. Tester mới sẽ tìm được ít lỗi hơn senior - điều này bình thường. Kỹ năng review cải thiện dần theo thời gian và thực hành.
Tóm tắt và bước tiếp theo cho tester mới
Static testing không phải khái niệm khó. Khó là hình thành thói quen - mỗi khi nhận tài liệu mới, dừng lại 10-15 phút để đọc kỹ trước khi bắt tay vào viết test case.
Thói quen nhỏ này tích lũy thành kỹ năng lớn theo thời gian
Những gì bạn đã biết sau bài này:
- Static testing = kiểm tra work product mà không chạy phần mềm
- Hai nhóm chính: review (tài liệu) và static analysis (code)
- Review có 4 loại: informal, walkthrough, technical review, inspection
- Inspection là kỹ càng nhất, gồm 6 bước có quy trình
- Tester mới có thể bắt đầu ngay với informal review requirement và cross-review test case
Bước tiếp theo mình gợi ý:
- Lần tới khi nhận user story, dùng 5 tiêu chí trong checklist (rõ ràng, đầy đủ, nhất quán, khả thi, có thể kiểm chứng) để tự review trước
- Nhờ đồng nghiệp cross-review 1 test case của bạn trong tuần này
- Tìm hiểu về ISTQB Foundation Level nếu bạn muốn học có hệ thống hơn - static testing chiếm một phần đáng kể trong syllabus
Nếu bạn đang học testing từ đầu và chưa rõ mình đang ở giai đoạn nào, có thể tham khảo Kiến Thức Nhập Môn IT - F8 để hình dung lộ trình tổng thể của ngành IT trước khi đi sâu vào một chuyên ngành cụ thể.
Thấy khó ở bước nào cứ comment bên dưới. Mình đọc hết và trả lời từng bạn. Static testing tưởng lý thuyết nhưng thực ra là kỹ năng bạn dùng mỗi ngày - chỉ là trước đây bạn làm mà không biết tên của nó thôi.