Tìm hiểu Static Techniques - Chương 3 Foundation Level Syllabus(ISTQB)

1. Static techniques and the Test Process

• Dynamic test yêu cầu phải chạy PM để test, còn Static test là kỹ thuật kiểm tra các tài liệu (review) và tự động phân tích cú pháp ( static analys) của code hoặc các tài liệu khác của dự án mà không cần chạy code.
• Hoạt động review thường làm thủ công, đôi khi được hỗ trợ bởi tool nhưng không nhiều. Phần lớn là review thủ công để kiểm tra các SP và đưa ra nhận xét về nó. Bất cứ SP cũng có thể review được: Requirement specitifications, design specification, code, TCs...
• Lợi ích của review là lỗi được cải thiện và sửa sớm, cải thiện được năng suất phát triển phần mềm, giảm được thời gian phát triển, giảm chỉ phí và thời gian test, nên sẽ giảm được chi phí toàn thời gian, ít lỗi hơn và giao tiếp được cải thiện.
• Review có thể tìm thiếu sót của Requirement, cái này khó tìm được trong dynamic test.
• Review, static analysis and dynamic testing có chung mục đích là xác định lỗi. CHúng bổ sung cho nhau, các kỹ thuật khác nhau sẽ tìm được các lỗi khác nhau. So sánh với dynamic testing thì static test có thể tìm ra được nguyên nhân của lỗi hơn là chỉ tìm thấy các failures.
• Các lỗi điển thình dễ tìm ra trong review hơn trong dynamic test: lệch chuẩn, lỗi về yêu cầu, lỗi design, lỗi không đủ khả năng bảo trì, đặc tả giao diện không chính xác.

2. Review Process

2.1 Những hoạt động của một Formal Review

1. Planning

• Xác định tiêu chuẩn review
• Chọn nhận sự
• Phân bổ vai trò cho từng người
• Xác định tiêu chuẩn đầu ra và đầu vào cho các loại formal review( vd: inspections)
• Chọn các phần của document để review
• Kiểm tra tiêu chuẩn đầu vào

2. Kick - off

• Distributing tài liệu
• Giải thích mục tiêu, quy trình và tài liệu cho người tham gia dự án

3. Individual preparation

• Chuẩn bị cho meeting review bằng việc xem lại document
• Ghi chú lại các defect tiềm năng, câu hỏi và comment

4. Review meeting

• Thảo luận và log với kết quả được ghi lại
• Note lại các defect, đưa ra các cách giải quyết cho các defects đó
• Đánh giá và record lại các issues trong buổi họp

5. Rework

• Fix các defect được tìm thấy
• Update trạng thái của các defect

6. Follow - up

• Kiểm tra các defect đã được loại bỏ chưa
• Thu thập các thông số
• Kiểm tra tiêu chuẩn đầu ra

2.2 Role and Responsibilitis

Các vai trò tham gia vào review:

• Manager: Lãnh đạo quyết định thực hiện review, lên kế hoạch thời gian thực hiện trong KH dự án, xác định xem mục tiêu review có phù hợp không.
• Moderator: Người điều phối là người lãnh đạo cho 1 phiên review, thực hiện các task: lên kế hoạch, thực hiện họp, follow sau khi họp. Nếu cần Moderator có thể đứng ra phân giải khi có nhiều ý kiến khác nhau và quyết định thành công của buổi review.
• Author: Tác giả là người viết tài liệu và có trách nhiệm chỉnh sửa các lỗi tìm được
• Reviewers: Người review là các cá nhân có kiến thức về kỹ thuật hoặc nghiệp vụ, tham gia vào chuẩn bị, xác định và mô tả lỗi. Reviewer nên được chọn đại diện cho các quan điểm khác nhau và vai trò trong quá trình xem xét
• Scribe (hay recorder): Người ghi chép lại tất cả các issues, vấn đề, điểm mở trong quá trình họp. Việc sử dụng checklist hoặc xem các sản phẩm có liên quan giúp review hiệu quả hơn, phát hiện nhiều lỗi hơn.

2.3 Types of Review

Mỗi sản phẩm đều có thể áp dụng nhiều phương pháp review khác nhau và sẽ mang lại nhiều ý nghĩ hơn. Dưới đây là một số Type của Review: Informal Review

• Không có quy trình chính thức
• Có thể mang hình thức lập trình hoặc một chỉ dẫn kỹ thuật xem xét thiết kế và mã code
• Kết quả có thể được ghi chép lại
• Thay đổi tính sử dụng tùy thuộc vào người review
• Mục đích chính: đây là cách ko tốn kém để có nhiều lợi ích

Walkthrough

• Buổi meeting được Led bởi Author
• Có thể dưới dạng scenarios, dry runs, peer group participation
• Mở - Kết thúc sessions

• Sự chuẩn bị trước buổi họp của các reviewer
• Sự chuẩn bị của một báo cáo review bao gồm dách sách các phát hiện

• Tùy chọn scribe ( không là author)
• Có thể thay đổi trong thực tế từ informal đến formal
• Mục đích chính: Học hỏi, có được sự hiểu biết, tìm defects

Technical Review

• Ghi chép, xác định quy trình phát hiện defect, bao gồm các peers đồng nghiệp và chuyên gia kỹ thuật với bên management
• Có thể được thực hiện bởi Peer review ma không phải management
• Được led bởi trained moderator ( không phải author)
• Chuẩn bị trước buổi meeting bởi reviewers
• Sử dụng checklist
• Chuẩn bị một Review Report bao gồm: danh sách các phát hiện defect, cách giải quyết...
• Mục đích chính: thảo luận, đưa ra quyết định, đánh giá sự thay thế, tìm defect, giải quyết vấn đề kỹ thuật và kiểm tra sự phù hợp của spec, plan, regulation và standards

Inspection

• Được led bở trained moderator ( không phải author)
• Thường được tiến hành như một peer examination
• Xác định các roles cho từng ngừời
• Quy trình Formal dựa vào rule và checklist
• Xác định các tiêu chuẩn đầu vào và ra cho chaaso nhận của sản phẩm phần mềm
• Sự chuẩn bị trước cuộc meeting
• Báo cáo kiểm tra bao gồm danh sách của các phát hiện defect,..
• Quy trình follow- up chính thống
• Optional reader
• Mục đích chính: tìm kiếm defects

2.4 Success factors for reviews - Các nhân tố thành công cho review:

• Mỗi cuộc review phải được định nghĩa mục đích rõ ràng
• Mời đúng những người cần tham gia vào review
• Tester là người rất có giá trị khi tham gia vào review
• Welcome các lỗi được tìm thấy
• Vấn đề rắc rối về còn người và khía cạnh tâm lý cần được giải quyết
• Review được thực hiện trong bầu không khí tin tưởng, kết quả của nó không được dùng để đánh giá - những người tham gia.
• Các kỹ thuật review được dung phù hợp để đạt được mục đích
• Checklist hoặc vai trò được sử dụng nếu phù hợp sẽ tăng hiệu quả tìm ra lỗi
• Cần thực hiện đào tạo về kỹ thuật review đặc biệt là các kỹ thuật chính thống như inspection
• Sự hỗ trợ của lãnh đạo rất quan trọng để có quy trình review tốt (bố trí đủ thời gian cho hoạt động review trong dự án) Nhấn mạnh vào việc học và cải tiến quy trình

3. Static Analysis by tools

• Mục tiêu của static analysis là để tìm ra lỗi trong code và mô hình PM
• Static analysis được hiện bằng tool và không cần chạy code, chỉ ra các lỗi mà khó tìm được trong dynamic testing
• Giống nhw review , Static analysis tìm ra defects hơn là failures, dựa trên phân tích code (control flow, data flow)
• Giá trị của Static Analysis:
• Sớm phát hiện được defect trước khi chạy test
• Cảnh báo sớm về những khía cạnh đáng ngờ của code hoặc thiết kế bằng các tính toán số liệu, chẳng hạn như một độ đo sư phức tạp cao
• Xác định các defects không dễ dàng tìm được bởi dynamic testing
• Phát hiện phụ thuộc và không nhất quán trong các mô hình phần mềm như các links
• Cải thiện khả năng bảo trì của code và thiết kế
• Ngăn ngừa các defects, nếu những bài học được học trong phát triển Các loại lỗi điển hình được tìm thấy bởi Static Analysis:
• Tham chiếu tới một biến với một giá trị không xác định
• Giao tiếp không đồng nhất giữa các module và các thành phần
• Các biến mà không được sử dụng hoặc kê khai không đúng
• Đoạn code không chạy đến ( hay đã chết)
• Thiếu và logic sai lầm ( vòng có khả năng vô hạn)
• Cấu trúc quá phức tạp
• Tiêu chuẩn lập trình vi phạm
• Lỗ hổng bảo mật
• Vi phạm cú pháp của mã và mô hình phần mềm

Static Analysis tool thường được sử dụng bởi developer trước hoặc trong khi test component và test integration hoặc khi kiểm tra trong code với tool quản lý cấu hình, và bởi Designer trong mô hình hóa phần mềm.

Trình biên dịch có thể được coi là Static Analysis tool gồm cả việc đo đạc thông số. Bài viết được tham khảo tại:" http://www.istqb.org/downloads/send/2-foundation-level-documents/3-foundation-level-syllabus-2011.html4"