Nguyên lý "kiểm thử chứng minh sự tồn tại của lỗi" nghĩa là gì?
A.Càng nhiều test case thì càng ít lỗi lọt ra production
B.Test pass không chứng minh phần mềm không còn lỗi
C.Tester phải tìm được lỗi thì mới hoàn thành công việc
D.Mọi phần mềm đều còn ít nhất một lỗi chưa tìm ra
Đáp án: B
Kiểm thử chỉ có thể chứng minh lỗi đang tồn tại, không chứng minh được là không còn lỗi. Toàn bộ test pass chỉ nói rằng những gì được kiểm chưa lộ lỗi — nó không nói gì về phần chưa kiểm.
Vì sao kiểm thử toàn bộ (exhaustive testing) là bất khả thi?
A.Vì công cụ kiểm thử hiện nay chưa đủ mạnh
B.Vì tester không bao giờ đủ thời gian trong dự án
C.Số tổ hợp đầu vào và trạng thái quá lớn để chạy hết
D.Vì yêu cầu luôn thay đổi trong quá trình phát triển
Đáp án: C
Vì không gian đầu vào và trạng thái bùng nổ tổ hợp. Chỉ một ô nhập số nguyên đã có hàng tỉ giá trị, chưa kể thứ tự thao tác và trạng thái hệ thống. Nên kiểm thử luôn là bài toán chọn mẫu theo rủi ro.
Component (unit) → integration (tích hợp) → system (toàn hệ thống) → acceptance (nghiệm thu). Mỗi cấp độ có đối tượng kiểm thử, mục tiêu và người thực hiện khác nhau, không phải chỉ khác quy mô.
Thông tin nào bắt buộc phải có trong một bug report dùng được?
A.Bước tái hiện, kết quả mong đợi và thực tế
B.Tên người chịu trách nhiệm gây ra lỗi
C.Đoạn code nghi ngờ gây ra lỗi
D.Đánh giá thời gian cần để sửa lỗi
Đáp án: A
Tối thiểu: các bước tái hiện, kết quả mong đợi, kết quả thực tế, kèm môi trường (phiên bản, trình duyệt, tài khoản, dữ liệu) và bằng chứng. Thiếu bước tái hiện thì bug gần như chắc chắn bị trả lại.
Confirmation testing (re-test) khác regression testing ở điểm nào?
A.Confirmation chạy trên staging, regression chạy trên production
B.Confirmation làm thủ công, regression làm tự động
C.Confirmation do tester làm, regression do developer làm
D.Confirmation kiểm bản vá, regression kiểm phần còn lại
Đáp án: D
Confirmation testing chạy lại đúng ca đã lỗi để xác nhận bản vá có tác dụng. Regression testing chạy các ca khác để chắc bản vá không làm hỏng phần đang chạy tốt. Sửa xong một bug thì cần cả hai.
Kiểm nhanh rằng các luồng cốt lõi còn chạy sau khi có bản build mới — đăng nhập, luồng nghiệp vụ chính, kết nối cơ sở dữ liệu. Nếu smoke test đỏ thì trả build lại ngay, không mất công chạy bộ test đầy đủ.
Exit criteria trong kế hoạch kiểm thử dùng để làm gì?
A.Chốt trước điều kiện được coi là đã test đủ
B.Ghi lại ngày kết thúc giai đoạn test theo kế hoạch
C.Liệt kê những chức năng không nằm trong phạm vi test
D.Xác định ai được quyền đóng một bug đã sửa
Đáp án: A
Chốt trước điều kiện nào thì coi là đã kiểm thử đủ: độ phủ yêu cầu, tỉ lệ test case đã chạy, số lỗi mở còn lại theo từng mức severity, và rủi ro còn tồn đọng. Không có tiêu chí này thì "test xong chưa" luôn là tranh cãi cảm tính.
401 Unauthorized = chưa xác thực hoặc token không hợp lệ, cần đăng nhập lại. 403 Forbidden = đã biết bạn là ai nhưng bạn không có quyền với tài nguyên này. Nhầm hai mã này làm client xử lý sai, ví dụ tự động đăng xuất người dùng khi họ chỉ thiếu quyền.
A.Hệ thống có chạy được trên nhiều trình duyệt không
B.Người khuyết tật có sử dụng được không
C.Giao diện có hiển thị đúng thiết kế không
D.Người dùng có hoàn thành được công việc dễ dàng không
Đáp án: D
Đo xem người dùng thật có hoàn thành được công việc của họ dễ dàng không — dễ học, dễ thao tác, ít nhầm lẫn. Nó không kiểm chức năng đúng hay sai mà kiểm chức năng đúng đó có dùng được hay không.
Kiểm thử tương thích (compatibility testing) kiểm điều gì?
A.Hệ thống chạy đúng trên các nền tảng và cấu hình khác nhau
B.Các module trong hệ thống giao tiếp đúng với nhau
C.Hệ thống chịu được số người dùng đồng thời theo yêu cầu
D.Dữ liệu cũ vẫn đọc được sau khi nâng cấp
Đáp án: A
Kiểm hệ thống chạy đúng trên các nền tảng và cấu hình khác nhau: trình duyệt, hệ điều hành, thiết bị, độ phân giải màn hình, phiên bản ứng dụng. Không thể phủ hết nên phải chọn theo dữ liệu người dùng thật.
Alpha testing và beta testing khác nhau ở điểm nào?
A.Alpha kiểm chức năng, beta kiểm hiệu năng
B.Alpha diễn ra tại nơi phát triển, beta tại nơi người dùng
C.Alpha do tester nội bộ chạy, beta do tester thuê ngoài chạy
D.Alpha chạy trước khi code xong, beta chạy sau khi phát hành
Đáp án: B
Cả hai đều là hình thức kiểm thử nghiệm thu. Alpha diễn ra tại nơi phát triển, thường do người dùng tiềm năng hoặc nhân sự nội bộ thực hiện có giám sát. Beta diễn ra tại nơi làm việc thật của người dùng, trong môi trường thật của họ.
Ad-hoc testing khác exploratory testing ở điểm nào?
A.Ad-hoc do người mới làm, exploratory do người có kinh nghiệm
B.Ad-hoc chỉ kiểm giao diện, exploratory kiểm cả nghiệp vụ
C.Ad-hoc chạy trước khi có yêu cầu, exploratory chạy sau
D.Exploratory có định hướng và ghi nhận, ad-hoc thì không
Đáp án: D
Exploratory có mục tiêu (charter), khung thời gian và ghi chép lại đường đã đi — nên đo được và bàn giao được. Ad-hoc là thử tự do, không định hướng, không ghi nhận, chủ yếu để làm quen sản phẩm.
Kiểm thử theo danh sách kiểm (checklist-based testing) phù hợp nhất khi nào?
A.Khi hệ thống hoàn toàn mới và chưa ai hiểu nghiệp vụ
B.Khi cần đo chính xác thời gian kiểm thử từng chức năng
C.Khi cần chứng minh độ phủ cho kiểm toán bên ngoài
D.Khi cần phủ nhanh những điểm quen thuộc
Đáp án: D
Khi cần phủ nhanh những điểm quen thuộc mà không muốn tốn công soạn test case chi tiết: danh sách kiểm cho biểu mẫu, cho màn hình danh sách, cho luồng thanh toán, cho phần tải tệp. Chi phí soạn thấp mà độ phủ ổn định.
Trong Scrum, ai chịu trách nhiệm về chất lượng sản phẩm?
A.Cả team, tester giữ vai trò chuyên môn
B.Product Owner, vì họ nghiệm thu hạng mục
C.Trưởng nhóm kỹ thuật, vì họ duyệt mã nguồn
D.Tester, vì đó là chuyên môn của họ
Đáp án: A
Cả team — cách tiếp cận whole-team. Tester mang chuyên môn kiểm thử và tư duy tìm rủi ro, nhưng developer viết test đơn vị, review lẫn nhau, và cùng chịu Definition of Done. Chất lượng giao khoán cho một người thì luôn bị kiểm ở khâu cuối.
Phân vùng tương đương (equivalence partitioning) giúp giảm số ca kiểm thử bằng cách nào?
A.Gộp nhiều bước kiểm thử vào một ca duy nhất
B.Bỏ bớt các ca kiểm thử có độ ưu tiên thấp
C.Chỉ kiểm các giá trị nằm ở biên của khoảng hợp lệ
D.Gom giá trị xử lý như nhau, mỗi nhóm thử một giá trị
Đáp án: D
Chia miền đầu vào thành các nhóm được hệ thống xử lý như nhau, rồi chỉ thử một giá trị đại diện cho mỗi nhóm. Với ô nhập tuổi từ 18 đến 60, ba nhóm là dưới 18, từ 18 đến 60, và trên 60 — thử thêm giá trị trong cùng nhóm không phát hiện thêm gì.
Entry criteria trong kế hoạch kiểm thử dùng để làm gì?
A.Quy định ai được phép tham gia đợt kiểm thử
B.Liệt kê các ca kiểm thử bắt buộc phải chạy
C.Xác định thời điểm được phép kết thúc kiểm thử
D.Xác định điều kiện tối thiểu để bắt đầu
Đáp án: D
Xác định điều kiện tối thiểu để bắt đầu: build đã triển khai được lên môi trường test, smoke test đã qua, tài liệu yêu cầu đã chốt, và dữ liệu test đã sẵn sàng. Bắt đầu khi chưa đủ điều kiện làm phần lớn thời gian bị tiêu vào việc chờ và báo lỗi môi trường.
B.Hai khái niệm giống nhau, chỉ khác cách gọi theo công ty
C.Sanity chạy trước khi phát hành, smoke chạy sau
D.Sanity kiểm sâu vùng vừa sửa, smoke kiểm rộng
Đáp án: D
Smoke test kiểm rộng và nông — các chức năng chính có chạy không, để quyết định build có đáng kiểm tiếp hay không. Sanity test kiểm hẹp và sâu — tập trung vào vùng vừa được sửa hoặc vừa thêm, để xác nhận thay đổi có hiệu lực đúng.
B.Scenario dùng cho kiểm thử thủ công, case dùng cho tự động
C.Scenario do khách hàng viết, case do QA viết
D.Scenario nêu việc cần kiểm, case nêu bước và kết quả
Đáp án: D
Scenario nêu việc cần kiểm ở mức khái quát — "đặt hàng khi hết tồn kho". Case cụ thể hoá thành các bước, dữ liệu đầu vào và kết quả mong đợi để người khác thực hiện lại được. Scenario dùng để lập kế hoạch và rà độ phủ, case dùng để thực hiện.
Nhận một màn hình mới hoàn toàn để kiểm thử. Nên bắt đầu từ đâu?
A.Đọc yêu cầu, thử luồng chính trước khi vào chi tiết
B.Kiểm mọi ô nhập với giá trị không hợp lệ trước
C.Kiểm khả năng tương thích trên nhiều trình duyệt
D.Viết đầy đủ ca kiểm thử rồi mới mở màn hình lên
Đáp án: A
Đọc yêu cầu để hiểu màn hình này phục vụ việc gì, rồi chạy luồng chính một lượt. Nếu luồng chính đã hỏng thì trả lại build ngay thay vì tốn thời gian kiểm chi tiết. Sau đó mới đi vào các nhánh lỗi, giá trị biên và các tổ hợp.
Trong buổi họp hằng ngày của nhóm, QA nên nêu thông tin gì là hữu ích nhất?
A.Kế hoạch kiểm thử chi tiết cho tuần tới
B.Việc đang bị chặn và rủi ro mới thấy
C.Danh sách toàn bộ lỗi đã báo trong ngày
D.Số lượng ca kiểm thử đã chạy hôm qua
Đáp án: B
Nêu việc đang bị chặn (môi trường hỏng, chờ dữ liệu, chờ bản sửa) và rủi ro mới phát hiện ảnh hưởng tới kế hoạch phát hành. Đây là những thứ cần cả nhóm phối hợp; số liệu tiến độ thì ai cũng xem được trong công cụ.
Nghịch lý thuốc trừ sâu (pesticide paradox) trong kiểm thử mô tả hiện tượng gì?
A.Sửa một lỗi thường làm phát sinh lỗi khác
B.Test tự động luôn kém tin cậy hơn test thủ công
C.Bộ test lặp lại mãi sẽ không còn tìm ra lỗi mới
D.Càng nhiều tester thì càng khó thống nhất kết quả
Đáp án: C
Chạy mãi một bộ test thì hiệu quả phát hiện lỗi giảm dần — nó chỉ phủ những đường đã biết, còn lỗi mới nằm ở chỗ chưa ai chạm tới. Bộ test cần được rà soát và bổ sung định kỳ.
Phân biệt error, defect và failure theo thuật ngữ ISTQB?
A.Error do developer gây ra, defect do tester phát hiện, failure do người dùng báo
B.Error là lỗi nhẹ, defect là lỗi nặng, failure là sự cố production
C.Con người mắc error, sinh ra defect trong sản phẩm, gây failure khi chạy
D.Ba từ này đồng nghĩa, chỉ khác ngữ cảnh sử dụng
Đáp án: C
Chuỗi nhân quả: con người mắc error (nhầm lẫn) → để lại defect (lỗi trong code hoặc tài liệu) → khi thực thi có thể gây failure (hệ thống hành xử sai). Một defect có thể chưa bao giờ gây failure nếu đoạn code đó không bao giờ chạy.
Severity và priority của một bug khác nhau thế nào?
A.Severity dùng cho production, priority dùng cho môi trường test
B.Severity là tác động kỹ thuật, priority là mức khẩn cấp
C.Hai chỉ số này luôn phải bằng nhau
D.Severity do tester đặt, priority do developer đặt
Đáp án: B
Severity = mức tác động lên hệ thống (crash, mất dữ liệu, sai số liệu, lệch giao diện). Priority = mức khẩn cấp cần sửa, quyết định theo nghiệp vụ. Hai chỉ số này độc lập và thường lệch nhau.
Ô nhập tuổi chấp nhận giá trị từ 18 đến 60. Phân tích giá trị biên chọn những giá trị nào?
A.17, 18, 60, 61
B.18, 30, 60
C.0, 18, 60, 100
D.17, 19, 59, 61
Đáp án: A
17, 18, 60, 61 — mỗi biên lấy giá trị ngay trong và ngay ngoài. Lý do: lỗi lập trình hay gặp nhất ở đây là dùng nhầm > với >=, và chỉ những giá trị sát biên mới lộ ra kiểu lỗi đó.
Khi nào nên dùng bảng quyết định (decision table) để thiết kế test?
A.Khi cần đo độ phủ câu lệnh của mã nguồn
B.Khi kết quả phụ thuộc vào tổ hợp nhiều điều kiện
C.Khi hệ thống có nhiều màn hình nối tiếp nhau
D.Khi cần kiểm tra một ô nhập có nhiều khoảng giá trị
Đáp án: B
Khi kết quả phụ thuộc vào tổ hợp nhiều điều kiện — ví dụ quy tắc tính chiết khấu theo hạng thành viên, giá trị đơn hàng và mã khuyến mại. Bảng giúp lộ ra tổ hợp mà đặc tả bỏ sót.
C.Kiểm thử phiên bản đã đóng băng, không còn thay đổi
D.Kiểm thử giao diện không có tương tác người dùng
Đáp án: B
Xem xét sản phẩm công việc mà không chạy mã: review yêu cầu, review thiết kế, review code, và phân tích tĩnh bằng công cụ (linter, quét bảo mật, kiểm tra kiểu). Nó tìm được cả lỗi trong tài liệu, thứ mà kiểm thử động không chạm tới.
Trong kiểm thử dựa trên rủi ro, mức rủi ro của một chức năng được tính thế nào?
A.Số dòng code của chức năng đó
B.Số lượng test case đã viết cho chức năng đó
C.Thời gian phát triển chức năng đó
D.Khả năng xảy ra nhân với mức thiệt hại
Đáp án: D
Rủi ro = khả năng xảy ra × mức thiệt hại. Khả năng nhìn vào độ phức tạp, mức độ thay đổi gần đây, kinh nghiệm của người làm và lịch sử lỗi; thiệt hại nhìn vào tiền, dữ liệu, uy tín và nghĩa vụ pháp lý.
Load testing và stress testing khác nhau ở điểm nào?
A.Load chạy ở tải dự kiến, stress đẩy vượt ngưỡng
B.Load chạy trên production, stress chạy trên staging
C.Load đo thời gian phản hồi, stress đo mức tiêu thụ bộ nhớ
D.Load kiểm số người dùng, stress kiểm khối lượng dữ liệu
Đáp án: A
Load test chạy ở mức tải dự kiến để xác nhận hệ thống đáp ứng chỉ tiêu. Stress test đẩy vượt ngưỡng để tìm điểm gãy và xem hệ thống gãy như thế nào — gãy êm hay đổ sập kéo theo cả hệ thống khác.
Kiểm thử khám phá (exploratory testing) được mô tả đúng nhất là gì?
A.Chạy lại test case cũ với dữ liệu ngẫu nhiên
B.Kiểm thử tùy hứng, không cần ghi chép gì
C.Thiết kế và thực thi diễn ra đồng thời
D.Kiểm thử do người dùng cuối tự thực hiện
Đáp án: C
Thiết kế test, thực thi và học về sản phẩm diễn ra đồng thời — kết quả bước trước định hướng bước sau. Đây là kỹ thuật dựa trên kinh nghiệm, không phải là kiểm thử tùy hứng vô tổ chức.
C.Có tiền đề rõ và kết quả mong đợi kiểm chứng được
D.Bao phủ càng nhiều chức năng trong một case càng tốt
Đáp án: C
Có tiền đề rõ ràng (tài khoản, dữ liệu, trạng thái), các bước xác định, và kết quả mong đợi kiểm chứng được. Phép thử đơn giản: người khác đọc và chạy lại có ra cùng kết luận pass hay fail không.
Nguyên lý "lỗi tập trung thành cụm" (defect clustering) được dùng thế nào trong lập kế hoạch test?
A.Chỉ kiểm thử module mới viết trong Sprint hiện tại
B.Chia đều số test case cho tất cả module
C.Bỏ qua module đã có nhiều lỗi vì chúng đã được sửa
D.Dồn công sức vào module có lịch sử nhiều lỗi nhất
Đáp án: D
Một phần nhỏ module thường chứa phần lớn lỗi, nên dồn công sức kiểm thử vào đó: nơi phức tạp nhất, thay đổi nhiều nhất, và có lịch sử lỗi dày nhất. Đây là cơ sở dữ liệu để phân bổ, không phải cảm tính.
Kiểm thử chuyển trạng thái (state transition testing) hợp nhất với loại chức năng nào?
A.Chức năng chỉ hiển thị dữ liệu, không có thao tác
B.Chức năng có vòng đời trạng thái rõ ràng
C.Chức năng có nhiều ô nhập liệu dạng số
D.Chức năng tính toán theo nhiều điều kiện song song
Đáp án: B
Chức năng có vòng đời trạng thái: đơn hàng, tài khoản, hồ sơ duyệt, phiên đăng nhập. Kỹ thuật này kiểm cả chuyển đổi hợp lệ lẫn chuyển đổi không được phép xảy ra.
Ngoài mã trạng thái, một ca kiểm thử API nên kiểm thêm gì?
A.Số lượng dòng log mà server ghi ra
B.Phiên bản thư viện mà server đang dùng
C.Cấu trúc dữ liệu trả về và tác động lên dữ liệu lưu trữ
D.Thời gian phản hồi của lần gọi đầu tiên
Đáp án: C
Kiểm cấu trúc và nội dung dữ liệu trả về (đúng schema, đúng kiểu, thiếu trường nào), và tác động phụ — dữ liệu có ghi đúng vào cơ sở dữ liệu, có gửi sự kiện hay email không. Mã 200 chỉ nói yêu cầu được nhận, không nói kết quả đúng.
Vì sao không nên sao chép nguyên dữ liệu production sang môi trường test?
A.Dữ liệu cá nhân bị ràng buộc pháp lý về bảo vệ và truy cập
B.Dữ liệu production thay đổi liên tục nên test không ổn định
C.Dữ liệu production quá lớn nên môi trường test không chứa nổi
D.Dữ liệu production không có đủ ca biên để kiểm thử
Đáp án: A
Vì nó chứa dữ liệu cá nhân — họ tên, số điện thoại, địa chỉ, thông tin thanh toán — trong khi môi trường test thường có kiểm soát truy cập lỏng hơn nhiều. Cách đúng là ẩn danh hoặc sinh dữ liệu giả giữ nguyên đặc điểm phân bố.
Test tự động lúc pass lúc fail dù code không đổi. Cách xử lý đúng là gì?
A.Bỏ qua vì đây là hiện tượng bình thường của test đầu cuối
B.Xóa test đó khỏi bộ và kiểm phần đó bằng tay
C.Tìm nguyên nhân bất định rồi sửa hoặc tách test đó ra
D.Cho chạy lại tự động tối đa ba lần rồi lấy kết quả tốt nhất
Đáp án: C
Truy nguyên nhân bất định: chờ theo thời gian cố định thay vì chờ theo điều kiện, dữ liệu dùng chung giữa các test, thứ tự chạy phụ thuộc nhau, hoặc phụ thuộc dịch vụ ngoài. Trong lúc chưa sửa xong thì tách test đó ra khỏi luồng chặn chứ không cho chạy lại tới khi xanh.
Developer đóng bug với lý do "không tái hiện được". QA nên làm gì tiếp theo?
A.Nâng severity lên mức cao nhất để buộc phải xử lý
B.Bổ sung môi trường, dữ liệu và bằng chứng rồi mở lại
C.Chấp nhận đóng vì developer hiểu hệ thống hơn
D.Báo cáo lên quản lý để can thiệp ngay
Đáp án: B
Bổ sung chính xác điều kiện tiền đề: phiên bản build, tài khoản và quyền, dữ liệu cụ thể, trình duyệt và thiết bị, thời điểm, kèm video hoặc log. Phần lớn ca không tái hiện được là do báo cáo thiếu một điều kiện mà người báo tưởng là hiển nhiên.
B.Kiểm thử trên môi trường gần giống production hơn
C.Chuyển việc kiểm thử sang cho developer đảm nhiệm
D.Đưa hoạt động kiểm thử vào sớm hơn trong vòng phát triển
Đáp án: D
Đưa hoạt động kiểm thử về sớm hơn: tham gia review yêu cầu, đặt câu hỏi ở giai đoạn thiết kế, viết ca kiểm thử trước khi code. Lỗi phát hiện càng sớm thì chi phí sửa càng thấp.
A.Chạy công cụ quét tự động và báo cáo toàn bộ kết quả
B.Phân quyền, dữ liệu nhạy cảm và kiểm chứng dữ liệu đầu vào
C.Kiểm độ mạnh thuật toán mã hóa mà hệ thống sử dụng
D.Thử tấn công từ chối dịch vụ vào môi trường staging
Đáp án: B
Ba nhóm cơ bản: phân quyền (tài khoản quyền thấp gọi thẳng API quyền cao), dữ liệu nhạy cảm (mật khẩu và token có bị lộ trong log, URL, phản hồi API không), và kiểm chứng đầu vào (chuỗi dài, ký tự đặc biệt, tải tệp sai định dạng).
Ước lượng thời gian kiểm thử cho một hạng mục nên dựa vào đâu?
A.Thời gian còn lại trong Sprint sau khi trừ phần code
B.Phạm vi, mức rủi ro và dữ liệu từ các hạng mục tương tự
C.Số test case dự kiến nhân với thời gian trung bình mỗi case
D.Thời gian developer ước lượng cho phần code
Đáp án: B
Dựa trên phạm vi (bao nhiêu luồng, bao nhiêu tổ hợp), mức rủi ro (cần phủ sâu tới đâu), và dữ liệu lịch sử từ những hạng mục tương tự. Nhớ tính cả thời gian chuẩn bị dữ liệu, kiểm lại sau khi sửa, và chạy hồi quy.
Vai trò của QA khi review một yêu cầu (requirement) là gì?
A.Đánh giá yêu cầu có khả thi về mặt kỹ thuật không
B.Quyết định yêu cầu có đáng làm hay không
C.Viết lại yêu cầu cho đúng chuẩn tài liệu
D.Kiểm xem yêu cầu có kiểm chứng được không
Đáp án: D
Kiểm yêu cầu có kiểm chứng được không: có tiêu chí rõ để nói đúng hay sai, có nêu ca ngoại lệ, có nói gì về dữ liệu rỗng và giới hạn, có mâu thuẫn với yêu cầu khác không. Yêu cầu mơ hồ ở giai đoạn này là lỗi rẻ nhất để sửa.
Error guessing là kỹ thuật thiết kế test dựa trên gì?
A.Kinh nghiệm về những chỗ hệ thống hay hỏng
B.Phân tích cấu trúc mã nguồn của chức năng
C.Dữ liệu thống kê lỗi do công cụ tự sinh ra
D.Đặc tả yêu cầu chi tiết của chức năng
Đáp án: A
Dựa trên kinh nghiệm: những chỗ hệ thống này từng hỏng, những lỗi lập trình phổ biến, và trực giác về chỗ dễ sai. Thường triển khai bằng danh sách các ca đáng ngờ tích lũy dần qua dự án.
Ma trận truy vết (traceability matrix) dùng để làm gì?
A.Theo dõi ai đang thực thi test case nào
B.Ghi lại lịch sử thay đổi của từng test case
C.Nối yêu cầu với test case
D.Xếp thứ tự ưu tiên chạy các test case
Đáp án: C
Nối yêu cầu ↔ test case ↔ lỗi để trả lời hai câu: yêu cầu nào chưa có ca kiểm thử nào, và khi một yêu cầu thay đổi thì phải sửa những ca nào. Đây cũng là chứng cứ độ phủ khi làm dự án có kiểm toán.
Kiểm thử phần tiếng Việt của ứng dụng cần chú ý điều gì mà bản tiếng Anh không lộ ra?
A.Số lượng người dùng đồng thời hệ thống chịu được
B.Mức độ bảo mật của phiên đăng nhập
C.Dấu tiếng Việt khi sắp xếp và tìm kiếm
D.Tốc độ phản hồi của máy chủ khi đổi ngôn ngữ
Đáp án: C
Nhóm liên quan tới dấu tiếng Việt: sắp xếp danh sách tên, tìm kiếm không dấu có ra kết quả có dấu không, chuỗi dài hơn làm tràn layout, và cách nhập bằng bộ gõ có bị mất dấu khi ô nhập tự xử lý ký tự.
Kiểm thử khả năng tiếp cận (accessibility) ở mức cơ bản gồm những gì?
A.Kiểm bản dịch của giao diện có chính xác không
B.Kiểm ứng dụng chạy được trên trình duyệt cũ
C.Kiểm tốc độ tải trang trên thiết bị cấu hình thấp
D.Điều hướng bàn phím, tương phản và nhãn ảnh
Đáp án: D
Ba nhóm dễ kiểm và giá trị cao: điều hướng bằng bàn phím (tab đi hết được, thấy rõ ô đang chọn, không bị kẹt), độ tương phản màu chữ, và nhãn thay thế cho ảnh cùng nhãn cho ô nhập để trình đọc màn hình đọc được.
ISO/IEC 25010 dùng để làm gì trong kiểm thử phi chức năng?
A.Cung cấp danh sách đặc tính chất lượng
B.Chứng nhận chất lượng cho đội kiểm thử
C.Quy định định dạng bắt buộc của báo cáo kiểm thử
D.Quy định ngưỡng hiệu năng tối thiểu cho hệ thống
Đáp án: A
Dùng như danh sách đặc tính chất lượng để rà khi lập kế hoạch: hiệu năng, tính bảo mật, tính tin cậy, tính khả dụng, tính tương thích, tính bảo trì, tính khả chuyển và tính phù hợp chức năng. Mục đích là không bỏ sót nhóm nào.
Kiểm thử chức năng phân quyền theo vai trò nên bắt đầu từ đâu?
A.Đăng nhập từng vai trò và xem giao diện hiển thị gì
B.Lập ma trận vai trò và kiểm cả ô bị cấm
C.Hỏi developer những vai trò nào đã được xử lý
D.Đọc mã nguồn phần kiểm tra quyền của hệ thống
Đáp án: B
Lập ma trận vai trò × hành động, đánh dấu ô được phép và ô bị cấm, rồi kiểm cả hai loại ô — đặc biệt là gọi thẳng API cho ô bị cấm. Rất nhiều hệ thống chỉ ẩn nút trên giao diện mà không chặn ở phía máy chủ.
Chạy tự động ở mỗi lần gộp mã với bộ nhanh (smoke và các luồng chính), kèm bộ đầy đủ chạy theo lịch hằng đêm. Càng phát hiện gần thời điểm gây lỗi thì càng dễ truy nguyên nhân.
Để chạy được riêng lẻ và song song, và để một case hỏng không kéo theo hàng loạt case báo đỏ giả. Case phụ thuộc dây chuyền khiến kết quả phụ thuộc thứ tự chạy, và việc truy nguyên nhân trở nên rất tốn công.
Báo cáo kết quả kiểm thử hiệu năng nên dùng chỉ số nào là chính?
A.Tổng số yêu cầu đã gửi trong phiên kiểm thử
B.Thời gian phản hồi trung bình của toàn bộ yêu cầu
C.Thời gian phản hồi theo phân vị (p95, p99)
D.Thời gian phản hồi nhanh nhất ghi nhận được
Đáp án: C
Dùng phân vị (p95, p99) kèm tỉ lệ lỗi và thông lượng. Trung bình che mất phần đuôi: trung bình 200 mili giây trông rất ổn trong khi 5% người dùng chờ hơn ba giây — và đó thường là nhóm có nhiều dữ liệu nhất.
Bug bị mở lại nhiều lần sau khi developer báo đã sửa. Nguyên nhân thường gặp nhất là gì?
A.Hai bên hiểu khác nhau về hành vi đúng
B.Môi trường kiểm thử chưa cập nhật bản build mới
C.Tester chạy lại sai ca kiểm thử ban đầu
D.Developer sửa cẩu thả nên không hết lỗi
Đáp án: A
Thường là khác biệt về cách hiểu hành vi đúng: báo cáo mô tả triệu chứng nhưng không nói rõ kết quả mong đợi, nên developer sửa theo cách hiểu của họ còn tester kiểm theo cách hiểu của mình.
Kiểm thử kết hợp cặp (pairwise) giải quyết vấn đề gì?
A.Kết quả kiểm thử khác nhau giữa các môi trường
B.Ca kiểm thử phụ thuộc lẫn nhau về thứ tự chạy
C.Dữ liệu kiểm thử khó chuẩn bị cho từng ca
D.Số tổ hợp tham số quá lớn, không thử hết được
Đáp án: D
Khi có nhiều tham số, số tổ hợp tăng theo tích và không thể thử hết. Kỹ thuật này chọn một tập ca phủ mọi cặp giá trị của mọi cặp tham số — nhỏ hơn rất nhiều so với phủ toàn bộ, mà theo nhiều khảo sát vẫn bắt được phần lớn lỗi tổ hợp.
Vòng đời của một lỗi nên có những trạng thái nào là tối thiểu?
A.Trạng thái nên do từng người tự đặt theo cách của mình
B.Mỗi mức nghiêm trọng nên có một chuỗi trạng thái riêng
C.Chỉ cần hai trạng thái là đang mở và đã đóng
D.Mới, đang sửa, chờ kiểm lại, đã đóng, từ chối
Đáp án: D
Tối thiểu: mới → đang sửa → chờ kiểm lại → đã đóng, kèm nhánh từ chối cho báo cáo không phải lỗi hoặc trùng. Điểm quan trọng là mỗi trạng thái có một người chịu trách nhiệm rõ ràng để lỗi không nằm im vì không ai biết đến lượt mình.
Phát hiện một lỗi có vẻ trùng với lỗi đã báo trước đó. Nên làm gì?
A.Đóng lỗi mới ngay vì đã có người báo trước
B.Báo lỗi mới độc lập để không bỏ sót
C.Đối chiếu trước, nếu trùng thì liên kết và bổ sung
D.Chờ developer quyết định có trùng hay không
Đáp án: C
Đối chiếu trước khi kết luận trùng: cùng triệu chứng chưa chắc cùng nguyên nhân. Nếu đúng là trùng thì liên kết hai báo cáo và bổ sung thông tin mới vào lỗi gốc — các bước tái hiện khác, môi trường khác — vì chúng giúp việc chẩn đoán nhanh hơn.
Buổi phân loại lỗi (bug triage) nên đưa ra quyết định gì?
A.Mức ưu tiên, người xử lý, thời điểm dự kiến
B.Cách sửa cụ thể cho từng lỗi được báo
C.Ai chịu trách nhiệm về việc để lỗi lọt ra
D.Nguyên nhân kỹ thuật của từng lỗi
Đáp án: A
Ba quyết định: mức ưu tiên (sửa ngay, sửa trong đợt này, hay hoãn), người xử lý, và thời điểm dự kiến. Buổi này quyết định thứ tự làm việc, không phải nơi thảo luận nguyên nhân kỹ thuật — việc đó tốn thời gian của những người không liên quan.
Chọn tập ca kiểm thử hồi quy cho một đợt phát hành nên dựa vào gì?
A.Các ca kiểm thử được viết gần đây nhất
B.Các ca đã từng phát hiện lỗi trong quá khứ
C.Vùng thay đổi, vùng phụ thuộc, luồng quan trọng
D.Toàn bộ ca kiểm thử đã có, không loại trừ ca nào
Đáp án: C
Ba nhóm: vùng bị thay đổi trực tiếp; vùng phụ thuộc vào phần đã đổi — cần hỏi lập trình viên để xác định; và các luồng quan trọng nhất dù không liên quan tới thay đổi, vì đó là những thứ không được phép hỏng.
Báo cáo tổng kết kiểm thử gửi cho các bên liên quan nên chứa gì?
A.Danh sách đầy đủ các ca kiểm thử đã chạy
B.Chi tiết kỹ thuật của từng lỗi đã báo
C.Phạm vi đã kiểm, rủi ro còn lại, khuyến nghị
D.Số lượng lỗi tìm được của từng thành viên
Đáp án: C
Ba phần quan trọng nhất: phạm vi đã kiểm và chưa kiểm; rủi ro còn lại kèm mức tác động nếu xảy ra; và khuyến nghị phát hành hay chưa. Người đọc cần cơ sở để quyết định, không cần danh sách ca kiểm thử.
Chỉ số mật độ lỗi (defect density) được dùng để làm gì?
A.Quyết định thời điểm dừng kiểm thử
B.Đánh giá năng lực của từng lập trình viên
C.Dự đoán chính xác số lỗi còn lại trong sản phẩm
D.So mức độ lỗi giữa các mô-đun để tập trung nguồn lực
Đáp án: D
Dùng để so sánh giữa các mô-đun: số lỗi chia cho quy mô cho biết vùng nào đang có nhiều vấn đề hơn mức bình thường, từ đó tập trung kiểm thử và review nhiều hơn ở đó. Không dùng để đánh giá cá nhân, vì làm vậy tạo động cơ che giấu lỗi.
Review ca kiểm thử của người khác nên tập trung vào điều gì?
A.Số lượng ca kiểm thử có đủ chỉ tiêu không
B.Cách hành văn và định dạng của mô tả
C.Trường hợp bị thiếu và kết quả mong đợi có rõ không
D.Thời gian ước lượng chạy từng ca
Đáp án: C
Hai điều: trường hợp bị thiếu — nhánh lỗi, giá trị biên, tình huống người dùng thật hay gặp; và kết quả mong đợi có rõ ràng không — một ca ghi "hệ thống hoạt động đúng" thì hai người chạy sẽ kết luận khác nhau.
QA đọc một yêu cầu nghiệp vụ. Câu hỏi nào có giá trị nhất để phát hiện thiếu sót?
A.Điều gì xảy ra ở các tình huống không thuận lợi
B.Ai là người đề xuất tính năng này
C.Tính năng này dự kiến hoàn thành khi nào
D.Tính năng này sẽ được xây dựng bằng công nghệ nào
Đáp án: A
Hỏi về nhánh không thuận lợi: nếu thao tác thất bại thì sao, nếu dữ liệu rỗng thì hiển thị gì, nếu người dùng không có quyền thì thấy gì, nếu làm hai lần thì sao. Yêu cầu hầu như luôn mô tả kỹ đường đi thuận lợi và bỏ trống phần còn lại.
Tiêu chí chấp nhận (acceptance criteria) tốt cần đặc điểm gì?
A.Càng nhiều tiêu chí càng đầy đủ
B.Bao gồm ước lượng thời gian hoàn thành
C.Mô tả chi tiết cách hiện thực tính năng
D.Kiểm chứng được khách quan, không tuỳ cách hiểu
Đáp án: D
Quan trọng nhất là kiểm chứng được khách quan: hai người đọc phải cùng kết luận đã đạt hay chưa. "Trang tải nhanh" không dùng được; "trang hiển thị nội dung chính trong vòng hai giây trên mạng 4G" thì dùng được.
Tổ chức một đợt kiểm thử chấp nhận người dùng (UAT) cần chuẩn bị gì?
A.Kịch bản nghiệp vụ, dữ liệu thật, cách ghi phản hồi
B.Danh sách ca kiểm thử kỹ thuật chi tiết
C.Toàn bộ lỗi đã được sửa trước khi bắt đầu
D.Môi trường giống hệt production về hạ tầng
Đáp án: A
Ba thứ: kịch bản mô tả theo nghiệp vụ thay vì theo thao tác kỹ thuật; dữ liệu giống thực tế để người dùng nhận ra công việc của mình; và cách ghi nhận phản hồi rõ ràng để phân biệt lỗi thật với yêu cầu thay đổi.
Thực hành "ba bên cùng bàn" (three amigos) trước khi làm một hạng mục nhằm mục đích gì?
A.Phân chia công việc giữa ba vai trò
B.Thống nhất cách hiểu giữa ba vai trò trước khi làm
C.Quyết định giải pháp kỹ thuật sẽ dùng
D.Ước lượng thời gian hoàn thành chính xác hơn
Đáp án: B
Để thống nhất cách hiểu trước khi bắt đầu: người nghiệp vụ nói cần gì, người lập trình nêu ràng buộc kỹ thuật, người kiểm thử hỏi về các nhánh chưa được mô tả. Ba góc nhìn phát hiện được các cách hiểu lệch nhau khi việc sửa còn rất rẻ.
Viết kịch bản kiểm thử bằng cú pháp hướng hành vi mang lại lợi ích gì?
A.Người không lập trình cũng đọc và góp ý được
B.Kịch bản chạy nhanh hơn kiểm thử viết bằng mã
C.Tự động sinh ca kiểm thử từ tài liệu yêu cầu
D.Không cần viết mã hiện thực cho từng bước
Đáp án: A
Lợi ích chính là người không lập trình đọc và góp ý được: kịch bản viết bằng ngôn ngữ nghiệp vụ trở thành tài liệu sống, nên người đặt yêu cầu xác nhận cách hiểu ngay trong đó. Đổi lại, phải duy trì thêm một lớp ánh xạ từ câu chữ sang mã.
Xây bộ kiểm thử API bằng công cụ như Postman nên tổ chức thế nào để dùng lâu dài?
A.Mỗi người tự giữ bộ sưu tập riêng trên máy mình
B.Ghi cứng địa chỉ và token vào từng request
C.Tách cấu hình môi trường và đưa bộ sưu tập vào kho mã
D.Gộp tất cả request vào một thư mục duy nhất
Đáp án: C
Hai việc quan trọng: tách cấu hình môi trường (địa chỉ, thông tin đăng nhập) khỏi các request để chạy được trên nhiều môi trường; và đưa bộ sưu tập vào kho mã để theo dõi thay đổi, review, và chạy được trong pipeline bằng công cụ dòng lệnh.
Kiểm thử các thông báo lỗi hiển thị cho người dùng nên chú ý điều gì?
A.Thông báo càng ngắn càng tốt trong mọi trường hợp
B.Nói rõ chuyện gì xảy ra và nên làm gì tiếp
C.Hiển thị mã lỗi kỹ thuật để tiện tra cứu
D.Dùng cùng một thông báo chung cho mọi loại lỗi
Đáp án: B
Thông báo tốt cho biết chuyện gì xảy ra và người dùng nên làm gì tiếp. "Đã có lỗi xảy ra" không giúp được gì; "Số thẻ không hợp lệ, vui lòng kiểm tra lại 16 chữ số" thì có. Cũng cần kiểm rằng thông báo không lộ thông tin kỹ thuật như tên bảng hay câu truy vấn.
Kiểm thử luồng thanh toán với môi trường thử nghiệm của cổng thanh toán nên phủ trường hợp nào trước?
A.Tốc độ xử lý của cổng thanh toán
B.Thanh toán thành công với nhiều loại thẻ khác nhau
C.Thanh toán thất bại, bị huỷ, và mất phản hồi
D.Giao diện hiển thị của trang thanh toán
Đáp án: C
Ưu tiên các nhánh không thành công: thẻ bị từ chối, người dùng huỷ giữa chừng, đóng trình duyệt sau khi trả tiền nhưng trước khi quay về, và webhook xác nhận không tới. Đây là nơi tiền và trạng thái đơn hàng dễ lệch nhau nhất.
Kiểm thử luồng xác thực bằng mã một lần (OTP) nên chú ý trường hợp nào?
A.Mã hết hạn, nhập sai nhiều lần, gửi lại liên tục
B.Giao diện của ô nhập mã trên các thiết bị
C.Tốc độ tin nhắn đến điện thoại người dùng
D.Độ dài của mã có phù hợp không
Đáp án: A
Ba nhóm: mã hết hạn thì bị từ chối; nhập sai nhiều lần thì bị khoá tạm thời chứ không cho thử vô hạn; và yêu cầu gửi lại liên tục bị giới hạn tần suất. Thêm nữa: mã đã dùng không dùng lại được, và mã của người này không dùng cho tài khoản khác.
Kiểm thử danh sách có phân trang và sắp xếp trên giao diện nên chú ý điều gì?
A.Đổi bộ lọc hoặc sắp xếp có về trang đầu không
B.Tốc độ tải của trang đầu tiên
C.Màu sắc của nút chuyển trang
D.Số bản ghi trên mỗi trang có đúng cấu hình không
Đáp án: A
Nhóm hay có lỗi nhất: đổi bộ lọc hoặc sắp xếp khi đang ở trang giữa. Nếu không đưa về trang đầu, người dùng thấy trang trống hoặc dữ liệu không khớp. Kèm theo: trang cuối không đầy, danh sách rỗng, và giá trị trùng khi sắp xếp.
Kiểm thử ứng dụng di động khi mạng chập chờn nên tập trung vào đâu?
A.Thao tác bị gián đoạn và trạng thái khi có mạng lại
B.Thông báo mất kết nối có hiển thị không
C.Tốc độ tải màn hình khi mạng yếu
D.Dung lượng dữ liệu ứng dụng tiêu thụ
Đáp án: A
Tập trung vào thao tác bị gián đoạn giữa chừng: mất mạng ngay sau khi bấm gửi. Người dùng không biết đã gửi được hay chưa, và nếu thử lại thì có tạo hai bản ghi không. Kèm theo là trạng thái sau khi có mạng lại — dữ liệu có được đồng bộ đúng không.
Kiểm thử một chức năng có nhiều vai trò người dùng khác nhau nên tổ chức thế nào?
A.Kiểm lần lượt từng vai trò trên toàn bộ chức năng
B.Kiểm bằng tài khoản có quyền cao nhất cho nhanh
C.Ma trận vai trò và hành động, kiểm cả trường hợp cấm
D.Chỉ kiểm các vai trò được dùng nhiều nhất
Đáp án: C
Lập ma trận vai trò và hành động, rồi kiểm cả hai chiều: vai trò có quyền thì làm được, vai trò không đủ quyền thì bị chặn. Chiều thứ hai quan trọng hơn vì lỗi phân quyền là lỗi thiếu kiểm tra chứ không phải kiểm tra sai.
Kiểm thử chức năng tìm kiếm của ứng dụng tiếng Việt nên phủ trường hợp nào?
A.Vị trí của ô tìm kiếm trên giao diện
B.Tốc độ trả kết quả với từ khoá dài
C.Tìm không dấu, chữ hoa thường, khoảng trắng thừa
D.Số lượng kết quả hiển thị trên mỗi trang
Đáp án: C
Ba nhóm quan trọng: tìm không dấu phải ra kết quả có dấu; chữ hoa chữ thường không ảnh hưởng; và khoảng trắng thừa ở đầu cuối được bỏ qua. Người dùng Việt Nam thường gõ không dấu cho nhanh, nên đây là trường hợp phổ biến nhất chứ không phải trường hợp biên.
Nhiều người cùng dùng một môi trường test và dữ liệu bị xung đột. Cách xử lý bền vững là gì?
A.Khôi phục dữ liệu về trạng thái ban đầu mỗi sáng
B.Thoả thuận lịch dùng môi trường theo giờ
C.Yêu cầu mọi người báo trước khi sửa dữ liệu chung
D.Mỗi người một bộ dữ liệu riêng, tự tạo và tự dọn
Đáp án: D
Mỗi người dùng bộ dữ liệu riêng — tài khoản riêng, dữ liệu riêng có tiền tố phân biệt — và tự tạo, tự dọn. Cách này loại bỏ nguyên nhân xung đột thay vì quản lý nó, và mở rộng được khi nhóm đông thêm.
Dịch vụ bên thứ ba chưa sẵn sàng nhưng cần kiểm thử tính năng phụ thuộc nó. Cách xử lý là gì?
A.Bỏ qua phần tích hợp và chỉ kiểm giao diện
B.Dùng bản giả lập theo đặc tả để kiểm phần của mình
C.Gọi thẳng vào môi trường production của bên thứ ba
D.Chờ tới khi dịch vụ sẵn sàng rồi mới kiểm
Đáp án: B
Dùng bản giả lập theo đúng đặc tả để kiểm toàn bộ phần logic phía mình ngay. Bản giả lập còn cho phép dựng các nhánh lỗi khó tái hiện với dịch vụ thật. Nhưng phải có một đợt kiểm với dịch vụ thật trước khi phát hành, vì đặc tả và thực tế thường lệch nhau.
Sau khi đổi cấu hình môi trường production, cần kiểm lại những gì?
A.Toàn bộ hệ thống như một đợt phát hành đầy đủ
B.Luồng phụ thuộc cấu hình đó và luồng chính
C.Không cần kiểm vì mã nguồn không thay đổi
D.Chỉ cần kiểm rằng cấu hình đã được áp dụng đúng
Đáp án: B
Kiểm các luồng phụ thuộc trực tiếp vào cấu hình đó cộng với luồng chính của hệ thống. Đổi cấu hình không đổi mã nên bộ test chạy trước đó không phát hiện được gì, trong khi nhiều sự cố nghiêm trọng bắt nguồn từ chính loại thay đổi này.
Kiểm thử chức năng xuất dữ liệu ra file cho người dùng tải về nên chú ý gì?
A.Vị trí nút tải xuống trên giao diện
B.Dữ liệu xuất khớp bộ lọc và mở được bình thường
C.Tên file có chứa dấu thời gian không
D.Thời gian tạo file với dữ liệu lớn
Đáp án: B
Hai nhóm chính: dữ liệu xuất có khớp bộ lọc và sắp xếp đang chọn không — lỗi phổ biến là xuất toàn bộ thay vì phần đang xem; và file mở được đúng bằng công cụ phổ biến, đặc biệt là ký tự tiếng Việt không bị lỗi.
