STATIC TESTING – KIỂM THỬ TĨNH

1 . Kỹ thuật tĩnh và quy trình kiểm thử.

Có 2 khuynh hướng có thể được dùng để đạt được các mục tiêu kiểm thử, đó là kiểm thử tĩnh (static testing) và kiểm thử động (dynamic testing)

Kiểm thử động (Dynamic testing): Là kiểm thử có tiến hành chạy phần mềm, thực hiện các bước để kiểm thử xem các chức năng đã thực hiện có chạy đúng với kết quả mong đợi hay không.

Kiểm thử tĩnh (Static testing): Kiểm thử một thành phần hoặc hệ thống ở mức độ đặc tả hoặc thực nghiệm mà không chạy phần mềm, ví dụ: nhận xét hoặc phân tích Code tĩnh.

Hoạt động Review: là hoạt động đánh giá một sản phẩm hoặc trạng thái của dự án để xác định sản phẩm hoặc dự án có tiến hành theo đúng kế hoạch không, có sai sót hoặc chênh lệch gì so với kế hoạch đề ra hay không và từ đó đề xuất những giải pháp cải tiến. Có những loại hoạt động Review như sau: Management Review, Informal Review, Technical Review, Inspection, và Walkthrough.

Giữa những câu hỏi đặt ra: Chúng ta có thể đánh giá hoặc phân tích một tài liệu yêu cầu, một tài liệu thiết kế, một test plan hoặc một tài liệu hướng dẫn sử dụng như thế nào? Chúng ta có thể đánh giá tính hiệu quả của những đoạn Code mà không cần chạy chương trình lên như thế nào?…Một kỹ thuật hùng mạnh mà chúng ta có thể dùng là kiểm thử tĩnh. Theo nguyên tắc tất cả các phần mềm đều có thể được kiểm thử bằng cách dùng kỹ thuật Review.

Những loại lỗi có thể dễ dàng được tìm thấy trong quá trình kiểm thử tĩnh là: sự sai lệch so với tiêu chuẩn, sai lệch hoặc thiếu sót trong bản đặc tả yêu cầu, lỗi thiết kế, những đoạn code khó bảo trì và lỗi thiếu nhất quán khi đặc tả giao diện.

Tóm lại, sử dụng kỹ thuật kiểm thử tĩnh, ví dụ như Review, sẽ có nhiều thuận lợi sau đây:

Bởi vì kiểm thử tĩnh có thể bắt đầu sớm trong quy trình phát triển phần mềm, do đó sẽ có được những phản hồi sớm về vấn đề chất lượng của phần mềm cũng như dự án.
Phát hiện các lỗi ở giai đoạn đầu, chi phí làm việc lại thường là tương đối thấp và như vậy một cải tiến tương đối rẻ của chất lượng sản phẩm phần mềm có thể đạt được.
Do những hành động làm lại được giảm đáng kể, hiệu suất phát triển phần mềm sẽ được gia tăng.
Kiểm thử tĩnh góp phần gia tăng nhận thức về các vấn đề chất lượng.

2. Tiến trình Review

2.1 Những giai đoạn của một buổi Review chính thức

Những giai đoạn của một buổi Review chính thức bao gồm:

Lập kế hoạch (Planning)
Bắt đầu (Kick-off)
Giai đoạn chuẩn bị cá nhân (Preparation)
Giai đoạn họp chính thức (Review meeting)
Giai đoạn làm lại (Rework)
Giai đoạn theo sát (Follow-up)

Giai đoạn lập kế hoạch (Planning): bao gồm việc lựa chọn nhân sự, phân bổ vai trò; xác định tiêu chí đầu vào và tiêu chí đầu ra cho buổi Review; và lựa chọn những phần nào của tài liệu sẽ được xem xét. Để gia tăng hiệu quả của một buổi Review, những vai trò khác nhau nên được phân bổ cho những người tham dự.

Giai đoạn bắt đầu (Kick-off): Phân phối tài liệu, giải thích các mục tiêu, quy trình, giải thích tài liệu cho những người tham gia để họ có những hình dung về dự án và kiểm tra xem những tiêu chí đầu vào đã đáp ứng đủ chưa.

Giai đoạn chuẩn bị cá nhân (Individual preparation): Ở giai đoạn này, mỗi cá nhân sẽ tự chuẩn bị nhiều thứ trước khi bước vào cuộc họp chính thức (ví dụ: đọc kỹ trước những tài liệu của dự án, ghi chú lại những điểm còn mơ hồ, đặt sẵn những câu hỏi để làm rõ vấn đề, ghi lại những lỗi đã phát hiện trong tài liệu,…). Nếu mỗi cá nhân đều thực hiện tốt nhiệm vụ của mình ở giai đoạn này, cuộc họp sau đó sẽ được tiến hành nhanh chóng, thuận lợi hơn và hiệu quả hơn.

Giai đoạn họp chính thức (Review meeting): Các thành viên trong dự án sẽ tham dự cuộc họp, đưa ra những câu hỏi để làm rõ vấn đề, trình bày những lỗi sai hoặc những vấn đề chưa có hướng giải quyết trong tài liệu và đề xuất những phương án hợp lý để cải thiện. Những thành viên tham gia sẽ trình bày, phản biện, tranh luận, kiến nghị,… nhằm mục đích đưa dự án hoạt động đúng hướng, theo đúng mong đợi của khách hàng.

Giai đoạn làm lại (Rework): Ở giai đoạn này, người viết tài liệu đặc tả phần mềm (SRS), người viết tài liệu thiết kế giao diện, thiết kế kiến trúc,.. sẽ tiến hành sửa chữa hoặc cải thiện những vấn đề đã được trình bày trong cuộc họp để cho những phiên bản tài liệu sau được tốt hơn.

Giai đoạn theo sát (Follow-up): ở giai đoạn này, những người có trách nhiệm sẽ kiểm tra xem những yêu cầu thay đổi đã được các tác giả của tài liệu cải thiện hay chưa, thu thập các số liệu tiến độ công việc và kiểm tra xem các tiêu chí đầu ra đã đáp ứng hay chưa.

2.2 Vai trò và trách nhiệm

Một buổi Review chính thức thường bao gồm những vai trò như sau:

Quản lý (Manager): quyết định thực hiện đánh giá, phân bổ thời gian trong lịch trình dự án và xác định xem các mục tiêu đánh giá đã được đáp ứng chưa.

Người điều hành (Moderator): là người dẫn dắt buổi nhận xét tài liệu hoặc bộ tài liệu, bao gồm việc lập kế hoạch cuộc họp, điều hành cuộc họp và theo dõi sau cuộc họp. Nếu cần thiết, người điều hành có thể làm người trung gian hòa giải giữa những quan điểm khác nhau của những người tham dự cuộc họp và người điều hành cũng là người đảm bảo sự thành công của buổi họp đó.

Tác giả tài liệu (Author): là người viết hoặc người có trách nhiệm chính đối với các tài liệu cần được xem xét trong cuộc họp.

Người đánh giá (Reviewers): các cá nhân có nền tảng kỹ thuật hoặc nghiệp vụ cụ thể (còn được gọi là người kiểm tra hoặc thanh tra). Sau khi chuẩn bị cần thiết, xác định và mô tả các vấn đề đã phát hiện trong các tài liệu đặc tả được xem xét, những người đánh giá sẽ tham dự cuộc họp chính thức và trình bày những quan điểm khác nhau của mình nhằm mục đích đưa dự án tiến hành theo đúng hướng và sản phẩm làm ra sẽ đáp ứng được những mong đợi của khách hàng.

Thư ký cuộc họp (Scrible): là người sẽ ghi nhận lại các vấn đề, các ý kiến, các quan điểm khác nhau đã được đóng góp trong cuộc họp. Thư ký cuộc họp cũng cần phải hiểu các nghiệp vụ phần mềm để ghi chép theo ngôn ngữ phù hợp với chuyên ngành, tránh hiểu sai vấn đề.

2.3 Các loại Review

Walkthrough: Một buổi walkthrough là một buổi họp mà ở đó tác giả của các tài liệu đặc tả phần mềm giới thiệu sơ lược về dự án phần mềm sẽ làm để cho những người tham dự có một sự hiểu biết chung về phần mềm đó, đồng thời thu thập những ý kiến phản hồi từ họ.

Technical review: là một cuộc họp ngang hàng mà ở đó những người tham dự là những người cùng nhóm kỹ thuật với nhau, ví dụ Developer Team, Tester Team. Cuộc họp này được các nhóm tổ chức để quyết định những công nghệ sẽ sử dụng để lập trình hoặc kiểm thử (ví dụ: dùng Java, C#, Ruby,… dùng kỹ thuật kiểm thử hộp đen, hộp trắng, kiểm thử theo Test Cases, kiểm thử tự do,…) và đề xuất những thuật toán sẽ sử dụng, những giải pháp thay thế khi tiến hành phát triển phần mềm.

Inspection: Là cuộc họp mà ở đó các thành viên trong dự án sẽ tham dự cuộc họp, đưa ra những câu hỏi để làm rõ vấn đề, trình bày những lỗi sai hoặc những vấn đề chưa có hướng giải quyết trong tài liệu và đề xuất những phương án hợp lý để cải thiện. Những thành viên tham gia sẽ trình bày, phản biện, tranh luận, kiến nghị,… nhằm mục đích đưa dự án hoạt động đúng hướng, theo đúng mong đợi của khách hàng.

Mục tiêu của buổi Inspection bao gồm:

Giúp tác giả nâng cao chất lượng tài liệu đang được kiểm tra
Loại bỏ các lỗi một cách hiệu quả, càng sớm càng tốt
Cải thiện chất lượng sản phẩm phần mềm ngay từ giai đoạn sớm trong quá trình phát triển.
Tạo sự hiểu biết chung và đúng đắn về phần mềm thông quá việc trao đổi thông tin giữa những người tham dự.
Đào tạo nhân viên mới trong quá trình phát triển của tổ chức. Thông qua những buổi inspection như thế này, các nhân viên mới sẽ học hỏi được rất nhiều về kinh nghiệm phát triển phần mềm từ các đàn anh đi trước.
Rút kinh nghiệm từ các lỗi tìm được và cải tiến quy trình để ngăn ngừa sự phát sinh của các lỗi tương tự trong tương lai.

2.4 Các yếu tố giúp một buổi Review thành công

Các yếu tố đảm bảo cho một buổi Review thành công bao gồm:

Mỗi buổi Review phải có một mục tiêu rõ ràng được xác định trước.
Những người tham dự buổi Review phải được lựa chọn phù hợp, đúng người đúng việc.
Các lỗi tìm thấy được hoan nghênh (khuyến khích các thành viên góp ý, chỉ ra những điểm chưa được làm rõ, đưa ra những ý tưởng cải tiến vấn đề, cải tiến tài liệu), và được thể hiện một cách khách quan.
Những vấn đề cá nhân và các khía cạnh tâm lý được giải quyết tích cực.
Các kỹ thuật review được áp dụng phù hợp với các loại, mức độ của các sản phẩm phần mềm và người review phần mềm.
Danh sách kiểm tra (checklists) hoặc các vai trò được sử dụng phù hợp sẽ gia tăng hiệu quả của việc xác định và cải tiến các vấn đề.
Vấn đề đào tạo nhân lực cần được quan tâm để mang lại hiệu quả kiểm tra cũng như có tính kế thừa sau này.
Có sự nhấn mạnh về việc học tập và cải tiến quy trình.

Phước Phan – PLT Solutions