Tất cả câu hỏi

Đáp án đúng: "Data sources, formats, and integration points". Khi chọn một giải pháp đóng gói (packaged solution, tức phần mềm thương mại mua sẵn), việc phân tích yêu cầu dữ liệu phải trả lời dữ liệu đến từ đâu, ở định dạng nào và giải pháp phải trao đổi dữ liệu với hệ thống nào khác, vì gói phần mềm có mô hình dữ liệu riêng nên cần ánh xạ, chuyển đổi, di trú và tích hợp với dữ liệu sẵn có của tổ chức. "Only the storage capacity of the solution" sai vì chữ only thu hẹp vào dung lượng lưu trữ, một ràng buộc kỹ thuật nhỏ chứ không phải toàn bộ nhu cầu dữ liệu. "User access permissions" thuộc yêu cầu bảo mật (security), quan trọng khi cấu hình gói nhưng không cho biết dữ liệu nào cần có và luân chuyển ra sao. "The cost of data storage" là yếu tố chi phí trong quyết định mua, không mô tả bản thân nhu cầu dữ liệu.

Đáp án đúng: "To define data items and structures with consistent definitions for all project stakeholders.". Data dictionary (từ điển dữ liệu) là kho tập trung định nghĩa từng phần tử dữ liệu và cấu trúc dữ liệu của miền bài toán: tên, ý nghĩa, kiểu, độ dài, miền giá trị, các thành phần cấu tạo nên nó. Công cụ này thuộc hoạt động phân tích và đặc tả yêu cầu dữ liệu, giúp khách hàng, người phân tích nghiệp vụ, lập trình viên và kiểm thử viên cùng hiểu một nghĩa duy nhất cho mỗi thuật ngữ dữ liệu, tránh mỗi nơi định nghĩa một kiểu. "To list all functional requirements in a project" sai vì danh sách yêu cầu chức năng nằm trong SRS hay product backlog, không phải trong từ điển dữ liệu. "To depict the sequence of process flows within a system" là việc của sơ đồ quy trình như activity diagram hay swimlane diagram. "To model user interface interactions." thuộc về mô hình giao diện như dialog map, wireframe hay prototype, không liên quan tới việc định nghĩa dữ liệu.

Đáp án đúng: "Eliciting, analyzing, documenting, and validating the needs of project stakeholders.". Business Analyst (BA, chuyên viên phân tích nghiệp vụ), còn gọi là requirements analyst, là người giữ vai trò chính trong kỹ nghệ yêu cầu: khơi gợi (elicitation) nhu cầu từ các bên liên quan, phân tích để làm rõ và phát hiện xung đột, viết thành đặc tả rồi thẩm định (validation) để chắc rằng yêu cầu phản ánh đúng điều họ cần. BA là cầu nối giữa phía khách hàng và đội phát triển, tập trung vào câu hỏi hệ thống phải làm gì. "Programming and testing software." là việc của lập trình viên và kiểm thử viên; BA có thể góp tiêu chí chấp nhận nhưng không viết mã hay chạy kiểm thử. "Designing system architecture and databases." thuộc về kiến trúc sư và người thiết kế, tức là quyết định hệ thống được xây như thế nào, một bước nằm sau khi yêu cầu đã rõ. "Managing project budget and schedule." là trách nhiệm của quản lý dự án (project manager); BA chỉ cung cấp yêu cầu làm đầu vào cho việc ước lượng và lập lịch chứ không nắm ngân sách hay tiến độ.

Đáp án đúng: "A small team to establish the best way to use the tool". Theo ISTQB Foundation, khi đưa một công cụ mới vào tổ chức nên bắt đầu bằng dự án thí điểm (pilot project) với một nhóm nhỏ: tìm hiểu công cụ chi tiết, xác định cách nó khớp với quy trình hiện có, đặt ra cách dùng chuẩn, quy ước đặt tên và cách bảo trì, đánh giá lợi ích so với chi phí. Chỉ sau khi thí điểm thành công mới triển khai rộng. "Everyone who may eventually have some use for the tool" sai vì triển khai cho mọi người ngay khi chưa có cách dùng chuẩn dễ dẫn tới dùng lộn xộn và thất bại. "The independent testing team" không phải câu trả lời đúng vì việc thí điểm do một nhóm nhỏ được chọn đảm nhận, không gắn cứng với đội kiểm thử độc lập. "The vendor contractor to write the initial scripts" sai vì nhà cung cấp viết kịch bản thì tổ chức không tự học được cách dùng phù hợp với mình.

Đáp án đúng: "Scribe". Người ghi chép (scribe, recorder) trong rà soát hình thức có nhiệm vụ ghi lại mọi lỗi, vấn đề và điểm còn mở được nêu trong cuộc họp rà soát, cùng các đề xuất cải tiến, làm cơ sở cho bước làm lại và theo dõi. "Moderator" dẫn dắt quy trình và chủ trì cuộc họp; việc điều hành đòi hỏi tập trung nên ghi chép được giao cho người khác. "Reviewers" là những người rà soát, tìm lỗi và nêu vấn đề trong cuộc họp; họ cung cấp nội dung chứ không phải người lưu lại. "Author" là tác giả tài liệu, người nhận danh sách lỗi để sửa trong bước làm lại; ở một số rà soát ít hình thức tác giả có thể tự ghi, nhưng vai trò được giao chính thức việc này là người ghi chép.

Đáp án đúng: "i,ii,iii are true and iv is false". Theo ISTQB, kiểm thử thành phần (component testing) là cấp kiểm thử các phần nhỏ nhất có thể kiểm thử riêng, còn được gọi là kiểm thử đơn vị (unit testing), kiểm thử mô-đun (module testing) và kiểm thử chương trình (program testing), nên mục i, ii, iii đúng. Kiểm thử thành phần hệ thống (system component testing) không phải tên gọi chuẩn; nó lẫn lộn giữa cấp thành phần và cấp hệ thống, vốn là hai cấp kiểm thử khác nhau, nên mục iv sai. "i,ii,iii,iv are false" sai vì loại cả ba tên đồng nghĩa đã được thừa nhận. "i,ii,iv are true and iii is false" sai vì loại kiểm thử mô-đun, một tên gọi chuẩn, lại nhận mục iv không chuẩn. "All of them are true" sai vì đưa cả mục iv vào.

Đáp án đúng: "Even though the numbers you look at appear better, to achieve these numbers, people are doing other aspects of their work much less well.". Rối loạn đo lường (measurement dysfunction) là hiện tượng khi một chỉ số được dùng để đánh giá con người, họ điều chỉnh hành vi cho chỉ số đẹp lên, nhưng cái giá là những phần việc không được đo bị làm kém đi; ví dụ chấm điểm người kiểm thử theo số lỗi tìm được thì họ báo nhiều lỗi vặt và né lỗi khó, con số tốt hơn mà chất lượng thực giảm. "We don't know how to measure a variable (our measurement is dysfunctional)" mô tả việc không biết cách đo, đó là vấn đề độ tin cậy của phép đo chứ không phải sự biến dạng hành vi do bị đo. "You are measuring the wrong thing and thus reaching the wrong conclusions." là lỗi chọn sai đại lượng dẫn tới kết luận sai, không nói tới việc con người làm tệ đi phần việc khác. "All of the others" sai vì hai mô tả kia không phải bản chất của rối loạn đo lường.

Đáp án đúng: "Syntax testing". Chuẩn BS 7925-2 về kiểm thử thành phần chia kỹ thuật thành hai nhóm: hộp trắng (white box) dựa trên cấu trúc mã như statement testing, branch testing, data flow testing, và hộp đen (black box) dựa trên đặc tả như phân hoạch tương đương, giá trị biên, syntax testing. Syntax testing thiết kế ca kiểm thử từ cú pháp đầu vào đã đặc tả hình thức, không nhìn vào mã, nên không thuộc hộp trắng. Cần nói thẳng: "Random testing" cũng được BS 7925-2 xếp vào nhóm hộp đen, vì nó sinh đầu vào ngẫu nhiên theo phân bố của miền đầu vào chứ không dựa vào cấu trúc mã, nên xét chặt thì câu hỏi có hai phát biểu đúng; vì đề chỉ cho chọn một, đáp án chốt là syntax testing theo cách hiểu phổ biến nhất, còn random testing là phương án nhiễu rất sát. "Data Flow testing." là kỹ thuật hộp trắng, thiết kế ca theo cặp định nghĩa và sử dụng biến. "Statement testing" là kỹ thuật hộp trắng cơ bản nhất, nhắm cho mọi câu lệnh được thực thi.

Đáp án đúng: "Designed by a person from a different organization". ISTQB sắp mức độc lập của kiểm thử từ thấp tới cao: chính tác giả tự kiểm thử, một người khác trong cùng nhóm, một người từ nhóm hay bộ phận khác trong tổ chức, rồi tới người từ tổ chức khác như công ty kiểm thử thuê ngoài hay đơn vị chứng nhận; người ngoài tổ chức ít chịu ảnh hưởng của áp lực nội bộ và thiên kiến của tác giả nhất, nên độc lập cao nhất. "Designed by persons who write the software under test" là mức thấp nhất vì tác giả dễ mù với lỗi của chính mình. "Designed by another person" chỉ là mức độc lập kế tiếp, vẫn có thể cùng nhóm, cùng chịu áp lực tiến độ. "Designed by a person from a different section" độc lập hơn vì khác bộ phận, nhưng vẫn cùng tổ chức nên chưa đạt mức cao nhất.

Đáp án đúng: "Test Effectiveness". Độ phủ mã (code coverage) là tỉ lệ cấu trúc mã như câu lệnh, nhánh, điều kiện đã được bộ ca kiểm thử thực thi. Nó cho biết bộ kiểm thử đã chạm tới bao nhiêu phần của mã, phần nào chưa được kiểm thử, nên được dùng làm thước đo mức kỹ lưỡng, tức hiệu quả của kiểm thử (test effectiveness) và để thiết kế thêm ca kiểm thử cho phần còn trống. "Defects" sai vì độ phủ không đếm lỗi; độ phủ cao vẫn có thể còn lỗi và độ phủ thấp không nói được có bao nhiêu lỗi. "Trends analysis" (phân tích xu hướng) dùng chuỗi số liệu theo thời gian như số lỗi mở, đóng mỗi tuần, không phải điều độ phủ mã đo trực tiếp. "Time Spent Testing" là số đo công sức, nỗ lực của đội kiểm thử, không phản ánh mã đã được thực thi tới đâu.

Đáp án đúng: "Selecting the personnel, allocating roles.". Quy trình rà soát hình thức theo ISTQB gồm lập kế hoạch, khởi động (kick-off), chuẩn bị cá nhân, họp rà soát, làm lại (rework) và theo dõi (follow-up); bước lập kế hoạch định nghĩa tiêu chí rà soát, chọn người tham gia, phân vai, xác định tiêu chí vào ra và kiểm tra tiêu chí vào. "Explaining the objectives" là việc của buổi khởi động, khi người điều phối phát 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. "Individual Meeting preparations" là bước chuẩn bị cá nhân, mỗi người rà soát tự đọc tài liệu và ghi lỗi tiềm năng trước cuộc họp. "Follow up" là bước cuối, khi người điều phối kiểm tra các lỗi đã được sửa và tiêu chí ra đã đạt.

Đáp án đúng: "Tool support.". Chi phí của rà soát (review) thường được tính gồm chính quá trình rà soát, tức thời gian lập kế hoạch, chuẩn bị riêng và họp; công phân tích các số đo thu được; và công cải tiến quy trình rút ra từ kết quả rà soát; hỗ trợ công cụ không được tính vào nhóm chi phí này vì rà soát có thể làm hoàn toàn bằng tài liệu và con người. "Review process itself" là khoản chi phí lớn nhất, chính là công sức của những người tham gia. "Metrics analysis" là chi phí vì thu thập và phân tích số đo như số khiếm khuyết, tốc độ rà soát cần thời gian. "Process improvement." dễ gây nhầm vì nó thường được xem là lợi ích của rà soát, nhưng để hiện thực hoá cải tiến quy trình người ta phải bỏ công phân tích nguyên nhân và thay đổi cách làm sau buổi rà soát, nên nó cũng được tính là một khoản chi phí.

Đáp án đúng: "Load Testing". Kiểm thử tải (load testing) là loại kiểm thử hiệu năng, đặt đối tượng dưới các mức tải công việc khác nhau, chẳng hạn số người dùng đồng thời hay số giao dịch tăng dần, để đo và đánh giá hành vi hiệu năng cũng như khả năng tiếp tục hoạt động đúng ở từng mức tải. Mô tả trong câu hỏi, thay đổi workload để đo hiệu năng và khả năng hoạt động, khớp đúng định nghĩa này. "Integration Testing" kiểm giao diện và tương tác giữa các thành phần hay hệ thống được ghép lại, không xoay quanh mức tải. "System Testing" là cấp kiểm thử trên toàn bộ hệ thống, có thể chứa kiểm thử tải nhưng là khái niệm rộng hơn, không chỉ riêng việc thay đổi tải. "Usability Testing" đánh giá mức dễ học, dễ dùng đối với người dùng thật, không đo hành vi dưới tải.

Đáp án đúng: "Boo01k". Phân vùng tương đương (equivalence partitioning) chọn một giá trị đại diện cho mỗi lớp dữ liệu được hệ thống xử lý như nhau; với ô chỉ nhận giá trị chữ và số (alphanumeric), giá trị tiêu biểu cho lớp hợp lệ là chuỗi pha trộn cả chữ cái lẫn chữ số, và "Boo01k" chứa chữ B, o, k cùng chữ số 0 và 1 nên thể hiện đúng lớp này. "BOOK" chỉ gồm chữ in hoa, "Book" chỉ gồm chữ cái với chữ đầu viết hoa, "book" chỉ gồm chữ thường; hiểu rộng thì chuỗi toàn chữ cái vẫn có thể được ô chấp nhận, nhưng chúng không có chữ số nên không đại diện cho đặc trưng chữ và số mà câu hỏi muốn kiểm tra, chúng là đại diện cho lớp chỉ có chữ cái, khác với lớp chữ và số.

Đáp án đúng: "Supportability". Chuẩn ISO 9126 về chất lượng sản phẩm phần mềm định nghĩa sáu đặc tính chất lượng: chức năng (functionality), độ tin cậy (reliability), tính khả dụng (usability), hiệu suất (efficiency), khả năng bảo trì (maintainability) và tính khả chuyển (portability). Khả năng hỗ trợ (supportability) không có trong danh sách này; nó là chữ S trong mô hình FURPS của Hewlett-Packard, một cách phân loại khác. "Functionality" là đặc tính thứ nhất của ISO 9126, gồm tính phù hợp, độ chính xác, khả năng tương tác, bảo mật. "Usability" là đặc tính về mức dễ hiểu, dễ học, dễ vận hành. "Maintainability" là đặc tính về mức dễ phân tích, dễ thay đổi, ổn định và dễ kiểm thử của phần mềm. Ba đặc tính này đều thuộc chuẩn nên không phải đáp án.

Đáp án đúng: "All of the others". Kiểm thử vòng lặp (loop testing) là kỹ thuật hộp trắng tập trung vào tính đúng đắn của cấu trúc lặp, với cách thiết kế riêng cho từng loại vòng lặp, nên áp dụng được cho tất cả các loại được nêu. "Simple Loops" là vòng lặp đơn, kiểm thử bằng cách bỏ qua vòng, chạy một lần, hai lần, nhiều lần và quanh số lần tối đa. "Nested Loops" là vòng lặp lồng nhau, kiểm thử từ vòng trong cùng ra ngoài trong khi giữ các vòng ngoài ở giá trị nhỏ nhất. "Concatenated Loops" là các vòng lặp nối tiếp, kiểm thử như vòng đơn nếu chúng độc lập, hoặc như vòng lồng nếu vòng sau phụ thuộc vào vòng trước. Mỗi loại riêng lẻ đều đúng nhưng chọn một cái là chưa đủ, vì kỹ thuật này bao trùm cả ba.

Đáp án đúng: "False". Phát biểu rằng kiểm thử kỹ lưỡng có thể loại bỏ mọi lỗi khỏi chương trình trước khi giao cho khách hàng là sai, vì nó trái với hai nguyên tắc kiểm thử trong ISTQB Foundation. Thứ nhất, kiểm thử cho thấy sự hiện diện của lỗi chứ không chứng minh được không còn lỗi (testing shows presence of defects): dù không tìm thấy lỗi nào, ta cũng không thể kết luận phần mềm đúng hoàn toàn. Thứ hai, kiểm thử vét cạn là bất khả thi (exhaustive testing is impossible): số tổ hợp đầu vào, trạng thái và đường đi quá lớn để thử hết, nên luôn phải chọn mẫu theo rủi ro và ưu tiên. Kiểm thử làm giảm xác suất lỗi còn sót và tăng niềm tin vào chất lượng, nhưng không bảo đảm loại bỏ tất cả. Vì vậy "True" sai: nó đòi hỏi một điều kiểm thử không thể đạt được dù làm kỹ tới đâu.

Đáp án đúng: "(i) Identifying defects.". Theo ISTQB Foundation, rà soát (review), phân tích tĩnh (static analysis) và kiểm thử động (dynamic testing) có chung mục tiêu là xác định lỗi (identifying defects); chúng chỉ khác nhau ở cách tìm: rà soát và phân tích tĩnh tìm trực tiếp khiếm khuyết trong sản phẩm mà không chạy, còn kiểm thử động chạy phần mềm để làm lộ ra thất bại (failure) rồi lần về khiếm khuyết. Chúng bổ sung cho nhau vì mỗi kỹ thuật tìm hiệu quả những loại lỗi khác nhau. "(ii) Fixing defects." sai vì sửa lỗi là gỡ lỗi (debugging), việc của lập trình viên sau khi lỗi đã được tìm thấy, không phải mục tiêu của ba hoạt động này. "(i) and (ii)" sai vì kèm theo mục sửa lỗi. "None of (i) nor (ii)" sai vì phủ nhận cả mục tiêu chung là tìm lỗi.

Đáp án đúng: "(ii) Structural Testing". Kiểm thử cấu trúc (structural testing, hộp trắng) thiết kế ca kiểm thử từ cấu trúc bên trong như câu lệnh, nhánh, đường đi, nhằm làm chạy qua từng phần của mã; vì xuất phát từ mã chứ không từ cách người dùng sử dụng, các ca này thường là những tổ hợp nhân tạo, không nhất thiết phản ánh tình huống thực tế. "(i) Functional testing" dựa trên yêu cầu và hành vi mong đợi, thường xây ca kiểm thử từ kịch bản nghiệp vụ, nên gần với tình huống thực tế hơn. "Both of (i) and (ii)" sai vì kiểm thử chức năng vốn nhằm mô phỏng cách hệ thống được dùng. "None of (i) nor (ii)" sai vì kiểm thử cấu trúc đúng là loại có thể không mô phỏng được thế giới thực.

Đáp án đúng: "Run the risk that the requirements are not satisfied.". Kiểm thử hộp trắng (white-box testing) thiết kế ca kiểm thử từ cấu trúc mã, nên chỉ kiểm được những gì đã được lập trình; nếu một yêu cầu bị hiểu sai hoặc bị bỏ sót hoàn toàn trong mã thì không có câu lệnh hay nhánh nào để phủ, và kiểm thử hộp trắng sẽ không phát hiện ra. Chỉ dùng hộp trắng vì vậy có rủi ro hệ thống không thoả yêu cầu. "Ensure the test item is adequately tested" sai vì độ phủ cấu trúc cao không đảm bảo đủ, còn thiếu góc nhìn từ đặc tả. "Make the need for black-box testing redundant." sai vì hai cách tiếp cận bổ sung cho nhau, hộp đen mới đối chiếu với yêu cầu. "Suffices for the unit testing phase" sai vì ngay ở cấp thành phần vẫn cần kiểm theo đặc tả của thành phần, hộp trắng một mình không đủ.