1. Software Testing là gì? Mục đích chính của testing?

Câu trả lời: Testing là quá trình thực thi chương trình/hệ thống với mục đích tìm ra lỗi.

Mục đích chính:

• Phát hiện defects/bugs
• Đảm bảo software đáp ứng requirements
• Cải thiện chất lượng sản phẩm
• Giảm rủi ro và chi phí sửa lỗi

2. Phân biệt Verification và Validation?

Câu trả lời:

Verification: “Are we building the product right?”

• Kiểm tra sản phẩm có đúng theo specification không
• Thực hiện qua Review, Walkthrough, Inspection
• Không involve code execution

Validation: “Are we building the right product?”

• Kiểm tra sản phẩm có đáp ứng nhu cầu user không
• Thực hiện qua actual testing
• Involve code execution

3. STLC (Software Testing Life Cycle) gồm những phase nào?

Câu trả lời:

1. Requirement Analysis – Phân tích yêu cầu, xác định testable requirements
2. Test Planning – Lập kế hoạch test, estimate effort, resources
3. Test Case Development – Viết test cases, prepare test data
4. Test Environment Setup – Chuẩn bị môi trường test
5. Test Execution – Thực hiện test, log defects
6. Test Closure – Kết thúc, báo cáo, lessons learned

4. Phân biệt Test Plan và Test Strategy?

Câu trả lời:

Test Strategy:

• Document high-level, long-term
• Định hướng testing cho toàn organization/product line
• Ít thay đổi, độc lập với project
• Define testing approach, tools, best practices

Test Plan:

• Document chi tiết cho specific project
• Bao gồm scope, approach, resources, schedule
• Thay đổi theo từng project
• Based on Test Strategy

5. Black Box, White Box và Grey Box Testing là gì?

Câu trả lời:

Black Box Testing:

• Test mà không cần biết internal structure/code
• Chỉ quan tâm input/output
• Based on requirements/specifications
• Ví dụ: Functional testing, UAT

White Box Testing:

• Test với full knowledge về code/internal structure
• Kiểm tra logic paths, conditions, loops
• Cần programming knowledge
• Ví dụ: Unit testing, Code coverage

Grey Box Testing:

• Kết hợp cả Black Box và White Box
• Biết một phần internal structure
• Ví dụ: Integration testing, Database testing

6. Smoke Testing và Sanity Testing khác nhau thế nào?

Câu trả lời:

Smoke Testing:

• Test cơ bản để verify build có stable không
• Cover main/critical functionalities
• Wide and shallow approach
• Thực hiện mỗi khi có new build
• Automated thường xuyên

Sanity Testing:

• Test sau khi có minor changes/bug fixes
• Verify specific functionality works
• Narrow and deep approach
• Focus on changed areas
• Usually manual

7. Regression Testing là gì? Khi nào thực hiện?

Câu trả lời:

Định nghĩa: Test lại các chức năng cũ để đảm bảo changes/fixes mới không làm hỏng existing features.

Khi nào thực hiện:

• Sau khi fix bug
• Thêm feature mới
• Change requirements
• Update environment/configuration
• Performance improvements
• Patch updates

Best practice: Automate regression test suite

8. Bug/Defect Life Cycle gồm những status nào?

Câu trả lời:

1. New – Bug mới được report
2. Assigned – Assign cho developer
3. Open/Active – Developer bắt đầu analyze/fix
4. Fixed – Developer đã fix xong
5. Ready for Retest – Deploy fix, sẵn sàng test
6. Retest – Tester verify fix
7. Verified – Fix confirmed working
8. Closed – Bug closed successfully
9. Reopen – Bug vẫn còn sau khi fix
10. Rejected/Invalid – Không phải bug
11. Deferred – Postpone sang version sau
12. Duplicate – Bug đã được report trước đó

9. Severity và Priority của bug khác nhau như thế nào? Cho ví dụ

Câu trả lời:

Severity (Technical Impact):

• Mức độ ảnh hưởng đến system functionality
• Do tester định nghĩa
• Levels: Critical, Major, Minor, Trivial

Priority (Business Impact):

• Độ ưu tiên fix từ business perspective
• Do Product Owner/Manager quyết định
• Levels: P1 (Urgent), P2 (High), P3 (Medium), P4 (Low)

Ví dụ:

• High Severity, Low Priority: Application crash ở feature rất ít người dùng
• Low Severity, High Priority: Logo công ty hiển thị sai
• High Severity, High Priority: Payment gateway không hoạt động
• Low Severity, Low Priority: Typo trong help documentation

10. Entry Criteria và Exit Criteria trong Testing là gì?

Câu trả lời:

Entry Criteria – Điều kiện để bắt đầu testing:

• Test environment setup completed
• Test cases reviewed và approved
• Test data prepared
• Build successfully deployed
• Smoke test passed
• Required tools available
• Team resources allocated

Exit Criteria – Điều kiện để kết thúc testing:

• All planned test cases executed
• No Critical/Major bugs in Open status
• Test coverage đạt target (ví dụ: >80%)
• Performance benchmarks met
• UAT sign-off received
• Test report completed
• Defect metrics within acceptable range

BONUS: 5 Câu Hỏi Nâng Cao

11. Exploratory Testing là gì? Ưu nhược điểm?

Câu trả lời:

Testing approach không theo pre-defined test cases, tester tự do explore application dựa trên experience.

Ưu điểm:

• Tìm được unexpected/edge case bugs
• Creative và flexible approach
• Nhanh chóng adapt với changes
• Phù hợp cho Agile environment

Nhược điểm:

• Khó track test coverage
• Phụ thuộc nhiều vào tester skill
• Khó reproduce và document
• Không suitable cho regression

12. Test Coverage là gì? Các loại coverage?

Câu trả lời:

Metric đo lường bao nhiêu phần trăm application được test.

Các loại:

• Code Coverage: Statement, Branch, Function, Line coverage
• Requirements Coverage: Percentage requirements được test
• Test Case Coverage: Percentage test cases executed
• Feature Coverage: Percentage features tested
• Risk Coverage: Critical risks addressed

13. Boundary Value Analysis (BVA) là gì? Cho ví dụ

Câu trả lời:

Test technique focus vào test các giá trị tại boundary của input domain.

Ví dụ: Field chấp nhận tuổi từ 18-60

• Test values: 17, 18, 19, 59, 60, 61
• Minimum boundary: 17 (invalid), 18 (valid)
• Maximum boundary: 60 (valid), 61 (invalid)

14. Equivalence Partitioning là gì?

Câu trả lời:

Technique chia input data thành các equivalent classes, test một value từ mỗi class.

Ví dụ: Password field (6-12 characters)

• Class 1 (Invalid): < 6 characters (test với “abc”)
• Class 2 (Valid): 6-12 characters (test với “test123”)
• Class 3 (Invalid): > 12 characters (test với “verylongpassword”)

15. Adhoc Testing vs Monkey Testing?

Câu trả lời:

Adhoc Testing:

• Random nhưng có domain knowledge
• Tester hiểu application flow
• Có mục đích tìm specific defects
• Informal nhưng có logic

Monkey Testing:

• Completely random, no structure
• Không cần domain knowledge
• Random inputs/actions
• Mainly test stability/crash

Tips Trả Lời Interview

Khi được hỏi về Testing Basics:

1. Structure câu trả lời: Definition → Explanation → Example
2. Sử dụng real-world examples từ project/học tập
3. Draw diagrams nếu cần (STLC cycle, Bug lifecycle)
4. Show understanding về when/why/how

Template trả lời cho Intern:

"Theo em hiểu, [concept] là [simple definition].
Cụ thể hơn, [detailed explanation].
Ví dụ trong project em từng học/làm, [specific example].
Em nghĩ điều quan trọng nhất là [key takeaway]."

Khi không biết câu trả lời:

"Em chưa có hands-on experience với [topic],
nhưng based on em hiểu về testing principles,
em nghĩ [logical reasoning].
Em rất interested để học thêm về vấn đề này."