Câu hỏi: SWT301 - Phần 3: Kỹ thuật kiểm thử tĩnh và rà soát

Đáp án đúng: "Defects and issues are identified and corrected". Câu hỏi tìm quy tắc không nên tuân theo. Trong review, nhiệm vụ của buổi họp là phát hiện và ghi nhận khuyết tật, vấn đề chứ không sửa chúng ngay tại chỗ; việc sửa thuộc bước làm lại (rework) do tác giả thực hiện sau buổi họp, nếu vừa tìm vừa sửa thì cuộc họp sa vào bàn giải pháp và mất trọng tâm. Các phát biểu kia đều là quy tắc đúng nên không được chọn. "The product is reviewed not the producer" là nguyên tắc cốt lõi: đánh giá sản phẩm chứ không phán xét con người, giúp tác giả không phòng thủ. "All members of the reviewing team are responsible for the result of the review" đúng vì chất lượng review là trách nhiệm chung của cả nhóm chứ không riêng tác giả hay moderator. "Each review has a clear predefined objective" đúng vì mục tiêu rõ ràng định trước là một yếu tố thành công của review theo ISTQB.

Đáp án đúng: "Mediates between people". Người điều phối (moderator) dẫn dắt quy trình rà soát: lập kế hoạch, chủ trì cuộc họp, giữ thảo luận đúng hướng và làm trung gian hòa giải giữa các quan điểm khác nhau, đặc biệt giữa tác giả và người rà soát, để buổi họp tập trung vào lỗi trong tài liệu chứ không thành chỉ trích cá nhân. "Takes minutes of the meeting" là việc của người ghi chép (scribe), người lưu lại lỗi và vấn đề được nêu. "Writes the documents to be reviewed" là vai trò tác giả (author), người không nên làm điều phối trong rà soát hình thức để giữ khách quan. "Takes telephone calls" không phải vai trò nào trong rà soát; cuộc họp rà soát cần tập trung và không có ai được giao việc nghe điện thoại.

Đáp án đúng: "Technical Review". Theo ISTQB, rà soát kỹ thuật (technical review) là quá trình được ghi lại, tập trung đạt đồng thuận và tìm khiếm khuyết, có sự tham gia của đồng nghiệp và chuyên gia kỹ thuật, và có thể tiến hành như rà soát đồng cấp (peer review) không có quản lý tham gia; vì thế peer review thường được gọi đồng nghĩa với technical review. "Inspection" là thanh tra, loại rà soát chính thức nhất do người điều phối được đào tạo dẫn dắt, có vai trò định sẵn, tiêu chí vào ra và số đo; nó cũng có đồng nghiệp tham gia nhưng có tên gọi riêng. "Walkthrough" là duyệt qua do chính tác giả dẫn dắt nhằm chia sẻ hiểu biết, không phải tên khác của peer review. "Formal Review" là thuật ngữ chung chỉ mọi rà soát có quy trình chính thức, bao trùm nhiều loại chứ không trùng với peer review.

Đáp án đúng: "Management". Rà soát kỹ thuật (technical review) là buổi thảo luận giữa đồng nghiệp và chuyên gia kỹ thuật nhằm đạt đồng thuận về nội dung kỹ thuật và tìm khiếm khuyết; ISTQB mô tả nó có thể thực hiện như rà soát đồng cấp (peer review) không có sự tham gia của quản lý, vì sự có mặt của quản lý khiến người tham gia ngại nêu vấn đề và dễ biến buổi rà soát thành đánh giá con người. "Analysts" là người viết hoặc hiểu sâu yêu cầu, thường tham gia rà soát kỹ thuật tài liệu yêu cầu và thiết kế. "Developers" là đồng nghiệp kỹ thuật cốt lõi, rà soát mã và thiết kế của nhau. "Testers" tham gia để kiểm tra khả năng kiểm thử và phát hiện mâu thuẫn trong sản phẩm được rà soát, cũng là thành phần kỹ thuật bình thường.

Đáp án đúng: "Inexpensive way to get some benefit". Rà soát không chính thức (informal review) không có quy trình định sẵn, không bắt buộc ghi biên bản, có thể chỉ là một đồng nghiệp đọc lại tài liệu hoặc lập trình đôi; ISTQB nêu mục tiêu chính của nó là một cách rẻ để thu được một phần lợi ích của việc rà soát. "Find defects" là mục tiêu chính của thanh tra (inspection), loại rà soát hình thức nhất. "Learning, gaining understanding, effect finding" là mục tiêu của duyệt qua (walkthrough), nơi tác giả trình bày để mọi người học hỏi và hiểu tài liệu. "Discuss, make decisions, solve technical problems" là mục tiêu của rà soát kỹ thuật (technical review), nơi các chuyên gia thảo luận, đạt đồng thuận và chọn phương án kỹ thuật.

Đáp án đúng: "An inspection is led by a moderator and a walkthrough is led by the author.". Theo ISTQB, duyệt qua (walkthrough) do tác giả dẫn dắt, trình bày tài liệu cho đồng nghiệp để chia sẻ hiểu biết và nhận góp ý; thanh tra (inspection) là loại rà soát hình thức nhất, do người điều phối được đào tạo dẫn dắt, có chuẩn bị cá nhân, tiêu chí vào ra và theo dõi chính thức. "Both inspections and walkthroughs are led by the author." sai về phía thanh tra, vì tác giả không được làm người điều phối để giữ khách quan. "Both inspections and walkthroughs are led by a trained moderator." sai về phía duyệt qua, vốn do chính tác giả chủ trì. Phát biểu "The author is not present during inspections." sai vì tác giả vẫn có mặt trong thanh tra, chỉ không giữ vai trò dẫn dắt, và thường giải đáp câu hỏi, nhận danh sách lỗi để sửa.

Đáp án đúng: "Enforcement of coding standards.". Công cụ phân tích tĩnh (static analysis tool) đọc mã nguồn mà không chạy nó, đối chiếu với tập quy tắc để báo các vi phạm như đặt tên sai quy ước, hàm quá dài, độ phức tạp vòng cao, biến không dùng; kiểm tra tuân thủ chuẩn lập trình một cách tự động, đồng loạt trên toàn bộ mã là thế mạnh rõ nhất của loại công cụ này. "Supporting reviews." là việc của công cụ hỗ trợ rà soát (review tool) như lưu tài liệu, ghi nhận xét, quản lý cuộc họp; phân tích tĩnh có thể góp số liệu cho rà soát nhưng không phải công cụ chuyên cho việc đó. "Validating models of the software." là việc của công cụ mô hình hóa (modelling tool), kiểm tra tính nhất quán của mô hình như sơ đồ UML hay mô hình dữ liệu. "Testing code executed in a special test harness." là kiểm thử động: mã được chạy trong khung kiểm thử (test harness) có driver và stub, thuộc công cụ thực thi kiểm thử hoặc kiểm thử đơn vị.

Một walkthrough là một quá trình đánh giá kỹ lưỡng và chi tiết về một sản phẩm, dự án hoặc quy trình. Mục đích chính của walkthrough là giáo dục người tham gia và thu thập phản hồi. Quá trình này giúp người tham gia hiểu rõ hơn về sản phẩm, dự án hoặc quy trình, đồng thời có cơ hội đóng góp ý kiến và đề xuất cải thiện. Thông qua walkthrough, người tham gia có thể nhận được thông tin chi tiết về các tính năng, chức năng, và quy trình hoạt động của sản phẩm, dự án hoặc quy trình. Điều này giúp người tham gia có thể đưa ra ý kiến và đề xuất một cách có căn cứ và hiệu quả.

Static testing trong phát triển phần mềm giúp kiểm tra mã nguồn trước khi thực hiện các hoạt động khác. Nó giúp giảm thiểu các lỗi và cải thiện chất lượng phần mềm. Tuy nhiên, một trong những lợi ích không chính xác của static testing là cải thiện giao tiếp giữa các thành viên trong đội ngũ trong quá trình tham gia các đánh giá. Thực tế, static testing không trực tiếp cải thiện giao tiếp giữa các thành viên trong đội ngũ. Thay vào đó, nó giúp giảm thiểu các lỗi và cải thiện chất lượng phần mềm, từ đó giúp đội ngũ phát triển phần mềm làm việc hiệu quả hơn.

Trong một đánh giá chính thức, các vai trò sau đây thường được tham gia: - Nhà phát triển (Developer): chịu trách nhiệm về chất lượng và hiệu suất của sản phẩm. - Người điều hành (Moderator): đảm bảo quá trình đánh giá diễn ra suôn sẻ và công bằng. - Lãnh đạo đánh giá (Review leader): chịu trách nhiệm tổng thể về quá trình đánh giá và đảm bảo các tiêu chí đánh giá được thực hiện. - Đánh giá viên (Reviewer): đánh giá sản phẩm dựa trên các tiêu chí đã được xác định. - Kỹ sư kiểm thử (Tester): kiểm tra sản phẩm để đảm bảo nó hoạt động đúng như mong đợi. Vậy, các vai trò trong một đánh giá chính thức bao gồm: Nhà phát triển, Người điều hành, Lãnh đạo đánh giá, Đánh giá viên và Kỹ sư kiểm thử.

Kỹ thuật kiểm thử tĩnh (static testing) là một phương pháp kiểm thử phần mềm mà không cần thực hiện chương trình. Trong đó, kỹ thuật "Error guessing" là một phương pháp kiểm thử tĩnh phổ biến. Kỹ thuật này dựa trên kinh nghiệm và kiến thức của người kiểm thử để đoán lỗi tiềm ẩn trong mã nguồn. Người kiểm thử sẽ sử dụng kiến thức về lập trình, thiết kế và các nguyên tắc kiểm thử để tìm kiếm các lỗi tiềm ẩn trong mã nguồn. Kỹ thuật này giúp phát hiện các lỗi sớm và hiệu quả, giảm thiểu thời gian và chi phí phát triển phần mềm.

Các phần đánh giá, đi qua từng bước và kiểm tra là một phần của quá trình nào?

Quá trình đánh giá sản phẩm công việc (Work Product Review) là một phần quan trọng trong quản lý chất lượng sản phẩm. Dưới đây là một số bước chính trong quá trình này: Khởi động đánh giá - Chọn người đánh giá - Đánh giá cá nhân - Phân tích và giải quyết vấn đề - Chỉnh sửa lại. Quá trình này giúp đảm bảo rằng sản phẩm công việc đáp ứng các yêu cầu và tiêu chuẩn chất lượng.

Mục tiêu chính của kiểm thử tĩnh là đánh giá chất lượng phần mềm mà không cần thực hiện kiểm thử chức năng. Kiểm thử tĩnh bao gồm việc xem xét các tài liệu và mã nguồn của phần mềm mà không cần thực hiện kiểm thử chức năng. Điều này giúp phát hiện các lỗi và sai sót trong mã nguồn và tài liệu trước khi phần mềm được triển khai. Kiểm thử tĩnh giúp đảm bảo rằng phần mềm được xây dựng dựa trên các yêu cầu và yêu cầu chức năng chính xác, từ đó giúp giảm thiểu các lỗi và sai sót trong phần mềm.

Quá trình đánh giá chính thức thông thường bao gồm năm bước chính. Để xác định trình tự đúng, chúng ta cần xem xét từng bước một. Bước đầu tiên là Planning, đây là bước lập kế hoạch cho quá trình đánh giá. Sau đó, bước tiếp theo là Individual review, đây là bước đánh giá cá nhân. Tiếp theo là Initiate review, đây là bước khởi động quá trình đánh giá. Sau đó là Issue communication & Analysis, đây là bước truyền thông và phân tích vấn đề. Cuối cùng là Fixing & Reporting, đây là bước sửa chữa và báo cáo. Vì vậy, trình tự đúng là Planning -> Individual review -> Initiate review -> Issue communication & Analysis -> Fixing & Reporting.

Trong quá trình phát triển phần mềm, đánh giá (review) đóng vai trò quan trọng trong việc đảm bảo chất lượng sản phẩm. Một trong những lợi ích chính của việc thực hiện đánh giá là xác định các lỗi (đặc biệt là lỗi logic) sớm, từ đó giảm thiểu chi phí tái tạo (rework costs). Khi các lỗi được phát hiện và sửa chữa ngay từ ban đầu, nó giúp giảm thiểu thời gian và chi phí cần thiết để sửa chữa, đồng thời cải thiện độ tin cậy và hiệu suất của sản phẩm. Ngoài ra, việc đánh giá cũng giúp các nhà phát triển hiểu rõ hơn về yêu cầu của khách hàng và cải thiện khả năng giao tiếp trong nhóm.

Technical Review là quá trình đánh giá kỹ thuật nhằm đảm bảo chất lượng của một sản phẩm hoặc dự án. Dưới đây là các thông tin cần biết về Technical Review: I. Reviewers nên là đồng nghiệp kỹ thuật của tác giả, và các chuyên gia kỹ thuật trong cùng hoặc lĩnh vực khác. Điều này giúp đảm bảo rằng các đánh giá được thực hiện một cách khách quan và có chuyên môn. II. Review meeting thường được dẫn dắt bởi tác giả. Điều này cho phép tác giả trình bày rõ ràng về sản phẩm hoặc dự án của mình và nhận được phản hồi từ các reviewer. III. Mục đích của Technical Review là đạt được sự đồng thuận và phát hiện các lỗi tiềm ẩn. Quá trình này giúp đảm bảo rằng sản phẩm hoặc dự án đáp ứng các yêu cầu kỹ thuật và tiêu chuẩn. IV. Scribe là bắt buộc trong quá trình Review. Scribe sẽ ghi chép lại các ý kiến và kết luận của các reviewer, giúp đảm bảo rằng tất cả các thông tin được lưu giữ và có thể tham khảo sau này. V. Chuẩn bị cá nhân trước Review meeting là tùy chọn. Mặc dù vậy, các reviewer nên chuẩn bị kỹ lưỡng trước khi tham gia Review meeting để đảm bảo rằng họ có thể đưa ra các ý kiến và đánh giá chính xác.

Trong quá trình kiểm thử tĩnh (static testing), các loại lỗi thường được phát hiện hiệu quả hơn so với kiểm thử động (dynamic testing) là những lỗi liên quan đến yêu cầu hoặc thiết kế. Điều này bao gồm các lỗi như yêu cầu không đầy đủ, thiết kế không phù hợp, hoặc các lỗi khác liên quan đến yêu cầu hoặc thiết kế của hệ thống. Kiểm thử tĩnh cho phép các chuyên gia kiểm thử có thể xem xét và đánh giá yêu cầu, thiết kế và mã nguồn của hệ thống mà không cần phải thực hiện các thử nghiệm thực tế. Điều này giúp phát hiện các lỗi liên quan đến yêu cầu hoặc thiết kế một cách hiệu quả hơn.

Trong quá trình kiểm tra, các quy tắc và danh sách kiểm tra được sử dụng để đảm bảo sự nhất quán và toàn diện trong việc xác định các lỗi. Điều này giúp giảm thiểu khả năng bỏ sót các lỗi quan trọng và đảm bảo rằng tất cả các bên liên quan đều tuân thủ các tiêu chuẩn giống nhau. Các quy tắc và danh sách kiểm tra cũng giúp tăng cường tính minh bạch và trách nhiệm giải trình trong quá trình kiểm tra, đồng thời cung cấp một cơ sở để đánh giá và cải thiện quy trình kiểm tra.

Trong các lựa chọn trên, hoạt động được thực hiện bởi các nhà phát triển thường liên quan đến việc đánh giá kỹ thuật của một tài liệu chức năng. Điều này bao gồm việc kiểm tra tính chính xác và đầy đủ của các yêu cầu kỹ thuật, cũng như đảm bảo rằng tài liệu chức năng phù hợp với các tiêu chuẩn và quy định của dự án. Các nhà phát triển thường có kiến thức chuyên môn sâu về công nghệ và kỹ thuật, vì vậy họ có thể đánh giá kỹ thuật một cách hiệu quả. Ngoài ra, hoạt động này cũng giúp đảm bảo rằng các yêu cầu của khách hàng được hiểu và thực hiện đúng cách.