Một số thuật ngữ - Chuyên ngành - Testing - kiểm thử phần mềm

Develop a technical review process (≤ 4 pages total) that the team will use during Session #6 (Technical Review of Code) , including any artifacts needed, roles played, metrics to be gathered and how the metrics will be analyzed. Be sure to describe and support why your team chose a specific level of formality.

              Một qui trình có 4 yếu tố quan trọng là People - Methods - Tools - Materials. Để chuẩn bị cho việc sắp sửa nhận code của chương trình JMedia từ thầy. Đội chúng tôi, sẽ áp dụng thử nghiệmInspection vào Technical Review of Code.

1.      Mục tiêu của quy trình đưa ra (Technical Review of Code): xác định những khiếm khuyết của đoạn code. Ngoài ra quy trình còn giúp cho nhóm làm dự án :

      Loại bỏ được các khiếm khuyết

      Đạo tạo thêm các kĩ thuật cho nhóm dự án thông quá qui trình này.

      Các thành viên học hỏi lẫn nhau trong buổi meeting

2.      Giá trị của quy trình mang lại:

      Lợi ích: sớm xác định được các lỗi sai của đoạn code. Nâng cao khả năng kĩ thuật của các thành viên trong đội. Tạo ra một tiêu chuẩn để kiểm tra.

      Để đảm bảo cho việc xác định này, các số liệu cần phải được xác nhận thông qua quy trình.

3.      Các bước của quy trình:

      Planning: Thiết lập được lịch trình. Lựa chọn người thanh tra để có thể đạt được mục tiêu của quy trình.

      Overview: cung cấp tài liệu,chủ đề cuộc họp và nói tổng quát về tài liệu.

      Preparation: mỗi cá nhân xem trước tài liệu.

      Meeting: Tìm và ghi nhận lại tất cả các lỗi sai của đoạn code.

      Rework: tất cả thành viên cũng làm lại đoạn code

      Follow up: Xác minh giải pháp cho tất cả các các vấn đề đã được tìm thấy trong suốt quá trình thanh tra, đồng thời xem xét lại để đi đến quyết định có làm lại cuộc thanh tra khác hay không.

Sơ đồ Swim lane tổng quan cho quy trình Technical Review của đội:

Bảng phân công vai trò cụ thể cho từng người:

Step	Participant	Objectives
Planning	Author Moderator	Quyết định mục tiêu của buổi kiểm tra, lên kế hoạch và lịch biểu, xác định các component của các dòng code cần kiểm tra, khi nào thực hiện và ở đâu, lên danh sách những ai sẽ tham gia kiểm tra tài liệu này và  đưa tài liệu cho các Inspector       Đây là tiêu chí cho Technical Reviews  và nó là việc đầu tiên cần làm trong buổi inspection review. Nếu thiếu những tiêu chí này, chúng ta không thể tiến hành bước tiếp theo. Mục tiêu của những việc trên là xác định mục tiêu, chọn team sẽ được review, đưa  ra dc schedule , chuẩn bị và đưa ra các tài liệu cho người inpestor)
Overview	Moderator	Moderator (người lên kế hoạch) sẽ chịu trách nhiệm cung cấp input entry cho cá thành viên tham gia. Giới thiệu sơ qua cho tất cả những người tham gia tài liệu sẽ được kiểm tra
Preparation	Inspectors	Mỗi một người Inspector tham gia vào quá trình kiểm tra thì sẽ đọc lại (đọc để hiểu, xem nói về cái gì) các tài liệu sẽ thực hiện kiểm tra. Là bước để chuẩn bị trước và có thể phát hiện trước một số khiếm khuyết và đưa nó ra bàn bạc trong các buổi họp.       Đây là việc cần làm, nó giúp xác đinh được các vấn đề sớm và hiệu quả, khi mà mổi người inpestor được tự do đánh giá thì họ sẽ kiểm tra để tìm lỗi trong sản phẩm, và họ sẽ ko bị ảnh hưởng bởi những người khác, phát hiện được nhiều khiếm khuyết hơn
Meeting	Author Moderator Inspectors Reader Recorder	Trong thời gian như định sẽ đi vào các task chính và tất cả ngồi lại với nhau. Tại buổi họp, người Moderator sẽ điều khiển cuộc họp. Người Reader sẽ đọc từng công đoạn cho các Inspector nghe và phân tích và khi phát hiện được lỗi sẽ ghi chép lại vào trong danh sách vấn đề. Người Reader sẽ ghi lại những lỗi đã được sữa. Người Recorder thì viết lại những câu trả lời cho các vấn để đó và những lỗi mới được tìm thấy cũng như biên bản cuộc họp. Cuối buổi meeting mổi người sẽ đưa ra biểu quyết cho việc giải quyết các lỗi..       Là bước quan trọng cần phải làm trog quy trình inspector review bởi vì trong bước này những vấn đề những lỗi sẽ được nêu ra và thảo luận cẩn thận, sau đó những vấn đề sẽ được tóm tắt và được làm lại ở bước tiếp theo . Thiếu bước này lổi sẽ không được nêu ra và không được thảo luận để tiềm cách loại bỏ nó và chúng ta có thể đạt được mục tiêu tìm thấy được các lỗi
Rework	Author	Sau các buổi họp, Author sẽ về sửa lại các defect dựa vào defect list.       Vì cần sửa lỗi đã được nêu trong buổi họp.
Follow-up	All	Theo dõi xem output  tài liệu đã sửa như thế nào (Moderator sẽ xem xét bản sửa chửa và đưa cho người author kiểm tra lại), có sinh ra defect mới hay không. Nếu có sẽ có thêm Qui trình kiểm tra mới. Khâu này do Moderator hay cả nhóm cùng tham gia. Đưa ra một Inspection Report       Bước này cần làm nhưng không cần chính thức lắm dựa trên mục tiêu và tình huống của inspection review

4.      Người có liên quan đến quy trình: Người tác giả(viết code), Người điều hành, người thanh tra, người ghi nhận, và những người đọc.

Author

      Là tác giả và là người viết ra các dòng (đoạn) Code, theo dõi các vấn đề được Inspector đưa ra, sửa tất cả defect theo defect list.

Moderator

      Là một trong số điều có vai trò cao trong Inspection Review, duy trì thảo luận và giải quyết các xung đột cùng các vấn đề phát sinh trong buổi meeting hoặc sau này.

      Xây dựng một kế hoạch Review cụ thể chi tiết (review tài liệu nào, thực hiện ở đâu, khi nào review...) và chịu mọi trách nhiệm cho lịch trình chi tiết cho một buổi review sẽ diễn ra.

      Có sự chuẩn bị cho quá trình Review

      Đảm bảo các công việc đi theo đúng lịch trình

      Tổng kết và nhìn nhận các vần đề đã xảy ra. Xem và feeback cho toàn bộ buổi review thông qua số liệu được đo lường cụ thể.

      Không được là người Author.

Recorder

      Là người viết những vấn đề trong thời gian meeting, đóng vai trò như một người thư kí trong một buổi họp.

      Ghi chép những vấn đề nào sẽ được chỉnh sửa, có bao nhiêu defect cần phải chỉnh sửa, có bao nhiêu ý kiến trong một defect,…

Inspector

      Chuẩn bị cho lần họp reviews sẽ được diễn ra

      Là những người đóng vai trò chính trong các buổi meeting reviews

      Kiểm tra các tài liệu để tìm ra khiếm khuyết và cung cấp feedback cho các đoạn code bị lỗi (hoặc các vấn đề lien quan trong buổi meeting)

      Ghi nhớ các kết quả code đã sửa trong component.

Reader

      Đọc tài liệu gồm những phần gì và trình bày chúng trong các buổi meeting, ghi chép các defect để cho ra một defect list  dùng để gửi cho Author

      Không phải là người Author

      Người điều hành: Nhựt.

      Người đọc: Luân.

      Người ghi nhận: Kim.

      Người thanh tra: Tuấn, Tín.

      Vai trò sẽ thay đổi trong mỗi lần thanh tra.

      Trước cuộc họp:

      Người điều hành: lên kế hoạch

      Người thanh tra: tóm tắt tài liệu.

      Người đọc, người ghi nhận: đọc trước tài liệu.

      Trong cuộc họp: tất cả thành viên.

      Người điều hành: xử lý xung đột.

      Người thanh tra: tìm lỗi đoạn code.

      Người ghi nhận: ghi nhận cụ thể những gì diễn ra trong cuộc họp (số lỗi sai, sai lỗi gì, sai dòng nào,...) bằng cách tô đỏ.

      Người đọc: kiểm soát cuộc họp.

      Sau cuộc họp : tất cả thành viên.

Người ghi chép: cung cấp tài liệu thu được trong cuộc họp.

Tất cả thành viên chỉnh sửa lại đoạn code. (Nếu làm bài tập JMedia hoặc các bài tập đồi hỏi các thành viên cùng làm nhiều công việc)

5.      Quy trình được thực hiện đúng lúc:

      Những bước thực hiện tuần tự ?

      Có hay không một vài bước thực thi mang tính phụ thuộc vào các task khác.

      Có những bước được thực thi song song không?

      Có một số thời gian đặc biệt mà liên quan đến quy trình không?

6.      Đầu vào và đầu ra của quy trình:

      Đầu vào (Input):

      Đoạn code bị lỗi (trong từng function, Class, component)

      Những chuẩn mà để đạt được

      Đầu ra (Output):

      Bảng liệt kê các khiếm khuyết.

      Inspection Report

      Code Inspection Log (do Inspector ghi lại trong quá trình meeting)

      Meeting Minus, Meeting Information (do Recorder ghi lại)

7.      Phân tích các Metrics

      Dựa vào số liệu recorder ghi chép lại và thống kê metrics:

-         Xác định vị trí và phân vùng được defect trong đoạn code. (Dòng thứ bao nhiêu xảy ra lỗi defect).

-         Đánh giá mức độ ưu tiên (nghiêm trọng) của các defect.

-         Phải phân loại được các loại defect xảy ra trọng đoạn code đó: Thuật toán, logic, document,…

-         Người nào đã tìm ra defect đó.

-         Defect đó xảy ra trong giai đoạn nào.

-         Thời gian trung bình mình tìm ra defect đó. Tổng thời gian để tìm ra tất cả các defect.

-         Tỉ lệ defect xảy ra trên tổng số dòng code được review.

-         Các vấn đề mình gặp phải trong quá trình review process thì phải document lại để lần sau biết được hướng giải quyết. Đưa ra một vài risk trong plan để khi gặp thì sẽ biết được hướng giải quyết.

8.      Điều cản trở tới sự thành công của quy trình:

      Các dữ liệu có khiếm khuyết được sử dụng một cách  không thích đáng.

      Sử dụng thanh tra dữ liệu để đo lường được tính hiệu quả, cải thiện việc thẩm định và đo lường

      Không sử dụng dữ liệu thanh tra để đánh giá lại hiệu suất làm việc.

      Độ chính xác không cao.

      Tránh thẩm định về lịch trình trong lúc công việc đang được thực thi

      Chưa được đào tạo.

      Thiếu tính cạnh tranh, động lực

      Thiếu sự tự động hóa.

      Sử dụng các công cụ để giúp cho việc thu thập dữ liệu.

      Thiếu sự tự động hóa.

      Các cuộc họp thanh tra được sử dụng cho việc giải quyết các vấn đề hoặc những thảo luận có liêm quan.

      Nên xác định được các vấn đề được đề cập tới.

      Những người tham gia vào trong cuộc họp đó thì tỏ ra thái độ không chuyên nghiệp khi đưa ra hoặc nhận một feedback.

Lời kết

              Formal Inspections  là một loại hình cụ thể của đánh giá kỹ thuật thực hiện một cách cực kỳ hiệu quả trong việc phát hiện các defect. Cần xem xét và áp dụng những cái hay của nó vào bài code JMedia sắp tới của đội. Để việc kiểm tra các lỗi code dễ dàng và triệt để hơn. Và đó cũng là quy trình mẫu mà đội đưa ra để sắp tới áp dụng thử nghiệm.