STATIC TESTING - KIỂM THỬ TĨNH (PHẦN 2)

Ở phần 1 mình đã nói về quy trình review work product, trong phần 2 này mình sẽ nói về các loại review và các kĩ thuật review

5. Vai trò và trách nhiệm trong review tiêu chuẩn

• Author:
  • Tạo ra các sản phẩm để review
  • Fix các defect của work product phát hiện được trong quá trình review (nếu cần thiết)
• Manager:
  • Có trách nhiệm lên kế hoạch review
  • Quyết định việc thực hiện review
  • Phân công người tham dự, chi phí và thời gian cho việc review
  • Giám sát những chi phí phát sinh
  • Thực hiện các quyết định trong trường hợp đầu ra không thỏa đáng
• Facilitator (hay còn gọi là moderator)
  • Đảm bảo hiệu quả của buổi review (khi được tổ chức)
  • Là người trung gian, nếu cần thiết giữa các bên khi họ có các viewpoint khác nhau
  • Thường là người quyết định sự thành công của một buổi review
• Review leader
  • Đảm nhận vai trò tổng thể của cuộc review
  • Quyết định những ai sẽ tham gia vào buổi review và đưa ra quyết định địa điểm, thời gian cho buổi review này
• Reviewer
  • Có thể là chuyên gia về một vấn đề nào đó trong work product cần review, hoặc những người trong cùng dự án, những bên liên quan quan tâm đến work product cần review hoặc những cá nhân có nền tảng kĩ thuật hoặc nghiệp vụ cụ thể liên quan đến work product cần review
  • Xác định những defect tiềm ẩn trong work product thông qua việc review
• Scribe ( hoặc recorder)
  • Đối chiếu/tham chiếu lại các lỗi tiềm ẩn được tìm ra trong hoạt động review cá nhân
  • Ghi chép lại các lỗi tiềm ẩn mới, các điểm mở, các quyết định trong buổi họp review

6. Các loại review

• Informal review (review không theo tiêu chuẩn):
  • Mục đích chính: phát hiện các defect tiềm ẩn
  • Mục đích bổ sung: Tạo ý tưởng mới hoặc giải pháp mới, nhanh chóng giải quyết các vấn đề nhỏ
  • Không dựa trên các quy trình tiêu chuẩn
  • Có thể không bao gồm buổi họp review
  • Có thể được thực hiện bởi đồng nghiệp/đồng sự của tác giả hoặc bởi nhiều người
  • Kết quả review có thể ghi chép lại hoặc không
  • Giá trị của buổi review phụ thuộc chủ yếu vào người review
  • Có thể sử dụng checklist hoặc không
  • Hay được sử dụng trong mô hình phát triển Agile
• Walkthrough
  • Mục đích chính: tìm defect, cải thiện sản phẩm phần mềm, xem xét triển khai thay thế, đánh giá sự phù hợp với tiêu chuẩn và thông số kĩ thuật
  • Trao đổi ý tưởng về kĩ thuật hoặc các phần cần thay đổi, đào tạo cho người tham gia, đạt cùng sự đồng thuận
  • Người chủ trì cuộc họp review là tác giả của work product được review
  • Vai trò Scribe là bắt buộc
  • Việc log và report lại các defect tiềm ẩn có thể có hoặc không
• Technical review
  • Mục đích: đạt được sự đồng thuận, xác định rủi ro tiềm ẩn
  • Mục đích có thể đạt được: đánh giá chất lượng và tạo niềm tin vào sản phẩm, tạo những ý tưởng mới, thúc đẩy và cho phép tác giả cải tiến những tính năng sản phẩm trong tương lai, xem xét cần thay thế với hiện tại hay không
  • Yêu cầu bắt buộc những người review cần chuẩn bị trước buổi họp review
  • Buổi họp review có thể không bắt buộc, lý tưởng nhất được tổ chức với 1 moderator
  • Scribe là bắt buộc
  • Cần log lại những defect được phát hiện và có báo cáo review
• Inspection
  • Mục đích chính: xác định defect tiềm ẩn, đánh giá chất lượng và tạo niềm tin vào sản phẩm, ngăn chặn những defect tương tự trong tương lai thông qua giúp tác giả phân tích được nguyên nhân gốc rễ.
  • Mục đích có thể đạt được: thúc đẩy và cho phép tác giả cải tiến những tính năng sản phẩm trong tương lai và quy trình phát triển, đạt được sự đồng thuận
  • Tuân theo một quy trình được định nghĩa sẵn với tài liệu đầu ra tiêu chuẩn, dựa trên quy tắc và checklist
  • Người review hoặc đồng sự với tác giả hoặc là expert về mảng liên quan đến sản phẩm được review
  • Các tiêu chí đầu vào đầu ra cần được sử dụng
  • Scribe là bắt buộc
  • Cần xây dựng báo cáo bug và report thông qua buổi review

7. Áp dụng các kĩ thuật vào review

• Adhoc:
  • Trong kĩ thuật review Adhoc, những người review được cung cấp rất ít hoặc không có bất kì hướng dẫn nào về việc sẽ phải thực hiện task đó
  • Người review thường xuyên phải đọc tài liệu một cách liên tục, xác định và ghi lại những vấn đề họ gặp phải/phát hiện được trong sản phẩm
  • Adhoc là kĩ thuật thông thường nhất được sử dụng khi có rất ít sự chuẩn bị
  • Kĩ thuật này phụ thuộc lớn vào kĩ năng người review và có thể gặp vấn đề rằng có 1 lượng lớn các issue bị report trùng lặp bởi các người review khác nhau.
• Checklist-based:
  • Kĩ thuật review checklist-based là một kĩ thuật review có phương pháp, tức là những người review sẽ xác định issue dựa trên checklist đã được phân bổ trong giai đoạn review initiation
  • Một checklist review bao gồm một tập các câu hỏi dựa trên defect tiềm tàng, thường xuất phát từ kinh nghiệm trước đó.
  • Checklist sẽ được cụ thể với từng loại work product được review và thường xuyên được maintain để cover các issue bị miss tại version trước.
  • Lợi ích chính của kĩ thuật checklist-based là khả năng coverage các loại defect điển hình 1 cách có hệ thống
• Scenarios và dry runs:
  • Trong scenario-based review, người review được cung cấp bản hướng dẫn làm cách nào để đọc hiểu work product
  • Hướng tiếp cận của scenario-based là hướng dẫn người review thực hiện "dry runs" work product dựa trên mong muốn sử dụng work product (nếu work product là tài liệu có format phù hợp ví dụ như use case)
  • Phương pháp này cung cấp cho người review hướng dẫn tốt hơn về làm cách nào xác định các loại defect dễ dàng hơn so với phương pháp check list
• Role-based:
  • Kĩ thuật này là người review đánh giá work product trên các quan điểm cá nhân của các bên liên quan trong dự án
  • Cụ thể các vai trò này có thể là end-user (có kinh nghiệm, không có kinh nghiệm) hoặc đóng các vai trò trong tổ chức như: user administrator, system administrator, performance tester
• Perspective-based:
  • Cũng tương tự như role-based, kĩ thuật này người review đứng trên góc nhìn của các bên liên quan khác nhau trong quá trình review. Các bên liên quan điển hình bao gồm: end user, marketing, designer, tester hoặc operation.. Việc sử dụng góc nhìn của các bên liên quan khác nhau có lợi ích là cái nhìn sâu hơn trong quá trình review cá nhân và cũng có tác dụng giảm bớt các issue trùng lặp
  • Dựa vào các nghiên cứu đánh giá, kĩ thuật Perspective-based là có hiệu quả nhất trong việc review các tài liệu work product của hệ thống bao gồm cả yêu cầu và kĩ thuật

8. Các nhân tố thành công cho review

• Nhân tố thành công về mặt tổ chức bao gồm:
  • Mỗi cuộc review phải được định nghĩa rõ ràng, đưa ra kế hoạch review, những người tham gia review và tiêu chí đo lường đầu ra để kết thúc quá trình review
  • Các loại review được áp dụng cần phù hợp để đạt được mục tiêu và phù hợp với sản phẩm phần mềm và những người tham gia review
  • Người tham dự cần có thời gian đầy đủ để chuẩn bị
  • Việc review được lập lịch với thông báo đầy đủ tới những người tham gia
• Nhân tố về con người liên quan đến việc review:
  • Mời đúng những người cần tham gia review để đạt được mục đích review cụ thể ví dụ như mời những người có kĩ năng hoặc có góc nhìn khác nhau
  • Tester là người rất có giá trị khi tham gia vào review và cũng để học luôn về work product, cái mà cần chuẩn bị tốt cho việc test hiệu quả và chuẩn bị cho việc test sớm
  • Buổi họp review cần được quản lý tốt để cho người tham dự thấy được giá trị của thời gian họ bỏ ra

Tài liệu tham khảo:

Giáo trình ISTQB Foundation 2018