Đề Thi FE SWT301 SU25 Đại học FPT Có Đáp Án & Giải Thích Chi Tiết

 Đề thi FE SWT301 SU25 Đại học FPT kèm đáp án chi tiết, mẹo nhớ nhanh và mở rộng câu hỏi ôn thi hiệu quả

Thi xong môn Software Testing (SWT301) lần 1 tại Đại học FPT, chắc hẳn nhiều anh em sinh viên IT tụi mình đang trong tình trạng “50 sắc thái”: Người thì tiếc nuối vì thiếu xíu điểm qua môn, người thì qua rồi nhưng vẫn muốn "phục thù" một lần nữa cho điểm thật cao, "sang chảnh" hơn chút để nhìn đẹp cái bảng điểm sau này. Thấu hiểu tâm trạng vừa đau thương vừa quyết tâm ấy, hôm nay HieuDevs quyết định chia sẻ luôn bộ đề thi FE SWT301 SU25 Đại học FPT chính thức vừa rồi, kèm luôn đáp án SWT301 được mình giải thích cực kỳ chi tiết. Chưa hết, mình bonus thêm một loạt mẹo nhớ nhanh, tips vui nhộn đặc biệt dành riêng cho dân IT tụi mình, và mở rộng thêm các câu hỏi liên quan giúp anh em nắm thật vững kiến thức Software Testing trước khi bước vào phòng thi lần 2.

Dẫu bạn thuộc phe nào, "team thi lại lần nữa vì điểm cao hơn" hay "team thi lại vì... rớt", thì cũng hãy tạm gác lại quá khứ đau thương, bật ngay chế độ nghiêm túc, lấy giấy bút ra note lại kinh nghiệm thi FE quý báu từ HieuDevs nhé! Giờ thì cùng mình vào bài thôi nào anh em!

Đề thi FE SWT301 SU25 Đại học FPT lần 1 đầy đủ có đáp án

Bây giờ thì khỏi vòng vo nữa nhé anh em. Dưới đây là full bộ đề thi chính thức môn Software Testing (SWT301), kỳ SU25 Đại học FPT lần 1 vừa qua. Mình đã mất nguyên buổi để note lại kỹ càng từng câu hỏi và giải thích thật rõ ràng cho từng đáp án để các bạn tiện theo dõi.

Trước khi kéo xuống xem đáp án chi tiết và mẹo nhớ nhanh, anh em thử tự làm nhanh một lượt coi thử mình "nhớ được nhiêu, quên mất bao nhiêu", từ đó xác định rõ điểm mạnh, điểm yếu nha. Ai "auto qua môn" lần trước cũng đừng chủ quan nhé, thử thách lần này là nâng điểm cao hơn để bảng điểm FE đẹp hơn nữa nè!

Cùng bắt đầu thôi nào các tester tương lai!

Question 1:

When we test or review a product, what are we looking for?

A. We are looking for errors and fixing them.

B. We are looking for defects in the product and thus are critical of it.

C. We are looking for difference between the system and the requirement.

D. We are looking for the mistakes of the requirement.

Ý chính cần nhớ:

• Mục tiêu chính của kiểm thử phần mềm (Testing): So sánh sản phẩm thực tế với yêu cầu (Requirement) để tìm ra sự khác biệt (differences).
• Testing không phải chủ yếu để sửa lỗi, chỉ trích sản phẩm hoặc bắt lỗi yêu cầu.
• Đáp án chuẩn: C – Looking for difference between the system and the requirement.

Mẹo nhớ nhanh:

• Câu thần chú: Kiểm thử = So sánh Thực tế với Yêu cầu
• Các từ khóa cần chú ý:
• Compare, Difference, Requirement → thường là đáp án đúng.
• Fixing, Critical of it, Mistakes of requirement → gây nhiễu, không đúng định nghĩa mục tiêu chính của testing.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following statements best describes the purpose of testing?

   A. To prove that the software is bug-free.

   B. To verify whether the software meets its requirements and identify defects.

   C. To validate that all errors are fixed.

   D. To make sure users are satisfied.

   Đáp án: B (theo ISTQB Foundation Level Syllabus 2018, mục "Objectives of Testing").

2. What is the main purpose of software testing?

   A. To demonstrate that the software works perfectly.

   B. To find differences between expected and actual results.

   C. To guarantee zero defects in production.

   D. To ensure developers write better code.

   Đáp án: B (tham khảo: Software Testing Fundamentals – Purpose of Testing).

3. Which statement is true about testing and fixing defects?

   A. Testing should focus mainly on fixing defects.

   B. Testing should focus on detecting deviations from requirements, fixing is a separate activity.

   C. Testing ensures that all mistakes of requirements are corrected.

   D. Testing only proves correctness of code.

   Đáp án: B (tham khảo: TutorialsPoint – Software Testing Overview).

Question 2:

What does the term 'failure' mean in the context of testing?

A. A mistake made by a developer.

B. A defect in the software that is found during testing.

C. An incorrect behavior of the system in operation.

D. A missed requirement during design.

Ý chính cần nhớ:

• Failure = Hành vi không đúng (incorrect behavior) của hệ thống khi đang hoạt động, gây ra do defect (lỗi) trong phần mềm hoặc do điều kiện môi trường.
• Đáp án chuẩn: C – An incorrect behavior of the system in operation.
• (Nguồn: ISTQB Glossary, ISTQB FL Syllabus 2018, mục "Failure")

Mẹo nhớ nhanh:

• Câu thần chú: Failure = Lỗi biểu hiện ra khi chạy hệ thống.
• Mistake = lỗi của con người → thường không đúng đáp án.
• Defect found during testing = defect, chưa chắc gây failure.
• Missed requirement = lỗi tài liệu, không phải failure.

Mở rộng – Các câu hỏi tương tự:

1. Which option best describes the relationship between defect and failure?

   A defect may cause a failure, but not all defects lead to failures.

   (Nguồn: ISTQB Glossary)

2. Failure occurs when:

   A. A human makes a mistake.

   B. A defect is executed in a certain condition leading to incorrect behavior.

   Đáp án: B.

   (Nguồn: SoftwareTestingFundamentals – “Defect, Error, Failure”)

3. Which of the following is NOT a cause of failure?

   A. Defects in code.

   B. Environmental conditions.

   C. Human error during operation.

   D. Testing process itself.

   Đáp án: D.

   (Nguồn: TutorialsPoint – Software Testing Basics)

Question 3:

Independent testing – who is a tester? Choose the correct sentence.

A. Tests by the person who wrote the item under test.

B. Tests by a person from a different organizational group, such as an independent test team.

C. Tests by another person within the same team, such as another programmer.

D. Tests by the person who wrote the source code.

Ý chính cần nhớ:

• Independent testing = kiểm thử được thực hiện bởi người hoặc nhóm khác biệt với nhóm phát triển để giảm thiên vị và tăng khách quan.
• Đáp án chuẩn: B – Tests by a person from a different organizational group.
• (Nguồn: ISTQB Syllabus 2018, Chương 1.4 "Independent Testing")

Mẹo nhớ nhanh:

• Câu thần chú: Independent = "Khác nhóm phát triển".
• Đáp án chứa Different organizational group gần như luôn đúng.

Mở rộng – Các câu hỏi tương tự:

1. Which of the following is an advantage of independent testing?

   Better detection of defects due to unbiased view.

   (Nguồn: ISTQB Foundation Level Sample Exam)

2. At which level is independent testing most beneficial?

   A. Unit testing.

   B. System testing and acceptance testing.

   Đáp án: B.

   (Nguồn: Guru99 – ISTQB Foundation MCQ)

3. Who can perform independent testing?

   External test team.

   QA team separate from developers.

   (Nguồn: TutorialsPoint – Independent Testing)

Question 4:

What is the significance of context in testing according to the principle?

A. It is irrelevant since all testing follows the same standard.

B. It is critical as testing approaches should vary based on the specific context.

C. It suggests that testing should always follow the same international standards.

D. Context is only important in large, complex systems.

Ý chính cần nhớ:

• Nguyên tắc kiểm thử: Testing is context dependent – cách kiểm thử cần thay đổi theo từng ngữ cảnh dự án, không có một phương pháp chung cho tất cả.
• Đáp án chuẩn: B – It is critical as testing approaches should vary based on the specific context.
• (Nguồn: ISTQB Syllabus 2018, Chương 1.3 "Seven Testing Principles")

Mẹo nhớ nhanh:

• Câu thần chú: Không có one-size-fits-all cho testing.
• Từ khóa: critical, vary based on context.

Mở rộng – Các câu hỏi tương tự:

1. Which principle states that there is no single universal approach to testing?

   Answer: Testing is context dependent.

   (Nguồn: ISTQB Principles of Testing)

2. Why can't we apply the same test process to all software projects?

   Because project type, risk, business domain, safety level vary.

   (Nguồn: TutorialsPoint – Principles of Testing)

3. Which factor does NOT affect context in testing?

   A. Business domain.

   B. Safety-critical nature.

   C. Time-to-market constraints.

   D. International testing standard.

   Đáp án: D.

   (Nguồn: SoftwareTestingFundamentals – Testing Principles)

Question 5:

Find the explanation of “Testing shows presence of defects”:

A. Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.

B. Testing concepts state that errors should be found as early as possible in the software or system development life cycle and should be based on defined objectives.

C. Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations.

D. Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.

Ý chính cần nhớ:

• Đây là Nguyên tắc số 2 trong 7 nguyên tắc kiểm thử (ISTQB): Testing shows presence of defects, not their absence – Testing giúp phát hiện các lỗi tồn tại, nhưng không thể chứng minh phần mềm hoàn toàn không có lỗi.
• Đáp án chuẩn: A – Testing can show that defects are present, but cannot prove that there are no defects.
• (Nguồn: ISTQB Syllabus 2018 – Principles of Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Testing = Chứng minh Có Lỗi, Không chứng minh Không Lỗi.
• Nếu câu trả lời chứa các từ khóa: cannot prove there are no defects, presence of defects, not a proof of correctness → chọn ngay.
• Các đáp án khác:
• B → Nguyên tắc "Early testing saves time and cost".
• C → Nguyên tắc "Absence-of-errors fallacy".
• D → Nguyên tắc "Testing is context dependent".

Mở rộng – Các câu hỏi tương tự:

1. Testing can only prove that software has defects, not that it is defect-free. Which principle is this?

   Answer: Testing shows presence of defects, not their absence.

   (Nguồn: ISTQB Foundation Level – 7 Principles of Testing)

2. Why can't testing guarantee that software is 100% defect-free?

   Because exhaustive testing is impossible, and testing only samples possible inputs and paths.

   (Nguồn: SoftwareTestingFundamentals – Testing Principles)

3. Which statement is TRUE about testing?

   A. Testing proves software correctness.

   B. Testing reduces risk but cannot eliminate it completely.

   Đáp án: B.

   (Nguồn: TutorialsPoint – Principles of Testing)

Question 6:

What types of defects are typically found more effectively during static testing than dynamic testing?

A. Performance-related defects

B. Defects in user interface design

C. Missing requirements or design defects

D. Runtime errors and exceptions

Ý chính cần nhớ:

• Static testing = kiểm tra phần mềm mà không cần chạy chương trình (ví dụ: Review tài liệu, Code inspection, Walkthrough).
• Static testing thường phát hiện tốt:
• Thiếu sót hoặc lỗi trong tài liệu yêu cầu.
• Lỗi trong thiết kế hoặc coding standard.
• Đáp án chuẩn: C – Missing requirements or design defects.
• (Nguồn: ISTQB Syllabus 2018 – Static Testing vs Dynamic Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Static = Lỗi trên giấy, Dynamic = Lỗi khi chạy.
• Từ khóa đúng trong câu hỏi: Missing requirements, Design defects → static test phát hiện tốt.
• Các lựa chọn còn lại:
• A và D → chỉ phát hiện khi chạy chương trình (dynamic).
• B → liên quan UI, thường test khi chạy thực tế.

Mở rộng – Các câu hỏi tương tự:

1. Which of the following is a benefit of static testing?

   Detect defects early before execution.

   (Nguồn: ISTQB Foundation Level – Static Techniques)

2. Which defect is LEAST likely to be found by static testing?

   A. Missing requirements.

   B. Incorrect algorithm implementation.

   Answer: B. (Cần chạy code mới thấy).

   (Nguồn: SoftwareTestingFundamentals)

3. What is a main advantage of static techniques over dynamic testing?

   They help detect defects early, reducing cost of fixing later in SDLC.

   (Nguồn: TutorialsPoint – Static Testing)

Question 7:

What is a key reason that software testing is necessary?

A. To increase software complexity

B. To identify defects in software

C. To reduce software features

D. To speed up software development

Ý chính cần nhớ:

• Mục tiêu chính của kiểm thử:
• Phát hiện và xác định lỗi (defects) trong phần mềm để đảm bảo chất lượng, giảm rủi ro khi phần mềm được đưa vào sử dụng.
• Testing không làm phần mềm phức tạp hơn, không giảm số lượng tính năng, và không trực tiếp tăng tốc phát triển (mặc dù phát hiện lỗi sớm có thể tiết kiệm thời gian).
• Đáp án chuẩn: B – To identify defects in software.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Why is Testing Necessary?)

Mẹo nhớ nhanh:

• Câu thần chú: Testing = Tìm lỗi trước khi người dùng gặp lỗi.
• Nhớ từ khóa trong đáp án đúng: Identify defects.
• Các lựa chọn còn lại:
• A → Không đúng, testing không tăng độ phức tạp.
• C → Testing không liên quan việc giảm tính năng.
• D → Testing không nhằm mục đích tăng tốc độ phát triển, dù có thể giúp tiết kiệm chi phí và thời gian gián tiếp.

Mở rộng – Các câu hỏi tương tự:

1. Main purpose of testing is:

   A. Prove that the software works correctly.

   B. Identify defects to improve quality and reduce risk.

   Answer: B.

   (Nguồn: ISTQB Glossary)

2. Why do we need software testing?

   To gain confidence in product quality, detect defects early, avoid costly failures after release.

   (Nguồn: Guru99 – Software Testing Basics)

3. Which is NOT an objective of testing?

   A. Prevent defects.

   B. Guarantee that software is 100% error-free.

   Answer: B.

   (Nguồn: TutorialsPoint – Testing Objectives)

Question 8:

How much testing is enough?

A. Exhaustive testing is possible.

B. Testing everything (all combinations of inputs and preconditions).

C. We use risks and priorities to focus testing efforts.

D. Full testing.

Ý chính cần nhớ:

• Nguyên lý kiểm thử: Không thể thực hiện kiểm thử toàn diện (exhaustive testing) vì số lượng trường hợp kiểm thử là vô hạn.
• Do đó, chúng ta sử dụng phân tích rủi ro (risk-based testing) và ưu tiên (prioritization) để quyết định mức độ kiểm thử cần thiết.
• Đáp án chuẩn: C – We use risks and priorities to focus testing efforts.
• (Nguồn: ISTQB Foundation Level Syllabus – Testing Principles, Principle 2: Exhaustive testing is impossible.)

Mẹo nhớ nhanh:

• Câu thần chú: Không thể test hết → Dùng rủi ro và ưu tiên để chọn.
• Khi gặp câu hỏi "how much testing is enough":
• Nhìn các từ khóa risk, priority → đáp án đúng.
• Các lựa chọn như exhaustive, full testing, everything → gây nhiễu, vì ISTQB khẳng định test toàn diện là không thể.

Mở rộng – Các câu hỏi tương tự:

1. Why is exhaustive testing not feasible?

   Vì có vô số tổ hợp dữ liệu, điều kiện đầu vào và đường dẫn chương trình.

   (Nguồn: Software Testing Help – Principles of Testing)

2. How do testers decide what to test first?

   Dựa vào risk analysis (tính nghiêm trọng + khả năng xảy ra lỗi).

   (Nguồn: Guru99 – Risk-based Testing)

3. Which principle states that it’s impossible to test everything?

   Principle 2: Exhaustive testing is impossible, testing must be prioritized.

   (Nguồn: ISTQB Foundation Level Glossary)

Question 9:

What is an effect of poor communication between testers and developers?

A. It enhances the efficiency of the development and testing processes.

B. It may lead to misunderstandings and reduced software quality.

C. It improves the independence of the testing function.

D. It has no effect as long as testing is done independently.

Ý chính cần nhớ:

• Giao tiếp kém giữa tester và developer gây ra:
• Hiểu sai yêu cầu hoặc lỗi bị bỏ sót.
• Thiếu thông tin quan trọng để tái tạo và sửa lỗi.
• Chất lượng phần mềm giảm, tăng chi phí sửa lỗi.
• Đáp án chuẩn: B – It may lead to misunderstandings and reduced software quality.
• (Nguồn: ISTQB Foundation Level Syllabus – The Psychology of Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Thiếu giao tiếp = Hiểu nhầm = Chất lượng kém.
• Khi thấy đáp án liên quan đến negative effect (misunderstanding, quality reduced) → chọn.
• Các đáp án kiểu enhances efficiency, improves independence, no effect chỉ gây nhiễu, không đúng với thực tế.

Mở rộng – Các câu hỏi tương tự:

1. What is the importance of communication in testing?

   Giao tiếp hiệu quả giúp chia sẻ thông tin lỗi nhanh, tránh hiểu sai yêu cầu, và cải thiện chất lượng phần mềm.

   (Nguồn: Guru99 – Psychology of Testing)

2. What can help improve tester–developer communication?

   Daily stand-up meetings (Scrum).

   Sử dụng các công cụ quản lý bug (JIRA, Bugzilla) với mô tả rõ ràng, tái tạo được lỗi.

   (Nguồn: ISTQB Glossary – Defect Lifecycle)

3. What is a risk of poor defect documentation?

   Developer không hiểu hoặc không thể tái tạo lỗi, dẫn đến lỗi tồn đọng.

   (Nguồn: Software Testing Help – Defect Reporting)

Question 10:

Which of the following strategies can help minimize psychological conflict between testers and developers? (Select all that apply)

A. Fostering mutual respect between roles.

B. Ensuring clear objectives for testing.

C. Feedback belittles the coder with errors found.

D. Encouraging collaboration on defect resolution.

Ý chính cần nhớ:

• Mục tiêu: Giảm thiểu xung đột tâm lý giữa tester và developer, xây dựng môi trường hợp tác tích cực và hiệu quả.
• Các yếu tố quan trọng:
• A – Mutual respect: Tôn trọng vai trò của nhau giúp tăng tinh thần làm việc nhóm.
• B – Clear objectives: Đặt mục tiêu rõ ràng cho testing để tránh hiểu nhầm và giảm tranh cãi.
• D – Collaboration: Khuyến khích hợp tác khi xử lý lỗi, tập trung giải quyết vấn đề thay vì đổ lỗi.
• C – Feedback tiêu cực (belittles) gây căng thẳng, giảm động lực làm việc và ảnh hưởng chất lượng phần mềm.
• Đáp án chuẩn: A, B, D.
• (Nguồn: ISTQB Foundation Level Syllabus – Psychology of Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Respect – Clear Goals – Work Together
• Nếu đáp án chứa Respect, Clear objectives, Collaboration → Chọn
• Nếu đáp án chứa Belittles, Criticism, Blame → Loại bỏ

Mở rộng – Câu hỏi liên quan:

1. Why are psychological factors important in software testing?

   A. They have no impact on software quality.

   B. Poor communication may lead to misunderstandings and reduced quality.

   C. Testing is only technical, psychology is irrelevant.

   D. Developers always accept tester feedback positively.

   Đáp án: B (Nguồn: Guru99 – Psychology of Testing)

2. How can test leaders reduce tester-developer conflicts?

   Bằng cách xây dựng văn hóa không đổ lỗi, khuyến khích giao tiếp tích cực, và đưa ra quy trình phản hồi chuyên nghiệp, tôn trọng.

   (Nguồn: Software Testing Help – Tester-Developer Relationship)

Question 11:

What should integration testing primarily focus on?

A. Testing the database and data processing.

B. Ensuring that software modules work together.

C. Checking that the system is ready for live deployment.

D. Evaluating user satisfaction with the product.

Ý chính cần nhớ:

• Integration Testing tập trung kiểm tra tương tác và giao tiếp giữa các module hoặc thành phần phần mềm.
• Mục tiêu: Đảm bảo các module hoạt động đúng khi kết nối với nhau, dữ liệu truyền đúng, xử lý chính xác.
• Không nhầm lẫn với:
• A: Database riêng lẻ → thuộc Unit/System Testing.
• C: Đánh giá trước triển khai → thuộc Acceptance Testing.
• D: Sự hài lòng người dùng → thuộc User Acceptance Testing (UAT).
• Đáp án chuẩn: B – Ensuring that software modules work together.
• (Nguồn: ISTQB Glossary)

Mẹo nhớ nhanh:

• Câu thần chú: Integration = Kiểm tra kết nối giữa các module.
• Từ khóa đúng thường xuất hiện: Modules work together, Interfaces, Interaction.
• Loại bỏ các đáp án liên quan đến database riêng lẻ, user satisfaction, hoặc deployment readiness.

Mở rộng – Câu hỏi liên quan:

1. Levels of Testing:

   • Unit: Kiểm tra từng module riêng lẻ.
   • Integration: Kiểm tra giao tiếp giữa các module.
   • System: Kiểm tra toàn bộ hệ thống end-to-end.
   • Acceptance: Kiểm tra hệ thống đáp ứng yêu cầu người dùng.

   (Nguồn: ISTQB Glossary)

2. Types of Integration Testing:

   • Big Bang
   • Top-down
   • Bottom-up
   • Hybrid (Sandwich)

   (Nguồn: Guru99 – Types of Integration Testing)

Question 12:

How does stress testing differ from load testing?

A. Stress testing examines system performance under peak loads, while load testing focuses on typical conditions.

B. Stress testing is concerned with usability under stress, while load testing measures performance thresholds.

C. Stress testing evaluates system behavior beyond normal operational capacity, while load testing verifies normal usage conditions.

Ý chính cần nhớ:

• Load Testing:
• Kiểm tra khả năng đáp ứng của hệ thống dưới tải bình thường hoặc tải dự kiến.
• Mục tiêu: Đảm bảo hệ thống hoạt động ổn định và đáp ứng đúng yêu cầu hiệu năng đã đề ra.
• Stress Testing:
• Kiểm tra hành vi của hệ thống khi tải vượt ngưỡng vận hành bình thường (quá tải).
• Mục tiêu: Xác định giới hạn chịu tải của hệ thống, quan sát lỗi tiềm ẩn và khả năng phục hồi sau sự cố.
• Đáp án chuẩn: C – Stress testing evaluates system behavior beyond normal operational capacity, while load testing verifies normal usage conditions.
• (Nguồn: ISTQB Foundation Level Syllabus 2018, mục Non-functional Testing)

Mẹo nhớ nhanh:

• Load = Bình thường (tải dự kiến).
• Stress = Quá tải (vượt khả năng vận hành).
• Nếu câu hỏi chứa cụm "beyond normal capacity", câu trả lời thường là Stress Testing.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following best defines stress testing?

   A. Testing the system under expected user load.

   B. Testing beyond normal operational capacity to identify breaking points.

   C. Testing response time under average conditions.

   D. Testing only hardware performance.

   Đáp án: B (Nguồn: ISTQB Foundation Level Syllabus 2018, mục Non-functional Testing).

2. Which type of performance testing focuses on determining the system’s behavior under expected conditions?

   A. Spike Testing

   B. Load Testing

   C. Stress Testing

   D. Endurance Testing

   Đáp án: B (Nguồn: TutorialsPoint – Performance Testing Types).

3. What is the primary goal of stress testing?

   A. To ensure the system performs optimally under normal workload.

   B. To guarantee zero failures.

   C. To find the point at which the system fails due to extreme workload.

   D. To improve user interface usability.

   Đáp án: C (Nguồn: Guru99 – Difference Between Load and Stress Testing).

Question 13:

What is the main advantage of using the V-model in software development?

A. It eliminates the need for testing.

B. It integrates testing throughout the development phases.

C. It is less costly and time-consuming compared to other models.

D. It focuses on post-development testing only.

Ý chính cần nhớ:

• V-Model là một mô hình phát triển phần mềm nhấn mạnh sự kết hợp kiểm thử trong từng giai đoạn phát triển (song song với mỗi hoạt động thiết kế).
• Mục tiêu chính: Phát hiện lỗi sớm, giảm thiểu chi phí sửa lỗi và rủi ro phát sinh do sai sót không được kiểm tra ngay từ đầu.
• Đáp án chuẩn: B – It integrates testing throughout the development phases.
• (Nguồn: ISTQB Foundation Level Syllabus – Software Development Models)

Mẹo nhớ nhanh:

• Câu thần chú: V-model = Verify + Validate song song với Dev
• Từ khóa cần chú ý:
• Integrates testing, throughout development, parallel with design → thường là đáp án đúng.
• Eliminates testing hoặc focus post-only → gây nhiễu, loại bỏ.

Mở rộng các câu hỏi cùng chủ đề:

1. What does each branch of the V-model represent?

   Left side: Các giai đoạn phát triển (Requirement, Design, Implementation).

   Right side: Các giai đoạn kiểm thử tương ứng (Unit, Integration, System, Acceptance Testing).

   Đáp án: Mô hình V thể hiện mối liên kết chặt chẽ giữa Dev và Test.

   (Nguồn: ISTQB, SoftwareTestingFundamentals)

2. What is the main benefit of early testing in the V-model?

   A. Reduce total cost of defect fixing.

   B. Testing can be skipped in early phases.

   C. Testing occurs only at the end of development.

   D. Improves developer productivity only.

   Đáp án: A – Vì lỗi được phát hiện càng sớm càng ít tốn chi phí và công sức sửa chữa (theo nguyên lý "Shift Left Testing").

   (Nguồn: ISTQB)

3. Which model emphasizes testing activities in parallel with development?

   A. Waterfall

   B. V-Model

   C. Spiral

   D. Big Bang

   Đáp án: B – V-Model.

   (Nguồn: ISTQB)

Question 14:

What is the purpose of unit testing in software development?

A. To test the entire system as a whole.

B. To test individual units or components in isolation.

C. To validate the software against user requirements.

D. To perform performance testing.

Ý chính cần nhớ:

• Unit Testing là mức kiểm thử thấp nhất trong quy trình kiểm thử phần mềm, tập trung vào kiểm tra từng đơn vị (unit) của phần mềm một cách độc lập (ví dụ: một hàm, một module hoặc một lớp).
• Mục tiêu chính:
• Xác minh rằng từng phần tử nhỏ nhất hoạt động đúng như thiết kế kỹ thuật (không phải toàn bộ hệ thống).
• Phát hiện lỗi sớm ở mức đơn vị, giảm chi phí sửa chữa khi phát triển.
• Đáp án chuẩn: B – To test individual units or components in isolation.
• (Nguồn: ISTQB Foundation Level Syllabus – Levels of Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Unit Testing = Test từng mảnh, từng đơn vị, độc lập
• Từ khóa thường xuất hiện trong đáp án đúng: Individual Units, Components, Isolation.
• Loại bỏ các lựa chọn gây nhiễu:
• A → Thuộc System Testing (kiểm tra toàn bộ hệ thống).
• C → Thuộc Acceptance Testing (kiểm tra yêu cầu người dùng).
• D → Thuộc Performance Testing (không phải Unit).

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is the main focus of unit testing?

   A. Testing interfaces between integrated modules.

   B. Testing individual functions or methods for correctness.

   C. Validating user stories end-to-end.

   D. Measuring system performance under load.

   Đáp án: B.

   (Nguồn: ISTQB, TutorialsPoint)

2. Who usually performs unit testing?

   A. End users.

   B. Independent testing team only.

   C. Developers (thường dùng framework hỗ trợ như JUnit, NUnit).

   D. Project managers.

   Đáp án: C – Unit testing thường do lập trình viên thực hiện ngay sau khi viết code.

   (Nguồn: ISTQB)

3. Which statement best describes unit testing?

   A. It is performed after system testing.

   B. It validates the smallest testable parts of the application.

   C. It ensures entire workflows meet user expectations.

   D. It requires actual production environment data.

   Đáp án: B.

   (Nguồn: ISTQB)

Question 15:

What is a characteristic of non-functional testing?

A. It is always performed after functional testing.

B. It focuses on how well the system performs certain actions.

C. It is concerned solely with what the system does.

D. It does not include performance testing.

Ý chính cần nhớ:

• Non-functional Testing tập trung vào chất lượng của hệ thống (How well), không chỉ là tính đúng đắn về chức năng (What).
• Mục tiêu chính:
• Đánh giá các thuộc tính như hiệu năng, khả năng mở rộng, bảo mật, tính khả dụng, độ tin cậy, khả năng chịu tải, v.v.
• Khác với Functional Testing – chỉ kiểm tra hệ thống có làm đúng chức năng yêu cầu hay không.
• Đáp án chuẩn: B – It focuses on how well the system performs certain actions.
• (Nguồn: ISTQB Foundation Level Syllabus – 2.4.2 Non-functional Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Non-functional = How well, Functional = What
• Từ khóa xuất hiện trong đáp án đúng: How well, Performance, Quality attributes.
• Loại bỏ các lựa chọn gây nhiễu:
• A: Non-functional testing có thể thực hiện song song hoặc sau functional testing, không bắt buộc luôn sau.
• C: Đây là functional testing (What system does).
• D: Ngược lại, performance testing là một phần của non-functional testing, nên lựa chọn này sai.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is NOT an example of non-functional testing?

   A. Load testing

   B. Stress testing

   C. Security testing

   D. Unit testing

   Đáp án: D (Unit testing là functional testing).

   (Nguồn: ISTQB, Guru99)

2. What types of attributes are evaluated during non-functional testing?

   A. Performance, Reliability, Usability, Scalability.

   B. Only correctness of functionality.

   Đáp án: A.

   (Nguồn: ISTQB)

3. Which testing ensures the system performs optimally under expected workloads?

   A. Functional testing

   B. Performance testing (thuộc Non-functional testing)

   C. System testing

   D. Unit testing

   Đáp án: B.

   (Nguồn: ISTQB)

Question 16:

What is not a test type?

A. Structural testing

B. Functional testing

C. Non-functional testing

D. Performance testing

E. Change-related testing

Ý chính cần nhớ:

• Theo định nghĩa ISTQB, có 4 loại test type chính:
1. Functional testing – kiểm tra chức năng của hệ thống (What the system does).
2. Non-functional testing – kiểm tra thuộc tính chất lượng (How well the system works).
3. Structural testing – kiểm tra cấu trúc bên trong (code, logic).
4. Change-related testing – bao gồm retesting và regression testing, thực hiện sau khi có thay đổi hoặc sửa lỗi.
• Performance testing không được xem là một “test type” độc lập trong phân loại chính thức, mà thuộc Non-functional testing.
• Đáp án chuẩn: D – Performance testing.
• (Nguồn: ISTQB Foundation Level Syllabus – 2.4 Test Types)

Mẹo nhớ nhanh:

• Câu thần chú: 4 loại chính: Functional – Non-functional – Structural – Change-related.
• Nếu gặp câu hỏi liệt kê, kiểm tra xem tùy chọn đó có nằm trong 4 nhóm này hay không.
• Performance testing = một phần của Non-functional, không phải test type riêng biệt.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is NOT a recognized test type in ISTQB Foundation syllabus?

   A. Structural testing

   B. Regression testing

   C. Performance testing

   D. Functional testing

   Đáp án: C.

   (Nguồn: ISTQB)

2. Regression testing belongs to which test type?

   A. Functional testing

   B. Change-related testing

   C. Structural testing

   D. Non-functional testing

   Đáp án: B.

   (Nguồn: ISTQB)

3. Which test type verifies system attributes like speed, scalability, and reliability?

   A. Functional testing

   B. Non-functional testing

   C. Structural testing

   D. Change-related testing

   Đáp án: B.

   (Nguồn: ISTQB)

Question 17:

What is the role of performance testing in system testing?

A. To verify that the system behaves correctly under load

B. To ensure that the system meets functional requirements

C. To check the accuracy of data processing

D. To confirm that the system is bug free

Ý chính cần nhớ:

• Performance testing là một dạng Non-functional testing, mục tiêu chính:
• Đánh giá hiệu suất của hệ thống dưới các điều kiện tải (load, stress).
• Đảm bảo hệ thống vẫn hoạt động ổn định, nhanh và đáp ứng yêu cầu về thời gian xử lý khi có nhiều người dùng đồng thời.
• Các lựa chọn khác không chính xác:
• B: Kiểm tra yêu cầu chức năng → thuộc Functional testing.
• C: Kiểm tra độ chính xác dữ liệu → liên quan đến Functional/Validation testing.
• D: Đảm bảo không có bug → không thể khẳng định hoàn toàn, không phải mục tiêu chính của performance testing.
• Đáp án chuẩn: A – To verify that the system behaves correctly under load.
• (Nguồn: ISTQB Foundation Level Syllabus – 2.4.2 Non-functional Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Performance = kiểm tra hệ thống khi chịu tải.
• Các từ khóa thường gặp: load, response time, scalability, stability.
• Không nhầm với functional testing hoặc bug-free claim.

Mở rộng – Các câu hỏi liên quan:

1. Which of the following is NOT part of performance testing?

   A. Load testing

   B. Stress testing

   C. Security testing

   D. Volume testing

   Đáp án: C (Security testing là dạng non-functional khác).

   (Nguồn: ISTQB)

2. What is the main goal of stress testing?

   A. To test beyond normal load conditions to observe system limits.

   B. To check functional accuracy under typical use.

   C. To find all functional defects.

   D. To verify usability.

   Đáp án: A.

   (Nguồn: ISTQB)

3. Performance testing focuses on which attributes?

   A. Speed, scalability, stability, response time.

   B. Functional correctness only.

   C. Accuracy of algorithms.

   D. User interface compatibility.

   Đáp án: A.

   (Nguồn: ISTQB)

Question 18:

What does the term "Big bang model" imply about the approach to software development?

A. Detailed and extensive planning.

B. Integration of all components at once without prior testing.

C. Regular testing from the beginning of the project.

D. User involvement is mandatory.

Ý chính cần nhớ:

• Big Bang Model là mô hình phát triển phần mềm trong đó tất cả các thành phần được tích hợp cùng lúc, và hầu như không có kế hoạch hoặc kiểm thử sớm trước khi ghép nối hệ thống.
• Mô hình này thường tiềm ẩn nhiều rủi ro vì lỗi chỉ được phát hiện muộn khi hệ thống được tích hợp hoàn chỉnh.
• Đáp án chuẩn: B – Integration of all components at once without prior testing.
• (Nguồn: ISTQB Foundation Level, Software Testing Fundamentals – Development Models)

Mẹo nhớ nhanh:

• Câu thần chú: Big Bang = Tích hợp tất cả một lần, ít hoặc không kiểm thử sớm.
• Từ khóa gợi nhớ: all at once, no prior testing, no planning → thường là dấu hiệu của Big Bang model.
• Loại bỏ các đáp án nói về planning hoặc regular testing vì trái ngược với bản chất của Big Bang.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is a major drawback of Big Bang model?

   A. Requires heavy documentation.

   B. Defects are found late, making them expensive to fix.

   C. Needs constant user involvement.

   D. It guarantees zero defects.

   Đáp án: B – Lỗi xuất hiện muộn sau khi tích hợp toàn bộ.

   (Nguồn: TutorialsPoint, Guru99, ISTQB)

2. In Big Bang model, when is testing typically started?

   A. From the very first coding activity.

   B. After all modules are developed and integrated.

   C. After each unit is completed.

   D. Continuously in parallel with development.

   Đáp án: B – Testing thường diễn ra muộn sau khi tất cả module được tích hợp.

   (Nguồn: TutorialsPoint)

3. What kind of project is sometimes suitable for Big Bang model?

   A. Large, critical systems with strict requirements.

   B. Small projects or academic experiments with unclear requirements.

   C. Projects requiring continuous delivery.

   D. Safety-critical real-time software.

   Đáp án: B – Vì Big Bang chỉ phù hợp khi quy mô nhỏ, yêu cầu không rõ ràng và rủi ro thấp.

   (Nguồn: Guru99)

Question 19:

What is the typical sequence of testing activities in the Waterfall model?

A. System testing, integration testing, acceptance testing.

B. Acceptance testing, system testing, integration testing.

C. Integration testing, system testing, acceptance testing.

D. Component testing, system testing, integration testing.

Ý chính cần nhớ:

• Mô hình Waterfall là quá trình phát triển phần mềm tuần tự, trong đó hoạt động kiểm thử cũng theo một trình tự rõ ràng từ mức thấp đến mức cao.
• Thứ tự kiểm thử điển hình: Integration Testing → System Testing → Acceptance Testing.
• Đáp án chuẩn: C – Integration testing, system testing, acceptance testing.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Software Development Life Cycle Models)

Mẹo nhớ nhanh:

• Câu thần chú: Tích hợp → Hệ thống → Chấp nhận (Integration → System → Acceptance).
• Từ khóa gợi nhớ:
• Integration = kiểm tra sự kết nối giữa các module.
• System = kiểm thử toàn bộ hệ thống.
• Acceptance = kiểm thử do khách hàng/người dùng thực hiện trước khi bàn giao.

Mở rộng các câu hỏi cùng chủ đề:

1. Which level of testing is performed first after individual units are completed?

   A. System testing.

   B. Integration testing.

   C. Acceptance testing.

   D. Regression testing.

   Đáp án: B – Vì cần kiểm thử cách các module hoạt động cùng nhau trước khi kiểm thử toàn hệ thống.

   (Nguồn: ISTQB)

2. In the Waterfall model, which testing level is primarily conducted by end-users or clients?

   A. Unit testing.

   B. System testing.

   C. Acceptance testing.

   D. Integration testing.

   Đáp án: C – Acceptance testing được khách hàng thực hiện để xác nhận sản phẩm đáp ứng yêu cầu.

   (Nguồn: ISTQB)

3. Which testing level verifies that the entire software meets the specified requirements?

   A. Unit testing.

   B. System testing.

   C. Integration testing.

   D. Component testing.

   Đáp án: B – System testing kiểm tra toàn bộ hệ thống dựa trên yêu cầu định nghĩa ban đầu.

   (Nguồn: ISTQB)

Question 20:

In which testing level would you test for defects in the interfaces and interaction between integrated components?

A. Component testing

B. Integration testing

C. System testing

D. Acceptance testing

Ý chính cần nhớ:

• Mục tiêu của Integration Testing là kiểm tra sự kết nối (interfaces) và tương tác giữa các module hay thành phần đã được tích hợp.
• Component testing chỉ kiểm tra từng đơn vị (unit/module) độc lập, chưa kiểm tra sự kết nối.
• System testing và Acceptance testing kiểm tra toàn hệ thống hoặc mức người dùng cuối, không đi sâu vào giao diện giữa các module.
• Đáp án chuẩn: B – Integration testing.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Testing Levels)

Mẹo nhớ nhanh:

• Câu thần chú: Integration = Interface (Kiểm thử tích hợp = Kiểm thử giao diện giữa các module).
• Từ khóa quan trọng: interface, interaction, components → chính là phạm vi của Integration testing.

Mở rộng các câu hỏi cùng chủ đề:

1. What is the main focus of Integration testing?

   A. To verify individual units are working correctly.

   B. To ensure modules or components work together as intended.

   C. To validate the software meets all requirements.

   D. To test usability for end-users.

   Đáp án: B – Integration testing kiểm tra sự phối hợp giữa các module.

   (Nguồn: TutorialsPoint, Guru99, ISTQB)

2. At which level are interface defects most likely to be found?

   A. Component level.

   B. Integration level.

   C. System level.

   D. Acceptance level.

   Đáp án: B – Vì các lỗi giao tiếp giữa module chỉ xuất hiện khi tích hợp.

   (Nguồn: ISTQB)

3. Which testing level comes immediately after unit testing in a typical SDLC?

   A. System testing.

   B. Integration testing.

   C. Acceptance testing.

   D. Regression testing.

   Đáp án: B – Sau khi kiểm thử đơn vị, ta kết hợp các module và kiểm thử tích hợp.

   (Nguồn: ISTQB)

Question 21:

What is dynamic testing?

A. Software work products are examined manually, or with a set of tools, but not executed.

B. Software is executed using a set of input values and its output is then examined and compared to what is expected.

C. Testing can start early in the life cycle, early feedback on quality issues can be established.

D. Testing can start early validation of user requirements and not just late in the life cycle during acceptance testing.

Ý chính cần nhớ:

• Dynamic Testing là phương pháp kiểm thử trong đó phần mềm được thực thi (executed) với dữ liệu đầu vào và kết quả thực tế được so sánh với kết quả mong đợi.
• Ngược lại, Static Testing (đáp án A) là kiểm tra sản phẩm công việc (work products) mà không chạy chương trình (ví dụ: review, walkthrough).
• Đáp án chuẩn: B – Software is executed using a set of input values and its output is then examined and compared to what is expected.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static and Dynamic Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Dynamic = Execute (Kiểm thử động = Chạy chương trình).
• Từ khóa quan trọng: executed, input values, output compared → luôn gắn với dynamic testing.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is NOT an example of dynamic testing?

   A. Code walkthrough.

   B. Functional testing.

   C. Integration testing.

   D. System testing.

   Đáp án: A – Walkthrough là static testing vì không chạy phần mềm.

   (Nguồn: TutorialsPoint, SoftwareTestingFundamentals)

2. What is the key difference between static and dynamic testing?

   A. Static testing detects defects by executing the code.

   B. Dynamic testing reviews documents manually.

   C. Static testing checks without execution, dynamic testing requires execution of code.

   D. Both are executed with test data.

   Đáp án: C – Phân biệt dựa vào việc có chạy phần mềm hay không.

   (Nguồn: TutorialsPoint)

3. Which testing types are considered dynamic testing?

   A. Unit testing, Integration testing, System testing.

   B. Reviews, Inspections, Walkthroughs.

   C. Code analysis, Document analysis.

   D. None of the above.

   Đáp án: A – Vì tất cả đều cần chạy phần mềm.

   (Nguồn: SoftwareTestingFundamentals)

Question 22:

Why are rules and checklists used during inspections?

A. To reduce the time spent on discussions.

B. To ensure consistency and thoroughness in defect identification.

C. To allow participants to avoid preparation.

D. To document defects for legal compliance.

Ý chính cần nhớ:

• Rules (quy tắc) và checklists (danh sách kiểm tra) trong quá trình inspection giúp đảm bảo tính nhất quán và đầy đủ (consistency & thoroughness) khi phát hiện lỗi.
• Mục tiêu là chuẩn hóa cách kiểm tra để không bỏ sót các loại lỗi tiềm ẩn và giảm sự phụ thuộc vào cảm tính cá nhân.
• Đáp án chuẩn: B – To ensure consistency and thoroughness in defect identification.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static Testing Techniques, Inspections)

Mẹo nhớ nhanh:

• Câu thần chú: Inspection = Systematic Check → phải có quy tắc và checklist để kiểm soát chất lượng quá trình.
• Từ khóa đúng: consistency, thoroughness, defect identification.
• Đáp án gây nhiễu:
• A (thời gian) chỉ là hiệu quả phụ, không phải mục đích chính.
• C (tránh chuẩn bị) hoàn toàn sai vì inspection yêu cầu chuẩn bị kỹ lưỡng.
• D (pháp lý) không phải mục tiêu chính của checklist.

Mở rộng các câu hỏi cùng chủ đề:

1. What is the main advantage of using checklists in inspections?

   A. Helps reviewers remember common defect types and ensures coverage.

   B. Saves time by skipping preparation.

   C. Only used for legal documentation.

   D. Reduces need for experienced reviewers.

   Đáp án: A – Checklists giúp tránh bỏ sót lỗi phổ biến.

   (Nguồn: TutorialsPoint)

2. Which activity is NOT part of the inspection process?

   A. Planning and preparation.

   B. Using rules and checklists to guide defect detection.

   C. Executing the software with test data.

   D. Recording found defects for later fixing.

   Đáp án: C – Inspection là static testing, không chạy phần mềm.

   (Nguồn: SoftwareTestingFundamentals)

3. What is the main benefit of formal inspections over informal reviews?

   A. Defect detection is more systematic and measurable thanks to rules, roles, and checklists.

   B. It takes less effort because preparation is not needed.

   C. It allows skipping documentation.

   D. It can replace all other test levels.

   Đáp án: A – Inspection có cấu trúc rõ ràng, hiệu quả hơn.

   (Nguồn: ISTQB)

Question 23:

Which of the following is most likely to be performed by developers?

A. Technical review of a functional specification.

B. Walkthrough of a requirements document.

C. Informal review of a program specification.

D. Static analysis of a software model.

Ý chính cần nhớ:

• Trong số các hoạt động được liệt kê, developer thường chịu trách nhiệm thực hiện static analysis (phân tích tĩnh) đối với mô hình phần mềm hoặc mã nguồn, vì đây là hoạt động kỹ thuật chuyên sâu, liên quan trực tiếp đến code và thiết kế phần mềm.
• Các hoạt động như walkthrough hay review tài liệu thường liên quan nhiều hơn đến BA, tester, hoặc stakeholder.
• Đáp án chuẩn: D – Static analysis of a software model.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static Testing Techniques, Static Analysis by Developers)

Mẹo nhớ nhanh:

• Ghi nhớ: Developer = Code-level tasks → Static analysis.
• Từ khóa đúng: static analysis, software model, code check.
• Đáp án nhiễu:
• A và B liên quan đến tài liệu yêu cầu, thường do BA và tester thực hiện.
• C là informal review, không yêu cầu chuyên sâu kỹ thuật và không đặc trưng của developer.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following static testing activities is typically performed by developers?

   A. Code walkthroughs and static analysis of code.

   B. Acceptance testing.

   C. Exploratory testing.

   D. User acceptance review.

   Đáp án: A – Static analysis, code walkthrough do developer thực hiện.

   (Nguồn: TutorialsPoint)

2. What is static analysis primarily used for?

   A. Detecting defects without executing the code.

   B. Running test cases on live environment.

   C. Validating user requirements via interviews.

   D. Confirming acceptance criteria with stakeholders.

   Đáp án: A – Static analysis giúp phát hiện lỗi sớm mà không chạy chương trình.

   (Nguồn: SoftwareTestingFundamentals)

3. Who usually performs static analysis?

   A. Developers using specialized tools to analyze source code.

   B. End-users before acceptance test.

   C. Project managers during planning phase.

   D. Clients reviewing requirement documents.

   Đáp án: A – Developer chịu trách nhiệm sử dụng tool phân tích tĩnh.

   (Nguồn: ISTQB)

Question 24:

What is a primary difference between static and dynamic testing techniques?

A. Static testing involves executing the code, while dynamic does not.

B. Static testing does not involve executing the code, while dynamic does.

C. Static testing is only performed by developers, while dynamic is not.

D. Static testing cannot find defects, while dynamic can.

Ý chính cần nhớ:

• Static testing là kỹ thuật kiểm thử không cần chạy phần mềm, thường dựa trên việc xem xét tài liệu, phân tích mã nguồn bằng công cụ hoặc review thủ công.
• Dynamic testing yêu cầu thực thi chương trình, chạy phần mềm để quan sát hành vi và tìm lỗi.
• Điểm khác biệt chính là việc thực thi (execution).
• Đáp án chuẩn: B – Static testing does not involve executing the code, while dynamic does.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static vs Dynamic Testing)

Mẹo nhớ nhanh:

• Ghi nhớ câu thần chú: Static = No run, Dynamic = Run.
• Các từ khóa chính: execution, running the code, analysis → giúp phân biệt rõ.
• Đáp án nhiễu:
• A sai vì đảo ngược khái niệm.
• C sai vì static testing không chỉ do developer làm (tester cũng tham gia review).
• D sai vì static testing vẫn phát hiện được lỗi logic, thiếu sót tài liệu, coding standard.

Mở rộng các câu hỏi cùng chủ đề:

1. Which testing activity does not require execution of code?

   A. Static testing.

   B. Dynamic testing.

   C. System testing.

   D. Regression testing.

   Đáp án: A – Static testing.

   (Nguồn: TutorialsPoint)

2. What are examples of static testing?

   A. Reviews, walkthroughs, static analysis of code.

   B. Unit testing and system testing.

   C. Exploratory testing.

   D. Acceptance testing.

   Đáp án: A – Static testing tập trung phân tích mà không chạy code.

   (Nguồn: SoftwareTestingFundamentals)

3. Which benefit does static testing provide early in the SDLC?

   A. Detects defects before execution, reducing cost of fixing them.

   B. Validates live system performance under load.

   C. Ensures data processing accuracy after deployment.

   D. Confirms user acceptance.

   Đáp án: A – Static testing phát hiện lỗi sớm, tiết kiệm chi phí.

   (Nguồn: ISTQB)

Question 25:

What types of defects are typically found more effectively during static testing than dynamic testing?

A. Performance-related defects

B. Defects in user interface design

C. Runtime errors and exceptions

D. Missing requirements or design defects

Ý chính cần nhớ:

• Static testing tập trung vào việc review tài liệu, phân tích thiết kế, code, yêu cầu mà không chạy phần mềm.
• Loại lỗi dễ tìm bằng static testing: thiếu yêu cầu, thiếu sót hoặc sai sót trong thiết kế, tài liệu → phát hiện sớm trước khi code chạy.
• Các lỗi liên quan runtime, performance, UI… thường chỉ thấy rõ khi thực thi chương trình (dynamic testing).
• Đáp án chuẩn: D – Missing requirements or design defects.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Benefits of Static Testing)

Mẹo nhớ nhanh:

• Ghi nhớ câu thần chú: Static = tìm lỗi sớm trên giấy, Dynamic = tìm lỗi khi chạy.
• Static testing phát hiện: requirement gaps, design flaws, coding standard violations.
• Distractors gây nhiễu:
• A: Performance cần chạy thực tế để đo lường.
• B: UI defects thường thấy khi chạy ứng dụng.
• C: Runtime errors chỉ xuất hiện khi code thực thi.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is NOT a typical benefit of static testing?

   A. Early detection of requirement defects.

   B. Reduced cost of fixing defects found late.

   C. Identification of runtime performance issues.

   D. Improved communication among team members.

   Đáp án: C – Vì runtime performance chỉ thấy khi chạy phần mềm.

   (Nguồn: ISTQB)

2. Static analysis can help detect which of the following?

   A. Dead code, uninitialized variables, coding standard violations.

   B. Memory leaks under stress conditions.

   C. Incorrect user interface alignment.

   D. Slow response time.

   Đáp án: A – Static analysis hỗ trợ phát hiện lỗi logic, cú pháp trước khi chạy.

   (Nguồn: SoftwareTestingFundamentals)

3. In static testing, which artifact is commonly reviewed to find missing requirements?

   A. Requirements specification.

   B. Test execution logs.

   C. Load test results.

   D. GUI screenshots.

   Đáp án: A – Đọc yêu cầu là cách chính để tìm thiếu sót trước khi code chạy.

   (Nguồn: TutorialsPoint)

Question 26:

How do reviews support software quality assurance?

A. By focusing solely on user needs

B. By providing a way to check compliance with standards

C. By testing software functionality through execution

D. By replacing the need for project management

Ý chính cần nhớ:

• Reviews (inspection, walkthrough, peer review) là một hoạt động static testing giúp đánh giá tài liệu, thiết kế, code mà không cần thực thi phần mềm.
• Mục tiêu chính: đảm bảo sản phẩm tuân thủ tiêu chuẩn, yêu cầu, hướng dẫn và quy trình chất lượng.
• Đáp án chuẩn: B – By providing a way to check compliance with standards.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Reviews and the Test Process)

Mẹo nhớ nhanh:

• Ghi nhớ câu thần chú: Review = Đọc để đảm bảo Chuẩn & Yêu cầu.
• Không bị nhầm lẫn:
• A: Chỉ tập trung vào nhu cầu người dùng chưa đủ cho QA.
• C: Thực thi phần mềm là dynamic testing, không phải review.
• D: Review không thể thay thế quản lý dự án.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is a main purpose of a technical review?

   A. To detect defects early by verifying compliance with standards and specifications.

   B. To measure system performance under high load.

   C. To validate user acceptance.

   D. To prioritize project tasks.

   Đáp án: A – Reviews tập trung vào việc phát hiện sai sót sớm và đảm bảo tuân thủ tiêu chuẩn.

   (Nguồn: ISTQB)

2. Which is NOT a benefit of reviews in software development?

   A. Early detection of requirement and design defects.

   B. Reduced cost of fixing late-stage defects.

   C. Eliminating the need for software execution.

   D. Guaranteeing zero defects in production.

   Đáp án: D – Reviews không thể đảm bảo phần mềm không còn lỗi hoàn toàn.

   (Nguồn: SoftwareTestingFundamentals)

3. Reviews are considered part of which type of testing?

   A. Static testing.

   B. Dynamic testing.

   C. Regression testing.

   D. Acceptance testing.

   Đáp án: A – Reviews thuộc nhóm kiểm thử tĩnh (static).

   (Nguồn: ISTQB)

Question 27:

How do technical reviews differ from informal reviews?

A. Technical reviews are less structured and more ad hoc

B. Technical reviews require the presence of software architects

C. Technical reviews are led by a trained moderator and follow a defined process

D. Informal reviews do not involve developers

Ý chính cần nhớ:

• Technical reviews là hoạt động kiểm tra tài liệu hoặc sản phẩm phần mềm có quy trình chính thức, được dẫn dắt bởi một moderator (điều phối viên) và thường liên quan đến các chuyên gia kỹ thuật để phát hiện lỗi và đánh giá tính khả thi kỹ thuật.
• Informal reviews ít cấu trúc hơn, thường không cần quy trình hoặc vai trò moderator rõ ràng.
• Đáp án chuẩn: C – Technical reviews are led by a trained moderator and follow a defined process.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static Testing Techniques)

Mẹo nhớ nhanh:

• Ghi nhớ: Technical review = Moderator + Quy trình chính thức.
• Các lựa chọn gây nhiễu:
• A: Đây là đặc điểm của informal reviews, không phải technical.
• B: Không bắt buộc phải có kiến trúc sư phần mềm trong mọi technical review.
• D: Informal reviews vẫn có thể có developers tham gia.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is NOT a characteristic of a technical review?

   A. Led by a moderator.

   B. Based on defined entry and exit criteria.

   C. Performed with clear roles and documented findings.

   D. Performed only by project managers without any structured approach.

   Đáp án: D – Một technical review luôn có quy trình và vai trò rõ ràng.

   (Nguồn: ISTQB)

2. What is a key difference between a walkthrough and a technical review?

   A. A walkthrough is less formal and often led by the author.

   B. A technical review is always informal.

   C. A walkthrough requires a moderator.

   D. A technical review focuses on training new testers.

   Đáp án: A – Walkthrough ít chính thức hơn và thường do chính tác giả dẫn dắt.

   (Nguồn: SoftwareTestingFundamentals)

3. Which review type is most structured among informal, walkthrough, and technical review?

   A. Informal review.

   B. Walkthrough.

   C. Technical review.

   D. None of the above.

   Đáp án: C – Technical review có quy trình, vai trò và tiêu chí rõ ràng nhất.

   (Nguồn: ISTQB)

Question 28:

Which of the following are the main activities of the work product review process?

1. Planning

2. Write review

3. Select reviewers

4. Individual review

5. Review meeting

6. Evaluating review findings against exit criteria

7. Issue communication and analysis

8. Fixing and reporting

A. 1,2,4,7,8

B. 2,3,5,6,8

C. 1,2,5,7

D. 1,4,6,7

Ý chính cần nhớ:

• Quy trình review sản phẩm phần mềm theo chuẩn ISTQB bao gồm 5 hoạt động chính:
1. Planning – Lên kế hoạch cho review (mục tiêu, phạm vi, tiêu chí).
2. Kick-off – (Tương tự "write review" trong một số mô tả) giới thiệu mục tiêu, hướng dẫn reviewer.
3. Individual review – Reviewer đọc và ghi chú lỗi độc lập.
4. Review meeting – Cuộc họp để thảo luận và thống nhất lỗi.
5. Fixing and reporting – Tác giả sửa lỗi và trưởng nhóm review tổng kết, báo cáo.
• Đáp án chuẩn: A – 1,2,4,7,8.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static Testing Techniques – Review Process)

Mẹo nhớ nhanh:

• Công thức: P–W–I–M–F = Planning – Write/kick-off – Individual review – Meeting – Fix/report.
• Các bước như “Select reviewers” hoặc “Evaluating findings vs exit criteria” là hoạt động hỗ trợ, không nằm trong main activities theo định nghĩa chuẩn ISTQB.

Mở rộng các câu hỏi cùng chủ đề:

1. Which role in a formal review is responsible for fixing defects?

   A. Moderator

   B. Author

   C. Reviewer

   D. Scribe

   Đáp án: B – Chỉ tác giả mới sửa được sản phẩm đã tạo ra.

   (Nguồn: ISTQB)

2. What is the main role of a moderator in a formal review?

   A. To fix defects.

   B. To lead the review process and ensure it follows the defined procedure.

   C. To approve the final version of the product.

   D. To write review reports.

   Đáp án: B – Moderator điều phối quy trình, không sửa sản phẩm.

   (Nguồn: ISTQB)

3. Which review type typically has a review meeting but may omit individual preparation?

   A. Walkthrough.

   B. Informal review.

   C. Technical review.

   D. Inspection.

   Đáp án: A – Walkthrough thường do tác giả trình bày, có họp nhưng không yêu cầu chuẩn bị cá nhân.

   (Nguồn: SoftwareTestingFundamentals)

Question 29:

What is a key feature of static analysis tools?

A. Executing the code

B. Checking coding standards

C. Testing system performance

D. Automating user feedback

Ý chính cần nhớ:

• Static Analysis Tools là các công cụ phân tích mã nguồn hoặc mô hình thiết kế phần mềm mà không cần chạy chương trình.
• Mục tiêu chính:
• Kiểm tra coding standards (quy tắc lập trình).
• Phát hiện lỗi tiềm ẩn, lỗ hổng bảo mật, vấn đề về maintainability trước khi chạy code.
• Đáp án chuẩn: B – Checking coding standards.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static Testing Techniques)

Mẹo nhớ nhanh:

• Hãy nhớ câu thần chú: Static = Không chạy code → kiểm tra chuẩn và lỗi tiềm ẩn.
• Các từ khóa cần chú ý:
• Without executing, Coding standards, Early detection → thường là đáp án đúng.
• Các lựa chọn liên quan đến executing code, performance testing, user feedback → thuộc về dynamic testing, không phải static.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is NOT a characteristic of static testing?

   A. It is performed without executing code.

   B. It can detect coding standard violations.

   C. It validates performance under load.

   D. It includes code reviews and walkthroughs.

   Đáp án: C (Performance testing cần chạy phần mềm → dynamic).

   (Nguồn: ISTQB)

2. What is an example of a static analysis tool function?

   A. Running unit tests to check logic errors.

   B. Checking unused variables or unreachable code.

   C. Measuring system response time under stress.

   D. Simulating user inputs in a GUI.

   Đáp án: B (Static analysis tìm lỗi tiềm ẩn mà không cần chạy code).

   (Nguồn: SoftwareTestingFundamentals)

3. Static testing is mainly performed to:

   A. Detect defects early in the development lifecycle.

   B. Execute the program and check results.

   C. Verify performance metrics under load.

   D. Collect user satisfaction feedback.

   Đáp án: A (giúp tiết kiệm chi phí sửa lỗi sớm).

   (Nguồn: TutorialsPoint)

Question 30:

What is static testing?

A. Software work products are examined manually, or with a set of tools, but not executed.

B. Software is executed using a set of input values and its output is then examined and compared to what is expected.

C. Simulation is applied as a technique to detect defects and to determine quality attributes of the code.

D. Testing can start after dynamic testing.

Ý chính cần nhớ:

• Static Testing là kỹ thuật kiểm tra phần mềm mà không thực thi chương trình (non-execution-based testing).
• Thường được áp dụng trên tài liệu đặc tả, thiết kế, mã nguồn, mô hình để phát hiện lỗi sớm, giảm chi phí sửa lỗi về sau.
• Phương pháp gồm: Review, Inspection, Walkthrough, Static Analysis Tools.
• Đáp án chuẩn: A – Examined manually or with tools, but not executed.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static Testing)

Mẹo nhớ nhanh:

• Ghi nhớ câu thần chú: Static = Không chạy code, chỉ đọc và phân tích.
• Các từ khóa cần chú ý:
• Not executed, Reviewed manually, Tools analysis → Đáp án đúng.
• Các lựa chọn liên quan executing, simulation, after dynamic testing → gây nhiễu.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is an example of static testing?

   A. Running automated regression tests.

   B. Performing code review and walkthroughs.

   C. Conducting load testing under peak conditions.

   D. Executing unit tests.

   Đáp án: B.

   (Nguồn: ISTQB)

2. Benefits of static testing include:

   A. Detecting defects early, before code execution.

   B. Reducing cost of fixing late defects.

   C. Enforcing coding standards.

   D. All of the above.

   Đáp án: D.

   (Nguồn: ISTQB)

3. Static analysis tools are used in static testing to:

   A. Simulate user behavior on the system.

   B. Measure performance under stress.

   C. Detect unused variables, syntax violations, unreachable code.

   D. Automate acceptance testing.

   Đáp án: C.

   (Nguồn: SoftwareTestingFundamentals)

Question 31:

What is the main purpose of specification-based testing techniques?

A. To evaluate the system's behavior from an external perspective.

B. To assess the internal structure of the software.

C. To improve the software design.

D. To test the software without any formal requirements.

Ý chính cần nhớ:

• Specification-based testing (Black-box testing) là kỹ thuật kiểm thử dựa trên đặc tả yêu cầu (specifications) của phần mềm, không cần biết chi tiết nội bộ (code).
• Mục tiêu chính là đánh giá hành vi (behavior) của hệ thống từ góc nhìn bên ngoài, dựa vào yêu cầu và đặc tả đã định.
• Đáp án chuẩn: A – Evaluate the system's behavior from an external perspective.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Nhớ câu: Specification = External behavior
• Các từ khóa quan trọng: External perspective, Requirements-based, Behavior → Đáp án đúng.
• Các đáp án gây nhiễu:
• B: Internal structure → liên quan White-box testing.
• C: Improve design → không phải mục tiêu kiểm thử.
• D: No requirements → trái ngược với specification-based.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is NOT a specification-based technique?

   A. Boundary value analysis

   B. Decision table testing

   C. Statement coverage testing

   D. Equivalence partitioning

   Đáp án: C – Statement coverage là white-box.

   (Nguồn: ISTQB)

2. Specification-based testing is also known as:

   A. Structural testing

   B. Black-box testing

   C. Experience-based testing

   D. Regression testing

   Đáp án: B

   (Nguồn: ISTQB)

3. The main input for specification-based testing techniques is:

   A. Source code

   B. Functional requirements, use cases, business rules

   C. Test harness and stubs

   D. Defect logs

   Đáp án: B

   (Nguồn: ISTQB)

Question 32:

Why is decision coverage important in white-box testing?

A. It measures the software's performance metrics.

B. It verifies the compatibility of new code with existing systems.

C. It focuses on the user interface aspects of the software.

D. It guarantees that all branches in decision points are executed.

Ý chính cần nhớ:

• Decision coverage (Branch coverage) là một kỹ thuật kiểm thử trong white-box testing nhằm đảm bảo mọi nhánh (true/false) của các câu lệnh điều kiện (if, switch...) đều được thực thi ít nhất một lần.
• Mục tiêu: Bao phủ tất cả các quyết định logic trong chương trình để giảm khả năng bỏ sót lỗi.
• Đáp án chuẩn: D – Guarantees that all branches in decision points are executed.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Nhớ câu: Decision coverage = Test all branches.
• Từ khóa quan trọng: All branches executed → Đáp án đúng.
• Các đáp án gây nhiễu:
• A: Performance → liên quan non-functional testing.
• B: Compatibility → không liên quan đến decision coverage.
• C: User interface → thuộc về functional/UI testing.

Mở rộng các câu hỏi cùng chủ đề:

1. What is the difference between statement coverage and decision coverage?

   A. Statement coverage ensures every line of code is executed, while decision coverage ensures every branch (true/false) is executed.

   B. They are identical metrics.

   C. Decision coverage is only used in black-box testing.

   D. Statement coverage is stronger than decision coverage.

   Đáp án: A

   (Nguồn: ISTQB)

2. Which is stronger: statement coverage or decision coverage?

   A. Statement coverage.

   B. Decision coverage.

   C. Both are equal.

   D. It depends on the number of test cases.

   Đáp án: B – Decision coverage bao phủ statement coverage nhưng không ngược lại.

   (Nguồn: ISTQB)

3. Decision coverage is mainly used to:

   A. Reduce test execution time.

   B. Increase code reliability by testing logical conditions.

   C. Evaluate software design quality.

   D. Detect UI inconsistencies.

   Đáp án: B

   (Nguồn: ISTQB)

Question 33:

Which scenario is ideal for using exploratory testing?

A. When there is limited time and no detailed specifications.

B. When detailed specifications are available.

C. When the software is fully stable.

D. When testing under controlled and stable conditions.

Ý chính cần nhớ:

• Exploratory testing là kỹ thuật kiểm thử dựa trên kinh nghiệm và sự sáng tạo của tester, không phụ thuộc nhiều vào tài liệu test case hoặc yêu cầu chi tiết.
• Thường áp dụng trong các tình huống:
• Thời gian hạn chế, cần kiểm tra nhanh.
• Thiếu tài liệu đặc tả, yêu cầu chưa rõ ràng.
• Đáp án chuẩn: A – When there is limited time and no detailed specifications.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Câu thần chú: Exploratory = Khám phá nhanh khi thiếu đặc tả.
• Từ khóa gợi ý: Limited time, No detailed specifications → Đúng.
• Các đáp án gây nhiễu:
• B, D: Detailed specs, Stable conditions → phù hợp với scripted testing.
• C: Fully stable → không phải điều kiện lý tưởng cho exploratory.

Mở rộng các câu hỏi cùng chủ đề:

1. Which statement best describes exploratory testing?

   A. It is a scripted testing technique based on written test cases.

   B. It relies on tester’s domain knowledge and simultaneous learning about the system.

   C. It only applies to performance testing.

   D. It ensures complete requirements coverage.

   Đáp án: B

   (Nguồn: ISTQB)

2. When is exploratory testing most useful?

   A. When time is limited, requirements are unclear or changing.

   B. When requirements are frozen and well-documented.

   C. During regression testing only.

   D. Only for user acceptance testing.

   Đáp án: A

   (Nguồn: ISTQB)

3. One of the key characteristics of exploratory testing is:

   A. It cannot detect defects missed by scripted tests.

   B. It combines test design and execution simultaneously.

   C. It replaces all formal testing.

   D. It is always automated.

   Đáp án: B

   (Nguồn: ISTQB)

Question 34:

For the password field (8–12 alphanumeric characters), which of the following is a valid boundary value?

A. 7 characters

B. 8 characters

C. 16 characters

D. 10 characters

Ý chính cần nhớ:

• Boundary Value Analysis (BVA) là kỹ thuật kiểm thử tập trung vào các giá trị tại biên (boundary) hoặc ngay sát biên của miền giá trị hợp lệ.
• Với trường hợp độ dài password hợp lệ: 8 – 12 ký tự:
• Các giá trị boundary là: 7 (dưới biên), 8 (biên dưới), 12 (biên trên), 13 (trên biên).
• Trong các lựa chọn, 8 characters là giá trị biên hợp lệ (valid boundary).
• Đáp án chuẩn: B – 8 characters.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Quy tắc BVA: Test các giá trị: (Min-1, Min, Max, Max+1).
• Ở đây: Min=8, Max=12.
• Giá trị valid boundary = giá trị bằng đúng biên hợp lệ, nên chọn 8.

Mở rộng các câu hỏi cùng chủ đề:

1. If a system accepts inputs 1–100, which are valid boundary values?

   A. 0, 1, 100, 101

   B. 1, 100

   C. 2, 99

   D. 0, 101 only

   Đáp án: A – Bao gồm cả dưới/ngoài và tại biên.

   (Nguồn: ISTQB)

2. Why is BVA effective in testing?

   A. Because errors often occur at extreme ends of input ranges.

   B. Because it ensures exhaustive testing of all inputs.

   C. Because it only checks valid inputs.

   D. Because it replaces equivalence partitioning.

   Đáp án: A

   (Nguồn: ISTQB)

3. In password field (min 6, max 12), which values should be tested for BVA?

   A. 5, 6, 12, 13

   B. 6, 12

   C. 7, 11

   D. 6, 10, 12

   Đáp án: A

   (Nguồn: ISTQB)

Question 35:

Which white box technique has the main goal of ensuring that each one of the possible branches from each decision point is executed at least once?

A. Path coverage testing

B. Statement coverage testing

C. Branch coverage testing

D. Condition coverage testing

Ý chính cần nhớ:

• White-box testing gồm nhiều kỹ thuật:
• Statement coverage: Đảm bảo mọi câu lệnh được chạy ít nhất một lần.
• Branch coverage: Đảm bảo mọi nhánh (true/false) từ mỗi điểm quyết định (decision point) đều được thực thi ít nhất một lần.
• Condition coverage: Kiểm tra tất cả các điều kiện boolean trong biểu thức logic đều có kết quả true/false.
• Path coverage: Bao phủ tất cả đường đi khả dĩ trong mã nguồn.
• Câu hỏi hỏi rõ each one of the possible branches from each decision point, đây chính là định nghĩa chuẩn của Branch Coverage Testing.
• Đáp án đúng: C – Branch coverage testing.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Statement = từng câu lệnh
• Branch = từng nhánh (if/else)
• Condition = từng điều kiện boolean
• Path = toàn bộ đường đi
• Khi thấy từ khóa branches from decision point → Branch Coverage.

Mở rộng các câu hỏi cùng chủ đề:

1. What is the minimum coverage level recommended for branch testing?

   A. 100% branch coverage

   B. 50% statement coverage

   C. 100% path coverage

   D. 50% decision coverage

   Đáp án: A

   (Nguồn: ISTQB)

2. Which statement is true about statement vs branch coverage?

   A. Branch coverage is stronger than statement coverage because it ensures execution of both true and false branches.

   B. Statement coverage guarantees branch coverage.

   C. Branch coverage does not include statement coverage.

   D. Both provide the same level of testing.

   Đáp án: A

   (Nguồn: ISTQB)

3. What does 100% branch coverage guarantee?

   A. Every possible outcome of each decision is executed at least once.

   B. Every line of code is executed at least once.

   C. All possible paths are executed.

   D. All individual boolean sub-conditions are tested true and false.

   Đáp án: A

   (Nguồn: ISTQB)

Question 36:

Which type of test design technique is based on the tester's skills, intuition, and experience in testing?

A. Black box testing

B. White box testing

C. Experience-based testing

D. Specification-based testing

Ý chính cần nhớ:

• Test design techniques thường được chia làm 3 nhóm chính (theo ISTQB):
1. Specification-based (Black-box): Dựa trên yêu cầu hoặc đặc tả phần mềm.
2. Structure-based (White-box): Dựa trên cấu trúc code và logic bên trong.
3. Experience-based: Dựa trên kinh nghiệm, trực giác, kỹ năng của tester, thường áp dụng khi thiếu tài liệu hoặc khi cần kiểm tra nhanh, khó dự đoán tất cả trường hợp.
• Câu hỏi nêu rõ based on the tester's skills, intuition, and experience, đây là định nghĩa chuẩn của Experience-based testing.
• Đáp án đúng: C – Experience-based testing.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Khi thấy intuition, skills, experience → Experience-based testing.
• Black-box và Specification-based dựa trên tài liệu yêu cầu, không dựa vào trực giác cá nhân.
• White-box dựa vào code, không liên quan đến kỹ năng cá nhân.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is NOT an example of experience-based testing?

   A. Exploratory testing

   B. Error guessing

   C. Checklist-based testing

   D. Boundary value analysis

   Đáp án: D – Boundary value analysis là specification-based.

   (Nguồn: ISTQB)

2. When is experience-based testing particularly useful?

   A. When there is limited documentation or time.

   B. When complete and detailed requirements are available.

   C. When automated tools are used.

   D. When code coverage is measured.

   Đáp án: A

   (Nguồn: ISTQB)

3. Which test design technique relies mainly on a tester’s background and past failures in similar projects?

   A. Equivalence partitioning

   B. Error guessing

   C. Decision table testing

   D. State transition testing

   Đáp án: B – Thuộc nhóm experience-based.

   (Nguồn: ISTQB)

Question 37:

Given the following pseudo-code, which is true about the minimum number of test cases required for full statement and branch coverage?

Read A
Read B
IF A+B > 50 THEN
    Print "Sum A and B"
    IF B > 10 THEN
        Print "B is greater than 10"
    ENDIF
ENDIF
  

A. 1 test case for statement coverage, 2 for branch coverage

B. 1 test case for statement coverage, 3 for branch coverage

C. 2 test cases for statement coverage, 2 for branch coverage

D. 2 test cases for statement coverage, 3 for branch coverage

Ý chính cần nhớ:

• Statement coverage: Mục tiêu là mỗi câu lệnh (statement) được thực thi ít nhất một lần.
• Branch coverage: Mục tiêu là mỗi điều kiện rẽ nhánh (True/False) trong chương trình được thực hiện ít nhất một lần.
• Phân tích đoạn code:
• Có 2 điều kiện IF:
1. A+B > 50 (True/False)
2. B > 10 (True/False, chỉ xét khi điều kiện 1 = True)
• Để bao phủ statement, cần:
• 1 test case: A+B ≤ 50 (chỉ đọc A, B).
• 1 test case: A+B > 50 và B > 10 (thực hiện tất cả các câu lệnh).
• → 2 test cases.
• Để bao phủ branch, cần:
• A+B ≤ 50 → Branch 1 = False.
• A+B > 50 và B ≤ 10 → Branch 1 = True, Branch 2 = False.
• A+B > 50 và B > 10 → Branch 1 = True, Branch 2 = True.
• → 3 test cases.
• Đáp án đúng: D – 2 test cases for statement coverage, 3 for branch coverage.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Statement coverage: Đảm bảo chạy ít nhất một lần mỗi câu lệnh.
• Branch coverage: Đảm bảo chạy cả True và False cho mọi điều kiện rẽ nhánh.
• Khi có lồng nhiều điều kiện (nested IF) → thường cần nhiều test case hơn cho branch coverage so với statement coverage.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is stronger, branch coverage or statement coverage?

   A. Branch coverage

   B. Statement coverage

   C. Chúng bằng nhau

   D. Không thể so sánh được

   Đáp án: A – Branch coverage bao phủ được statement coverage nhưng ngược lại thì không.

   (Nguồn: ISTQB)

2. What is the minimum number of test cases for full branch coverage of a simple IF statement (no ELSE)?

   A. 1

   B. 2

   C. 3

   D. 4

   Đáp án: B – Cần test cho cả điều kiện True và False.

   (Nguồn: ISTQB)

3. Which coverage metric requires every possible decision outcome to be executed at least once?

   A. Statement coverage

   B. Branch coverage

   C. Path coverage

   D. Condition coverage

   Đáp án: B – Branch coverage.

   (Nguồn: ISTQB)

Question 38:

What is the main purpose of use case testing?

A. To identify defects in process flows related to typical use of the system.

B. To identify defects in the connections between components.

C. To identify defects in the system related to extreme scenarios.

D. To identify defects in the system related to the use of unapproved programming practices.

Ý chính cần nhớ:

• Use case testing là kỹ thuật kiểm thử dựa trên các use case mô tả cách người dùng (actors) tương tác với hệ thống để đạt được một mục tiêu cụ thể.
• Mục tiêu chính:
• Đảm bảo rằng các luồng xử lý (process flows) thông thường của hệ thống (main flows và alternative flows) hoạt động chính xác theo yêu cầu.
• Xác định các lỗi hoặc thiếu sót xảy ra khi người dùng thực hiện các thao tác thực tế trên hệ thống.
• Đáp án đúng: A – To identify defects in process flows related to typical use of the system.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Khi thấy use case testing → luồng nghiệp vụ thực tế của người dùng.
• Dùng để xác minh các chức năng chính, kịch bản thường gặp, đảm bảo hệ thống hoạt động đúng như người dùng mong đợi.
• Không tập trung vào code, extreme cases, hay kết nối giữa component.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is true about use case testing?

   A. It is a specification-based testing technique.

   B. It is a structure-based testing technique.

   C. It is an experience-based testing technique.

   D. It is not suitable for functional testing.

   Đáp án: A – Use case testing dựa trên tài liệu đặc tả – specification-based.

   (Nguồn: ISTQB)

2. When is use case testing most effective?

   A. When there are well-defined functional requirements describing user interactions.

   B. When only the source code is available.

   C. When the system is being stress tested.

   D. When there are no end-user scenarios defined.

   Đáp án: A

   (Nguồn: ISTQB)

3. Use case testing helps ensure that:

   A. The user’s most common interactions with the system work as intended.

   B. The code structure is covered 100%.

   C. Performance metrics are met.

   D. Extreme negative conditions are handled properly.

   Đáp án: A

   (Nguồn: ISTQB)

Question 39:

Why is equivalence partitioning particularly effective in test case design?

A. It requires thorough knowledge of the internal structure of the system.

B. It divides input data into valid and invalid partitions to simplify testing.

C. It focuses solely on the output of the software.

D. It is the best method for performance testing.

Ý chính cần nhớ:

• Equivalence Partitioning (EP) là kỹ thuật kiểm thử thuộc nhóm specification-based (black-box testing).
• Mục đích của EP:
• Giảm số lượng test case cần thiết nhưng vẫn đảm bảo độ bao phủ cao.
• Chia tập dữ liệu đầu vào thành các phân vùng tương đương (equivalence classes):
• Valid partitions: Dữ liệu hợp lệ, hệ thống chấp nhận.
• Invalid partitions: Dữ liệu không hợp lệ, hệ thống phải xử lý lỗi đúng cách.
• Giả định rằng nếu một giá trị trong phân vùng hoạt động chính xác thì các giá trị khác trong cùng phân vùng cũng sẽ hoạt động chính xác.
• Đáp án đúng: B – It divides input data into valid and invalid partitions to simplify testing.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Khi thấy divide input data into partitions → Equivalence Partitioning.
• Giúp giảm test case, tránh trùng lặp, bao phủ nhiều tình huống đầu vào chỉ với ít dữ liệu đại diện.

Mở rộng các câu hỏi cùng chủ đề:

1. What is the primary goal of equivalence partitioning?

   A. To reduce the number of test cases while maintaining coverage.

   B. To ensure code statements are executed.

   C. To test system performance under load.

   D. To measure decision coverage.

   Đáp án: A

   (Nguồn: ISTQB)

2. Which is NOT an example of an equivalence partition for an age input field (1–120)?

   A. 0 (invalid)

   B. 25 (valid)

   C. 150 (invalid)

   D. 60–80 (range grouping)

   Đáp án: D – Phân vùng thường dùng giá trị đơn lẻ đại diện cho mỗi nhóm.

   (Nguồn: ISTQB)

3. What is the difference between equivalence partitioning and boundary value analysis?

   A. EP focuses on representative values from partitions, BVA focuses on limits of input ranges.

   B. EP is a white-box technique, BVA is black-box.

   C. EP is used for non-functional testing, BVA for functional testing.

   D. There is no difference.

   Đáp án: A

   (Nguồn: ISTQB)

Question 40:

Which of the following statement is true about the bug/defect report?

A. It is technical document written to describe the symptoms of a bug.

B. It is designed to prescribe the scope, approach, resources, and schedule of all testing activities.

C. It is a document that delivers a detailed summary of what scenarios will be tested in a software during the software testing life cycle (STLC).

D. It is used to confirm the function of the application when the code is executed.

Ý chính cần nhớ:

• Bug/Defect Report là tài liệu kỹ thuật mô tả chi tiết lỗi phần mềm, bao gồm:
• ID lỗi, tiêu đề lỗi, mô tả lỗi.
• Các bước tái hiện (steps to reproduce).
• Môi trường kiểm thử (test environment).
• Kết quả mong đợi (expected result) và kết quả thực tế (actual result).
• Mức độ nghiêm trọng (severity), độ ưu tiên (priority).
• Phân tích đáp án:
• A: Đúng – Đây là định nghĩa chuẩn về bug report.
• B: Sai – Đây là mô tả của Test Plan.
• C: Sai – Đây là mô tả của Test Specification/Test Scenario Document.
• D: Sai – Đây là mục tiêu của Functional Testing, không phải bug report.
• Đáp án đúng: A – It is technical document written to describe the symptoms of a bug.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Khi thấy bug report → nghĩ đến mô tả lỗi, bước tái hiện, kết quả mong đợi & thực tế.
• Nếu câu hỏi nói về kế hoạch, phạm vi, tài nguyên → đó là Test Plan.
• Nếu nói về scenarios hoặc test conditions → đó là Test Design/Specification.

Mở rộng các câu hỏi cùng chủ đề:

1. Which information is NOT typically included in a defect report?

   A. Test case ID.

   B. Expected result and actual result.

   C. Steps to reproduce.

   D. The code fix implemented by developer.

   Đáp án: D – Tester không ghi chi tiết code fix.

   (Nguồn: ISTQB)

2. Which is the main purpose of a defect report?

   A. To document the symptoms, severity, and reproduction steps of a defect to facilitate fixing.

   B. To define the test scope and objectives.

   C. To execute automated tests.

   D. To measure coverage of decision points.

   Đáp án: A

   (Nguồn: ISTQB)

3. Who is the primary audience of a bug report?

   A. Test manager.

   B. Developer and project team.

   C. End user.

   D. Project sponsor.

   Đáp án: B

   (Nguồn: ISTQB)

Question 41:

What role is responsible for leading the test effort?

A. Test manager

B. Test designer

C. Test analyst

D. Tester

Ý chính cần nhớ:

• Trong quy trình kiểm thử phần mềm, vai trò và trách nhiệm chính thường được phân chia như sau:
• Test Manager: Lập kế hoạch kiểm thử (Test Plan), quản lý và điều phối nguồn lực kiểm thử, giám sát tiến độ và chất lượng kiểm thử, chịu trách nhiệm tổng thể về hoạt động kiểm thử (test effort).
• Test Designer / Test Analyst: Tập trung thiết kế test cases, phân tích yêu cầu và tạo điều kiện kiểm thử.
• Tester: Thực hiện test cases, ghi nhận kết quả và báo cáo lỗi.
• Câu hỏi hỏi rõ “leading the test effort” → vai trò quản lý và lãnh đạo quá trình kiểm thử ⇒ Test Manager.
• Đáp án đúng: A – Test Manager
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Khi câu hỏi có các từ khóa lead / manage / responsible for planning & controlling → Test Manager.
• Khi nhấn mạnh viết test case, phân tích yêu cầu → Test Analyst / Test Designer.
• Khi nói thực hiện test cases → Tester.

Mở rộng các câu hỏi cùng chủ đề:

1. Who is responsible for preparing a detailed test schedule and allocating resources?

   A. Test manager

   B. Test analyst

   C. Developer

   D. Project sponsor

   Đáp án: A

   (Nguồn: ISTQB)

2. Who primarily designs test cases based on requirements and specifications?

   A. Test manager

   B. Test analyst

   C. Business analyst

   D. Product owner

   Đáp án: B

   (Nguồn: ISTQB)

3. Who executes tests and reports defects during test execution phase?

   A. Test manager

   B. Tester

   C. Test lead

   D. Project manager

   Đáp án: B

   (Nguồn: ISTQB)

Question 42:

What is NOT a goal of incident management?

A. Fixing all defects regardless of their impact

B. Improving the quality of the software product

C. Reducing the risk of future defects

D. Ensuring stakeholder satisfaction with the product

Ý chính cần nhớ:

• Mục tiêu chính của incident management (theo ISTQB):
1. Ghi nhận và phân loại tất cả các sự cố (incidents/defects).
2. Ưu tiên và xử lý dựa trên mức độ nghiêm trọng và ảnh hưởng.
3. Giúp cải thiện chất lượng phần mềm và giảm rủi ro lỗi trong tương lai.
4. Tăng sự hài lòng của stakeholder bằng cách quản lý và giao tiếp hiệu quả về lỗi và tiến độ sửa lỗi.
• Không phải mục tiêu: Fixing all defects regardless of their impact – Trong thực tế, không bắt buộc sửa tất cả lỗi (ví dụ: lỗi nhỏ, không ảnh hưởng đến người dùng, hoặc sửa tốn kém không cần thiết).
• Đáp án đúng: A – Fixing all defects regardless of their impact
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Nếu câu trả lời nói Fix all defects hoặc regardless of priority/impact → Sai, vì quản lý sự cố hướng đến ưu tiên và xử lý hợp lý, không phải tất cả.

Mở rộng các câu hỏi cùng chủ đề:

1. What is the main purpose of incident management?

   A. Identify and document all failures

   B. Control and manage defects throughout the test process

   C. Assign defects to developers

   D. Avoid writing test cases

   Đáp án: B

   (Nguồn: ISTQB)

2. Which of the following is NOT part of a defect report?

   A. Steps to reproduce

   B. Expected result

   C. Root cause analysis by developer

   D. Actual result

   Đáp án: C – Root cause là trách nhiệm của dev, không phải tester ghi ban đầu.

   (Nguồn: ISTQB)

Question 43:

Which of the following is a risk of test automation?

A. Using an automation tool that will not be supported in the future

B. Developing test automation for particularly tedious manual testing areas

C. Using technical testers to implement the automation

D. Developing automated reporting

Ý chính cần nhớ:

• Rủi ro trong test automation là các yếu tố có thể khiến đầu tư tự động hóa không hiệu quả hoặc gây tổn thất lâu dài, ví dụ:
• Chọn công cụ sẽ không còn được hỗ trợ trong tương lai → làm test scripts không dùng được về sau, mất chi phí chuyển đổi.
• Chọn kịch bản không ổn định, chi phí bảo trì cao.
• Thiếu nhân sự có kỹ năng phù hợp.
• Phân tích đáp án:
• A: Đúng – Đây là rủi ro thực sự. Khi công cụ không được hỗ trợ, tổ chức sẽ gặp vấn đề duy trì và cập nhật test automation.
• B: Sai – Đây là lợi ích, vì tự động hóa được dùng chính để giảm công việc thủ công tẻ nhạt.
• C: Sai – Đây là điều mong muốn, cần kỹ thuật viên giỏi để thực hiện automation.
• D: Sai – Tự động hóa báo cáo là ưu điểm, không phải rủi ro.
• Đáp án đúng: A – Using an automation tool that will not be supported in the future
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Tool Support for Testing)

Mẹo nhớ nhanh:

• Khi thấy từ khóa risk of automation, nghĩ đến:
• Tool không ổn định hoặc sớm bị bỏ rơi.
• Chi phí cao, ROI thấp.
• Test scripts khó bảo trì.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is NOT a benefit of test automation?

   A. Reduced repetitive manual effort

   B. Faster regression testing

   C. Detecting new defects automatically without human input

   D. Consistent test execution

   Đáp án: C – Automation không thể tự nghĩ ra test mới.

   (Nguồn: ISTQB)

2. What is a challenge of implementing test automation?

   A. Initial investment cost

   B. Tool selection and maintenance

   C. High learning curve for test team

   D. All of the above

   Đáp án: D

   (Nguồn: ISTQB)

Question 44:

How would you structure a test team for a project requiring specialized knowledge in both business processes and technical execution?

A. Assign only developers as testers

B. Use only external consultants

C. Focus on regression testing

D. Combine business experts with technical testers

Ý chính cần nhớ:

• Một dự án yêu cầu cả kiến thức nghiệp vụ (business domain) và kỹ thuật (technical execution) cần có đội ngũ kiểm thử đa dạng chuyên môn.
• Kết hợp business experts (hiểu rõ yêu cầu, quy trình, luồng nghiệp vụ) và technical testers (kiểm thử chức năng, hiệu suất, viết script tự động) sẽ giúp phát hiện lỗi từ cả góc nhìn nghiệp vụ và kỹ thuật.
• Đáp án chuẩn: D – Combine business experts with technical testers.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Khi câu hỏi có từ khóa specialized knowledge in business and technical, phương án đúng luôn là kết hợp cả hai kỹ năng.
• Chỉ dùng developers, external consultants hoặc chỉ tập trung regression testing sẽ không đáp ứng đầy đủ yêu cầu của dự án.

Mở rộng các câu hỏi cùng chủ đề:

1. Who is responsible for ensuring test coverage from both business and technical perspectives?

   A. Only developers

   B. Business analysts

   C. Combination of business and technical testers

   D. End users

   Đáp án: C

   (Nguồn: ISTQB)

2. Why should a test team have mixed expertise?

   A. To avoid redundant tests

   B. To improve test efficiency and defect detection rate

   C. To make the test team independent from developers

   D. To reduce test execution time

   Đáp án: B

   (Nguồn: ISTQB)

3. In a project with high business complexity, which testers are most valuable?

   A. Technical testers only

   B. Business experts only

   C. Testers with both technical and domain expertise

   D. End users only

   Đáp án: C

   (Nguồn: ISTQB)

Question 45:

Which of the following tasks is MOST LIKELY to be performed by the test manager?

A. Write test summary reports based on the information gathered during testing

B. Review tests developed by others

C. Create the detailed test execution schedule

D. Analyze, review, and assess requirements, specifications and models for testability

Ý chính cần nhớ:

• Vai trò của Test Manager là quản lý toàn bộ hoạt động kiểm thử, bao gồm:
• Lập kế hoạch, quản lý nguồn lực, lên lịch kiểm thử, quản lý rủi ro.
• Phối hợp nhóm tester, theo dõi tiến độ và báo cáo kết quả kiểm thử.
• Trong bốn lựa chọn:
• A: Viết báo cáo tóm tắt (test summary report) là nhiệm vụ chính của Test Manager, thể hiện vai trò báo cáo và tổng hợp thông tin sau kiểm thử.
• B: Review test thường do Test Analyst hoặc Test Lead phụ trách.
• C: Lên lịch chi tiết có thể do Test Lead/Test Analyst thực hiện dưới sự giám sát của Test Manager.
• D: Phân tích tính khả kiểm thử thường là nhiệm vụ của Test Analyst/Designer.
• Đáp án chuẩn: A – Write test summary reports based on the information gathered during testing.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Test Manager = Quản lý + Báo cáo + Lập kế hoạch
• Nếu có từ khóa summary report, manage, plan, monitor → thường là Test Manager.
• Các công việc phân tích chi tiết, thiết kế và review test case thường thuộc Test Analyst hoặc Test Designer.

Mở rộng các câu hỏi cùng chủ đề:

1. Which activity is the primary responsibility of a Test Manager?

   A. Writing detailed test cases

   B. Approving the test strategy and test plan

   C. Executing test scripts manually

   D. Debugging the code to fix defects

   Đáp án: B

   (Nguồn: ISTQB)

2. Who is accountable for managing risks in testing and communicating them to stakeholders?

   A. Developer

   B. Test Manager

   C. Test Analyst

   D. Product Owner

   Đáp án: B

   (Nguồn: ISTQB)

3. Which task is NOT typically performed by a Test Manager?

   A. Defining the test strategy

   B. Writing unit tests for new code

   C. Managing the test schedule

   D. Preparing the final test summary report

   Đáp án: B

   (Nguồn: ISTQB)

Question 46:

What information is typically included in the summary section of an incident report? (Choose 2 correct answers)

A. Personal opinions of the tester

B. Test progress metrics

C. Incident description and impact

D. Steps to reproduce the issue

Ý chính cần nhớ:

• Incident Report (hay Bug Report) là tài liệu ghi nhận một sự cố/phát hiện lỗi trong phần mềm, nhằm giúp đội phát triển hiểu và khắc phục sự cố.
• Mục tiêu chính của phần Summary: mô tả ngắn gọn và đầy đủ bản chất của sự cố. Thông tin quan trọng thường bao gồm:
• C: Incident description and impact – Mô tả sự cố và mức độ ảnh hưởng đến hệ thống/người dùng.
• D: Steps to reproduce the issue – Các bước cụ thể để tái hiện lỗi, giúp lập trình viên kiểm tra và sửa.
• Không bao gồm:
• A: Ý kiến cá nhân → gây thiên vị, không phải nội dung chuyên môn.
• B: Test progress metrics → nằm trong báo cáo tiến độ kiểm thử, không liên quan trực tiếp đến một sự cố cụ thể.
• Đáp án chuẩn: C và D.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Incident Report = Mô tả sự cố + Cách tái hiện
• Từ khóa thường gặp: Description, Impact, Steps to reproduce → Nội dung quan trọng của báo cáo sự cố.
• Opinions, Metrics → Không liên quan hoặc nằm ở báo cáo khác.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following elements are essential in a good bug report? (Choose 2)

   A. Expected result vs Actual result

   B. Personal assumptions about the cause

   C. Test environment details

   D. Opinions about developer skills

   Đáp án: A và C

   (Nguồn: ISTQB)

2. What should be avoided in an incident report?

   A. Clear reproduction steps

   B. Relevant screenshots or logs

   C. Emotional or subjective comments

   D. Severity and priority information

   Đáp án: C

   (Nguồn: ISTQB)

3. Which information makes an incident report most effective?

   A. A unique identifier, description, impact, and reproducible steps

   B. Only the personal opinion of tester

   C. Metrics about all test cases executed

   D. A list of unrelated defects

   Đáp án: A

   (Nguồn: ISTQB)

Question 47:

Which one of the following test tools is mostly suitable for developers rather than testers?

A. Requirement management tools

B. Configuration management tools

C. Defect management tools

D. Performance testing tools

Ý chính cần nhớ:

• Developer vs Tester Tool Usage:
• Configuration management tools (B): Được sử dụng chủ yếu bởi developer để quản lý các phiên bản mã nguồn, kiểm soát thay đổi và đồng bộ code giữa các thành viên.
• Requirement management tools (A): Chủ yếu dùng bởi BA, PM, Tester để quản lý yêu cầu.
• Defect management tools (C): Chủ yếu do tester và QA sử dụng để báo cáo và theo dõi lỗi.
• Performance testing tools (D): Chủ yếu do tester sử dụng để kiểm tra hiệu suất.
• Đáp án chuẩn: B – Configuration management tools.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Tool Support for Testing)

Mẹo nhớ nhanh:

• Configuration = Code version control → Developer dùng.
• Các công cụ còn lại thiên về hoạt động kiểm thử hoặc quản lý yêu cầu.

Mở rộng các câu hỏi cùng chủ đề:

1. Which tool is mainly used by developers to manage code versions?

   A. Defect tracking tool

   B. Configuration management tool

   C. Static analysis tool

   D. Test execution tool

   Đáp án: B

   (Nguồn: ISTQB)

2. Who primarily uses defect management tools?

   A. Developers

   B. Testers

   C. Business analysts

   D. Project sponsors

   Đáp án: B

   (Nguồn: ISTQB)

3. What is the main purpose of configuration management in software development?

   A. To track requirements changes

   B. To manage code versions and builds

   C. To automate test execution

   D. To analyze performance

   Đáp án: B

   (Nguồn: ISTQB)

Question 48:

Which element is critical in a test estimate?

A. The graphical design of the test documentation

B. The time and resources required to complete testing

C. The color scheme for the test report

D. The number of developers in the team

Ý chính cần nhớ:

• Test Estimation (Ước lượng kiểm thử): Là quá trình xác định thời gian (time) và nguồn lực (resources) cần thiết để thực hiện các hoạt động kiểm thử.
• Trong các đáp án:
• B: The time and resources required to complete testing là yếu tố cốt lõi của quá trình ước lượng.
• A và C: Chỉ liên quan đến trình bày tài liệu → không ảnh hưởng trực tiếp đến estimation.
• D: Số lượng developer có thể liên quan gián tiếp nhưng estimation tập trung vào resource testing (tester, tool, environment), không phải số lượng dev.
• Đáp án chuẩn: B – The time and resources required to complete testing.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Estimation = Time + Resources.
• Các yếu tố không liên quan trực tiếp đến effort testing (thiết kế, màu sắc báo cáo) → gây nhiễu, loại bỏ.

Mở rộng các câu hỏi cùng chủ đề:

1. What are the key inputs to test estimation?

   A. Test basis, test approach, resource availability

   B. Color template for report, developer list

   C. Bug priority, developer holiday list

   D. Project marketing plan

   Đáp án: A

   (Nguồn: ISTQB)

2. Which of the following factors can influence test estimation?

   A. Skills and experience of testers

   B. Complexity of the product

   C. Risks and dependencies

   D. All of the above

   Đáp án: D

   (Nguồn: ISTQB)

3. Why is accurate estimation important in test planning?

   A. To ensure deadlines and resources are realistic

   B. To improve UI design of test documents

   C. To decide defect severity

   D. To control code versioning

   Đáp án: A

   (Nguồn: ISTQB)

Question 49:

Which is a key benefit of risk-based testing?

A. It reduces the need for a test plan

B. It ensures all defects are identified and fixed

C. It optimizes test coverage by focusing on high-risk areas

D. It eliminates the need for regression testing

Ý chính cần nhớ:

• Risk-Based Testing (RBT) là phương pháp ưu tiên các hoạt động kiểm thử dựa trên mức độ rủi ro của các tính năng hoặc module trong phần mềm.
• Mục tiêu chính là tối ưu hóa phạm vi kiểm thử (test coverage) bằng cách tập trung kiểm thử kỹ hơn vào các khu vực có rủi ro cao nhất.
• Không có phương pháp nào đảm bảo 100% defect được tìm và fix (loại bỏ B).
• Regression testing và test plan vẫn cần thiết (loại bỏ A và D).
• Đáp án chuẩn: C – It optimizes test coverage by focusing on high-risk areas.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Câu thần chú: Risk-based testing = Ưu tiên High Risk trước.
• Khi gặp đáp án có từ khóa focus on high-risk, thường là đáp án đúng.

Mở rộng các câu hỏi cùng chủ đề:

1. Which factor is most important when applying risk-based testing?

   A. Probability and impact of potential failures

   B. Number of test cases executed

   C. Number of developers available

   D. Time to create test reports

   Đáp án: A

   (Nguồn: ISTQB)

2. What is the primary advantage of risk-based testing?

   A. It allows test efforts to be prioritized based on the likelihood and impact of failures.

   B. It removes the need for detailed test documentation.

   C. It guarantees zero defects.

   D. It reduces the size of the development team.

   Đáp án: A

   (Nguồn: ISTQB)

3. Which testing activity is commonly associated with risk-based testing?

   A. Risk analysis and prioritization of test cases.

   B. Random execution of test cases.

   C. Skipping tests with low severity.

   D. Automating all test cases.

   Đáp án: A

   (Nguồn: ISTQB)

Question 50:

Which of the following is a benefit of effective incident management?

A. Increased software development time

B. Decreased software reliability

C. Improved customer satisfaction

D. Reduced software functionality

Ý chính cần nhớ:

• Incident Management là quá trình quản lý các vấn đề (incidents/defects) xảy ra trong quá trình kiểm thử hoặc khi sản phẩm đang vận hành.
• Một hệ thống quản lý sự cố hiệu quả giúp:
• Giảm thiểu tác động tiêu cực của sự cố lên sản phẩm và người dùng.
• Tăng độ tin cậy (reliability) của phần mềm thông qua việc phát hiện, phân loại và xử lý lỗi kịp thời.
• Nâng cao sự hài lòng của khách hàng nhờ phản hồi và giải quyết sự cố nhanh chóng, minh bạch.
• Phân tích đáp án:
• A: Sai – Quản lý sự cố hiệu quả không làm tăng thời gian phát triển, ngược lại còn giúp tối ưu hơn.
• B: Sai – Quản lý sự cố hiệu quả tăng, không giảm độ tin cậy.
• C: Đúng – Nâng cao sự hài lòng của khách hàng là lợi ích chính.
• D: Sai – Mục tiêu không bao giờ là giảm chức năng phần mềm.
• Đáp án chuẩn: C – Improved customer satisfaction.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Khi nghĩ về incident management, hãy liên tưởng đến giải quyết vấn đề nhanh → khách hàng hài lòng hơn.
• Các đáp án chứa từ khóa increased time, reduced functionality, decreased reliability → thường là sai.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is a goal of incident management?

   A. To track defects and ensure their resolution.

   B. To reduce customer satisfaction.

   C. To delay product release.

   D. To minimize communication among stakeholders.

   Đáp án: A

   (Nguồn: ISTQB)

2. What is the primary purpose of recording incidents during testing?

   A. To build a historical database for process improvement.

   B. To blame developers for defects.

   C. To make testing slower but more accurate.

   D. To skip documentation.

   Đáp án: A

   (Nguồn: ISTQB)

3. Which of the following is a typical output of incident management?

   A. Incident reports with priority and status.

   B. Reduced number of test cases.

   C. Complete removal of all bugs before release.

   D. Test scripts for automation.

   Đáp án: A

   (Nguồn: ISTQB)

Question 51:

Which of the following statement is CORRECT about decision coverage?

A. Decision coverage is a measure of the percentage of paths through the source code exercised by tests.

B. Decision coverage is a measure of the percentage of business flows through the component exercised by tests.

C. Decision coverage is a measure of the IF statements in the code that are exercised with both the true and false outcomes.

D. Decision coverage is a measure of the proportion of decision outcomes in the source code exercised by tests.

Ý chính cần nhớ:

• Decision Coverage (Branch Coverage):
• Là kỹ thuật kiểm thử hộp trắng (white-box testing).
• Đo lường tỷ lệ các quyết định (decision outcomes) trong code đã được thực thi bởi các ca kiểm thử.
• Một decision thường là một câu lệnh rẽ nhánh (if, case, loop condition), và mỗi decision có ít nhất 2 kết quả (true/false).
• Đáp án đúng: D – A measure of the proportion of decision outcomes in the source code exercised by tests.
• Các đáp án sai:
• A: Nhầm với path coverage (đo tất cả đường đi).
• B: Không phải đơn vị đo của decision coverage (liên quan business flow).
• C: Không chỉ đo IF statements, mà đo mọi decision outcome, kể cả switch, loop.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Design Techniques)

Mẹo nhớ nhanh:

• Decision Coverage = Decision Outcomes (True/False).
• Keyword quan trọng: proportion of decision outcomes → luôn là đáp án đúng.
• Path coverage → paths.
• Statement coverage → statements.
• Decision coverage → decision outcomes.

Mở rộng các câu hỏi cùng chủ đề:

1. Which coverage criterion is stronger than statement coverage?

   A. Decision coverage

   B. Path coverage

   C. Condition coverage

   D. None of the above

   Đáp án: A – Decision coverage > statement coverage.

   (Nguồn: ISTQB)

2. If 100% decision coverage is achieved, what does it imply?

   A. 100% statement coverage is also achieved.

   B. All possible paths are tested.

   C. All possible condition combinations are tested.

   D. Code is defect-free.

   Đáp án: A

   (Nguồn: ISTQB)

3. Which coverage measures how many Boolean outcomes (true/false) are executed?

   A. Decision coverage

   B. Condition coverage

   C. Path coverage

   D. Data flow coverage

   Đáp án: A

   (Nguồn: ISTQB)

Question 52:

Which one of the following is MOST likely to be a benefit of test execution tools?

A. It is easy to create regression tests.

B. It is easy to maintain version control of test assets.

C. It is easy to design tests for security testing.

D. It is easy to run regression tests.

Ý chính cần nhớ:

• Test Execution Tools:
• Giúp tự động chạy các test cases, đặc biệt là Regression Testing, nhanh hơn và ít lỗi hơn so với chạy thủ công.
• Không trực tiếp hỗ trợ tạo hoặc thiết kế test, nhưng giúp thực thi lặp đi lặp lại các test đã có một cách dễ dàng.
• Đáp án đúng: D – It is easy to run regression tests.
• Giải thích các đáp án sai:
• A: Công cụ hỗ trợ chạy test, không tạo mới regression test cases.
• B: Version control thường thuộc về công cụ quản lý test (test management) hoặc hệ thống quản lý mã nguồn (Git, SVN).
• C: Thiết kế test cho bảo mật là hoạt động thủ công hoặc bằng tool chuyên biệt khác, không phải công cụ thực thi test thông thường.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Tool Support for Testing)

Mẹo nhớ nhanh:

• Test Execution Tool = Auto-run test → dễ chạy regression test.
• Keyword đúng: run regression tests.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is NOT a typical benefit of test execution tools?

   A. Run tests automatically

   B. Reduce human error in repetitive tasks

   C. Design high-quality test cases automatically

   D. Increase test coverage for regression

   Đáp án: C

   (Nguồn: ISTQB)

2. Which test tool helps re-run large sets of test cases quickly?

   A. Static analysis tool

   B. Test execution tool

   C. Defect management tool

   D. Configuration management tool

   Đáp án: B

   (Nguồn: ISTQB)

Question 53:

What is NOT typically a feature of a test management tool?

A. Scheduling tests

B. Generating test data

C. Logging test results

D. Managing testing activities

Ý chính cần nhớ:

• Test Management Tool (TMT): Dùng để quản lý hoạt động kiểm thử, bao gồm:
• Quản lý test cases, test suites.
• Lập lịch (scheduling) thực hiện test.
• Ghi nhận (logging) kết quả test.
• Quản lý tiến độ và hoạt động kiểm thử.
• Việc tạo dữ liệu kiểm thử (Generating test data) không phải chức năng chính của TMT. Việc này thường được hỗ trợ bởi Test Data Generation Tool hoặc làm thủ công.
• Đáp án đúng: B – Generating test data
• Giải thích các đáp án sai:
• A: Scheduling tests → Chức năng cơ bản của TMT để sắp xếp thứ tự chạy test.
• C: Logging test results → Chức năng chính để lưu và theo dõi kết quả kiểm thử.
• D: Managing testing activities → Nhiệm vụ chính của TMT là quản lý toàn bộ quá trình kiểm thử.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Tool Support for Testing)

Mẹo nhớ nhanh:

• Test Management Tool = Quản lý & Báo cáo, không tạo dữ liệu kiểm thử.
• Nếu thấy Generate test data → Thường là đáp án sai trong ISTQB.

Mở rộng các câu hỏi cùng chủ đề:

1. Which is NOT a common feature of test management tools?

   A. Tracking defects

   B. Managing test execution

   C. Automatically generating input data

   D. Reporting test progress

   Đáp án: C

   (Nguồn: ISTQB)

2. Which test tool focuses on planning, scheduling, and tracking?

   A. Test management tool

   B. Static analysis tool

   C. Test execution tool

   D. Performance test tool

   Đáp án: A

   (Nguồn: ISTQB)

Question 54:

Which metric would help monitor the progress of test execution?

A. Number of open defects compared to closed defects

B. Number of passed requirements per code line

C. Project manager's confidence level

D. Test script reusability percentage

Ý chính cần nhớ:

• Progress of test execution = Đo lường mức độ tiến triển của việc chạy test cases và xử lý defect.
• Số lượng defect đang mở (open) so với đã đóng (closed) là chỉ số chính để theo dõi tiến độ kiểm thử vì nó thể hiện mức độ xử lý lỗi qua thời gian.
• Đáp án đúng: A – Number of open defects compared to closed defects
• Giải thích các đáp án sai:
• B: Number of passed requirements per code line → Không liên quan trực tiếp đến tiến độ thực thi test.
• C: Project manager's confidence level → Mang tính chủ quan, không phải metric kỹ thuật.
• D: Test script reusability percentage → Đo hiệu quả tái sử dụng, không phải tiến độ thực thi.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Test Management)

Mẹo nhớ nhanh:

• Progress Execution Metric = Open vs Closed Defects.
• Hãy nhớ: Tiến độ kiểm thử = Trạng thái xử lý lỗi.

Mở rộng các câu hỏi cùng chủ đề:

1. Which metric is most useful for tracking test execution progress?

   A. Defect density

   B. Number of test cases executed vs planned

   C. Cost of fixing defects

   D. Test environment uptime

   Đáp án: B – Câu này tương tự, dùng defect status hoặc executed vs planned để đo tiến độ.

   (Nguồn: ISTQB)

2. Which metric best indicates readiness for release?

   A. Defects open vs closed and their severity.

   B. Lines of code tested.

   C. Number of test scripts reused.

   D. Manager confidence.

   Đáp án: A

   (Nguồn: ISTQB)

Question 55:

What is a key feature of a test execution tool?

A. Managing requirements traceability.

B. Supporting static code analysis.

C. Automatically running tests and recording results.

D. Managing test incidents.

Ý chính cần nhớ:

• Test Execution Tool là công cụ hỗ trợ thực hiện test case một cách tự động, giảm thiểu thao tác thủ công.
• Chức năng cốt lõi là chạy test tự động (automatically running tests) và ghi lại kết quả thực thi (recording results) để phân tích và báo cáo.
• Các hoạt động như quản lý yêu cầu (traceability), phân tích tĩnh, hay quản lý sự cố thường thuộc về các công cụ khác (Test Management, Static Analysis, Defect Management).
• Đáp án chuẩn: C – Automatically running tests and recording results.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Tool Support for Testing)

Mẹo nhớ nhanh:

• Câu thần chú: Execution Tool = Auto Run + Auto Record.
• Từ khóa gợi ý:
• Run tests automatically, Record results → đặc trưng của execution tool.
• Traceability, Static analysis, Managing incidents → thuộc nhóm công cụ khác.

Mở rộng các câu hỏi cùng chủ đề:

1. What is the main purpose of a test execution tool?

   A. To support automated execution of test scripts and capture results.

   B. To analyze source code quality without execution.

   C. To manage requirements and their test coverage.

   D. To manage defect lifecycle and incident reports.

   Đáp án: A

   (Nguồn: ISTQB)

2. Which tool is typically used for executing automated regression tests?

   A. Test Management Tool.

   B. Test Execution Tool.

   C. Static Analysis Tool.

   D. Incident Management Tool.

   Đáp án: B

   (Nguồn: ISTQB)

3. Which feature is not usually part of a test execution tool?

   A. Scheduling automated test runs.

   B. Recording actual test results.

   C. Managing defect statuses.

   D. Comparing expected and actual outputs.

   Đáp án: C

   (Nguồn: ISTQB)

Question 56:

What type of test tool would you use to ensure coding standards are met?

A. Test design tool.

B. Test execution tool.

C. Static analysis tool.

D. Configuration management tool.

Ý chính cần nhớ:

• Coding standards là các quy tắc, chuẩn mực về cách viết code (naming convention, indentation, comment rules, complexity rules…).
• Static analysis tool là công cụ phân tích mã nguồn tĩnh (không cần chạy chương trình) để phát hiện:
• Vi phạm coding standard.
• Lỗi tiềm ẩn (potential defects).
• Đo lường độ phức tạp (complexity).
• Đáp án chuẩn: C – Static analysis tool.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Static Testing Tools)

Mẹo nhớ nhanh:

• Câu thần chú: Static analysis = Kiểm tra code tĩnh → Đảm bảo tiêu chuẩn code.
• Từ khóa gợi ý:
• Coding standards, Static → công cụ phân tích code mà không chạy test.
• Test design, Test execution, Configuration → không liên quan trực tiếp tới việc kiểm tra chuẩn code.

Mở rộng các câu hỏi cùng chủ đề:

1. Which type of tool helps enforce coding guidelines before code execution?

   A. Static analysis tool.

   B. Test management tool.

   C. Test execution tool.

   D. Incident management tool.

   Đáp án: A

   (Nguồn: ISTQB)

2. Which is an example of a static analysis tool?

   A. SonarQube, Checkstyle, PMD.

   B. Selenium.

   C. JUnit.

   D. Bugzilla.

   Đáp án: A

   (Nguồn: ISTQB)

3. Static analysis is most beneficial in detecting:

   A. Runtime performance issues.

   B. Coding standard violations and potential defects.

   C. Incorrect expected test results.

   D. Wrong test data configuration.

   Đáp án: B

   (Nguồn: ISTQB)

Question 57:

Which of the following tools would you use for dynamic analysis? (Choose 2 correct answers)

A. Static analysis tool

B. Test management tool

C. Performance testing tool

D. Monitoring tools

Ý chính cần nhớ:

• Dynamic analysis = Phân tích phần mềm khi chương trình đang chạy để kiểm tra:
• Hiệu năng (performance).
• Bộ nhớ (memory usage).
• Deadlocks, leaks, bottlenecks,…
• Các công cụ phục vụ dynamic analysis bao gồm:
• Performance testing tool (C) → kiểm tra tốc độ, tải (load, stress test).
• Monitoring tools (D) → giám sát hành vi runtime (CPU, memory, network, resource usage).
• Đáp án chuẩn: C và D.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Tool Support for Testing)

Mẹo nhớ nhanh:

• Static = Không chạy code → chỉ đọc mã nguồn.
• Dynamic = Chạy code → dùng tool đo performance, giám sát (monitor).
• Từ khóa: Dynamic analysis → runtime behavior → Performance, Monitoring.

Mở rộng các câu hỏi cùng chủ đề:

1. Which of the following is an example of a dynamic testing tool?

   A. LoadRunner

   B. JUnit

   C. SonarQube

   D. Bugzilla

   Đáp án: A và B – LoadRunner và JUnit chạy test khi code được thực thi.

   (Nguồn: ISTQB)

2. Which type of tool supports dynamic analysis to detect memory leaks?

   A. Static analysis tool.

   B. Memory monitoring tool.

   C. Test design tool.

   D. Configuration management tool.

   Đáp án: B

   (Nguồn: ISTQB)

3. Dynamic analysis helps detect:

   A. Violations of coding standards.

   B. Deviations from expected runtime behavior (e.g., performance issues).

   C. Missing requirement documentation.

   D. Incorrect test data mapping.

   Đáp án: B

   (Nguồn: ISTQB)

Question 58:

What is a characteristic feature of a test harness?

A. Schedule tests

B. Supplies inputs to the software being tested

C. Manages software incidents

D. Analyzes software performance

Ý chính cần nhớ:

• Test harness là một bộ công cụ và môi trường được thiết lập để hỗ trợ chạy test cho phần mềm hoặc module cụ thể.
• Chức năng chính: cung cấp dữ liệu đầu vào (inputs), điều kiện test và môi trường giả lập để kiểm tra hành vi của phần mềm.
• Đáp án chuẩn: B – Supplies inputs to the software being tested.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Tool Support for Testing)

Mẹo nhớ nhanh:

• Harness = Bộ khung hỗ trợ test → cung cấp đầu vào, điều kiện, môi trường giả.
• Không nhầm lẫn với:
• A: Schedule tests → tính năng của test execution tool.
• C: Manages software incidents → tính năng của defect management tool.
• D: Analyzes software performance → công cụ kiểm thử hiệu năng.

Mở rộng các câu hỏi cùng chủ đề:

1. What is the purpose of a test harness in unit testing?

   A. Provide drivers and stubs for components under test.

   B. Manage test reports.

   C. Analyze coding standards.

   D. Control test schedules.

   Đáp án: A

   (Nguồn: ISTQB)

2. Which of the following best describes a test harness?

   A. A collection of test scripts and test data used to test an application.

   B. A system for tracking defects.

   C. A tool for generating code coverage reports.

   D. A tool for static code analysis.

   Đáp án: A

   (Nguồn: ISTQB)

3. A test harness includes:

   A. Test drivers

   B. Stubs

   C. Test data

   D. Logging and comparison mechanisms

   Đáp án: A, B, C, D

   (Nguồn: ISTQB)

Question 59:

What is an advantage of using data-driven scripts in test automation?

A. They do not require external data.

B. They separate test data from scripts, enhancing flexibility.

C. They are simpler to maintain than linear scripts.

D. They eliminate the need for scripting knowledge.

Ý chính cần nhớ:

• Data-driven testing là kỹ thuật tự động hóa mà dữ liệu kiểm thử được tách biệt hoàn toàn khỏi kịch bản test (scripts).
• Ưu điểm chính:
• Tăng tính linh hoạt và khả năng mở rộng test case bằng cách dễ dàng thay đổi dữ liệu mà không phải sửa lại script.
• Cho phép chạy cùng một kịch bản với nhiều tập dữ liệu khác nhau mà không cần viết lại test code.
• Đáp án chuẩn: B – They separate test data from scripts, enhancing flexibility.
• Giải thích các đáp án sai:
• A: Sai – Data-driven cần external data (như file CSV, database).
• C: Sai – Không hẳn là đơn giản hơn, mà là linh hoạt hơn.
• D: Sai – Vẫn cần kỹ năng scripting để tạo data-driven scripts.
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Tool Support for Testing)

Mẹo nhớ nhanh:

• Keyword: Separate test data from scripts → tăng flexibility.
• Data-driven giúp test case dễ mở rộng, tái sử dụng với nhiều data khác nhau.

Mở rộng các câu hỏi cùng chủ đề:

1. What is a primary benefit of data-driven test automation?

   A. Test scripts never fail.

   B. Reuse the same script with multiple data sets.

   C. No need for test data.

   D. Eliminate manual testing completely.

   Đáp án: B

   (Nguồn: ISTQB)

2. Which of the following best describes data-driven testing?

   A. Embedding test data directly into scripts.

   B. Separating test data from test scripts.

   C. Only running tests manually.

   D. Using scripts that do not require maintenance.

   Đáp án: B

   (Nguồn: ISTQB)

3. Data-driven testing is useful when:

   A. Testing simple one-time tests.

   B. Testing multiple input combinations using the same logic.

   C. No test data available.

   D. Only manual testing is possible.

   Đáp án: B

   (Nguồn: ISTQB)

Question 60:

___ is the process of testing a single unit of code in an isolated manner and can be a method, a class, or a module.

A. Integration Testing

B. Unit Testing

C. Acceptance Testing

D. System Testing

Ý chính cần nhớ:

• Unit Testing là quá trình kiểm thử một đơn vị nhỏ nhất của phần mềm (method, class, module) một cách độc lập, không phụ thuộc vào các thành phần khác.
• Mục đích: Xác định các lỗi ngay từ giai đoạn phát triển để sửa chữa sớm.
• Các loại kiểm thử khác:
• Integration Testing: kiểm thử sự phối hợp giữa các module.
• Acceptance Testing: kiểm thử theo yêu cầu người dùng cuối.
• System Testing: kiểm thử toàn bộ hệ thống end-to-end.
• Đáp án chuẩn: B – Unit Testing
• (Nguồn: ISTQB Foundation Level Syllabus 2018 – Testing Throughout the Software Development Lifecycle)

Mẹo nhớ nhanh:

• Khi thấy từ khóa testing single unit, isolated manner → luôn nghĩ đến Unit Testing.
• Integration Testing liên quan đến các module kết nối với nhau.
• Acceptance Testing là kiểm thử chấp nhận của người dùng.
• System Testing là kiểm thử toàn bộ hệ thống.

Mở rộng các câu hỏi cùng chủ đề:

1. What is typically tested in unit testing?

   A. Individual functions or methods.

   B. User acceptance criteria.

   C. Interaction between modules.

   D. System performance under load.

   Đáp án: A

   (Nguồn: ISTQB)

2. Who usually writes and executes unit tests?

   A. Developers.

   B. Test managers.

   C. End users.

   D. Business analysts.

   Đáp án: A

   (Nguồn: ISTQB)

3. Which phase comes immediately after unit testing?

   A. Integration testing.

   B. System testing.

   C. Acceptance testing.

   D. Regression testing.

   Đáp án: A

   (Nguồn: ISTQB)

Kinh nghiệm làm bài thi SWT301 lần 2 hiệu quả hơn

1. Quản lý thời gian: 60 câu trong 60 phút, ưu tiên câu dễ trước để giữ nhịp làm bài.
2. Nắm rõ keyword: Các thuật ngữ ISTQB như “risk-based testing”, “test levels”, “defect life cycle” xuất hiện nhiều, học thuộc để chọn nhanh.
3. Đọc kỹ đề: Tránh bẫy câu hỏi phủ định (NOT, EXCEPT) và đáp án gây nhiễu.
4. Học 7 nguyên tắc kiểm thử: Giúp loại trừ nhanh phương án sai.
5. Luyện đề: Càng làm nhiều đề thi thử, bạn càng nhớ nhanh và chính xác hơn.

Kết luận

Sau khi trải qua kỳ thi FE Software Testing (SWT301) lần 1 kỳ SU25 tại Đại học FPT, chắc hẳn mỗi sinh viên chúng ta đều rút ra cho mình những bài học quý báu. Bộ đề thi và đáp án tham khảo mà TruongDevs chia sẻ trong bài viết này được tổng hợp từ đề chính thức và giải thích chi tiết dựa trên kiến thức chuẩn ISTQB cùng kinh nghiệm thực tế làm bài. Mục tiêu lớn nhất là giúp anh em hiểu bản chất từng câu hỏi, nắm chắc kiến thức trọng tâm và tự tin hơn khi bước vào kỳ thi lần sau.

Xin nhấn mạnh rằng đáp án trong bài chỉ mang tính chất tham khảo, khuyến nghị bạn nên kết hợp với tài liệu học chính thức, giáo trình môn học và đề cương từ giảng viên để đạt kết quả tốt nhất. Đây không phải đáp án “chính thức” từ nhà trường và cũng không đảm bảo 100% giống đề ở lần thi lại, nhưng chắc chắn sẽ là nguồn tài liệu hữu ích để bạn luyện tập và nâng cao kỹ năng làm bài trắc nghiệm.

Nếu thấy bài viết này giúp ích cho quá trình ôn tập của bạn, hãy chia sẻ cho bạn bè cùng khoa, cùng lớp để mọi người đều có cơ hội học tập tốt hơn. Khi chia sẻ, vui lòng ghi rõ nguồn từ TruongDevs để tôn trọng công sức tổng hợp và biên soạn nội dung, đồng thời giúp nhiều sinh viên khác tiếp cận được tài liệu chất lượng.

Chúc tất cả anh em FPTU tự tin, giữ vững tinh thần "chất như dev", hoàn thành thật tốt môn SWT301 ở những lần thi tới và sớm đạt được số điểm mà mình mong muốn!