Bài này được biên soạn lại bằng tiếng Việt và đối chiếu với chuẩn thuật ngữ quốc tế ISTQB (CTFL v4.0) để đảm bảo chính xác, đồng thời bổ sung nhóm thuật ngữ AI testing mà nhiều từ điển cũ còn thiếu.

💡 Bạn nên đọc cùng lộ trình học tester để biết học khái niệm nào trước, khái niệm nào sau.

🔄 Trang được cập nhật liên tục — cập nhật gần nhất: 17/06/2026.

🧭 Mục lục nhanh

🧱 Nhóm 1 — Khái niệm cơ bản

Những viên gạch đầu tiên ai cũng cần nắm trước khi đi sâu.

Kiểm thử phần mềm (Software Testing): Kiểm thử phần mềm là quá trình đánh giá chất lượng của một thành phần hoặc hệ thống trong suốt vòng đời phát triển, nhằm phát hiện lỗi và xác nhận sản phẩm đáp ứng yêu cầu. Đây không đơn thuần là "đi tìm bug", mà còn là đo lường và góp phần cải thiện chất lượng. Nếu bạn mới bắt đầu, khóa Manual Testing cho người mới là điểm khởi hành lý tưởng.

Test Case: Test case là một tập hợp gồm điều kiện đầu vào, các bước thực hiện và kết quả mong đợi, dùng để kiểm tra một chức năng cụ thể. Ví dụ: với màn hình đăng nhập, một test case kiểm tra tình huống "nhập đúng email nhưng sai mật khẩu → hệ thống phải báo lỗi".

Test Plan: Test plan (kế hoạch kiểm thử) là tài liệu mô tả phạm vi, mục tiêu, nguồn lực, lịch trình và phương pháp kiểm thử cho một dự án. Nói gọn, nó trả lời bốn câu: kiểm thử cái gì, ai làm, khi nào và theo tiêu chí nào.

Test Scenario: Test scenario (kịch bản kiểm thử) là một tình huống hoặc luồng nghiệp vụ cần được kiểm tra, ở mức khái quát hơn test case. Một scenario như "Người dùng đặt hàng thành công" có thể được tách ra thành nhiều test case nhỏ.

Test Suite: Test suite là một nhóm các test case được gom lại để chạy cùng nhau theo một mục đích chung. Ví dụ: "Regression Suite" gom toàn bộ test case cần chạy lại sau mỗi lần build mới.

Defect / Bug (Lỗi): Defect (hay bug) là sự sai khác giữa kết quả thực tế của phần mềm và kết quả mong đợi theo yêu cầu. Nói nôm na: phần mềm đang "làm sai" so với điều đáng lẽ nó phải làm.

Bug Life Cycle (Vòng đời của lỗi): Bug life cycle là chuỗi trạng thái mà một lỗi đi qua từ lúc được phát hiện đến khi đóng, thường gồm New → Assigned → Open → Fixed → Retest → Closed (và có thể Reopened nếu lỗi tái diễn). Hiểu vòng đời này giúp bạn theo dõi lỗi trên Jira mạch lạc hơn.

Severity & Priority (Độ nghiêm trọng & Độ ưu tiên): Severity là mức độ ảnh hưởng của lỗi tới hệ thống, còn Priority là mức độ cần được sửa gấp xét theo nghiệp vụ. Ví dụ: một lỗi sai chính tả ở trang chủ có severity thấp nhưng priority cao, vì ai vào cũng nhìn thấy.

Test Environment (Môi trường kiểm thử): Test environment là tập hợp phần cứng, phần mềm, dữ liệu và cấu hình mạng được thiết lập để chạy kiểm thử. Mô hình phổ biến gồm ba tầng: Dev → Test/Staging → Production.

🔬 Nhóm 2 — Loại & cấp độ kiểm thử

Cùng một sản phẩm, ta test ở nhiều "tầng" và nhiều "góc nhìn" khác nhau.

Unit Testing (Kiểm thử đơn vị): Unit testing là việc kiểm thử từng thành phần nhỏ nhất của mã nguồn (như một hàm hoặc một class) một cách độc lập, thường do lập trình viên viết. Mục tiêu là bắt lỗi thật sớm, ngay ở cấp dòng code.

Integration Testing (Kiểm thử tích hợp): Integration testing là kiểm thử cách các module hoặc thành phần phối hợp với nhau sau khi đã ghép lại. Nó tìm những lỗi xuất hiện ở "điểm nối" giữa các phần — nơi unit test không nhìn thấy được.

System Testing (Kiểm thử hệ thống): System testing là kiểm thử toàn bộ hệ thống đã được tích hợp hoàn chỉnh, nhằm xác nhận nó đáp ứng yêu cầu. Đây là lúc tester kiểm tra sản phẩm như một khối thống nhất, từ đầu đến cuối.

Acceptance Testing / UAT (Kiểm thử chấp nhận): Acceptance testing là kiểm thử nhằm xác nhận phần mềm đáp ứng nhu cầu nghiệp vụ và sẵn sàng bàn giao, thường do khách hàng hoặc người dùng cuối thực hiện (gọi là UAT). Câu hỏi cốt lõi: "Sản phẩm này có dùng được trong thực tế không?".

Functional Testing (Kiểm thử chức năng): Functional testing là kiểm thử xem phần mềm có làm đúng những gì nó phải làm theo đặc tả hay không. Ví dụ: nút "Thanh toán" có thực sự trừ tiền và tạo đơn hàng đúng như mô tả.

Non-functional Testing (Kiểm thử phi chức năng): Non-functional testing là kiểm thử các thuộc tính chất lượng như hiệu năng, bảo mật, khả năng sử dụng và độ tin cậy. Nói cách khác, nó quan tâm "phần mềm làm tốt đến đâu" chứ không phải "phần mềm làm được gì".

Regression Testing (Kiểm thử hồi quy): Regression testing là việc chạy lại các test case cũ sau khi code thay đổi, để đảm bảo những tính năng đang chạy tốt không bị "vỡ". Ví dụ: vừa sửa lỗi giỏ hàng xong, bạn phải test lại cả phần thanh toán để chắc chắn không phát sinh lỗi mới.

Smoke Testing & Sanity Testing: Smoke testing là việc kiểm tra nhanh các chức năng quan trọng nhất để xem một build có "chạy được" không trước khi test sâu; còn sanity testing là kiểm tra nhanh một chức năng cụ thể vừa được sửa hoặc bổ sung. Dễ nhớ: smoke là kiểm tra diện rộng nhưng nông, sanity là kiểm tra hẹp nhưng sâu.

Retesting / Confirmation Testing (Kiểm thử xác nhận): Retesting là việc chạy lại đúng test case từng fail để xác nhận lỗi đã thực sự được sửa. Khác với regression (chạy các test khác để phòng lỗi mới phát sinh), retesting nhắm đúng vào lỗi vừa được fix.

🎯 Nhóm 3 — Kỹ thuật & nguyên tắc

Đây là phần "nghề" — biết cách thiết kế test thông minh để bắt được nhiều lỗi với ít công sức nhất.

Black-box Testing (Kiểm thử hộp đen): Black-box testing là kỹ thuật kiểm thử dựa trên yêu cầu và hành vi bên ngoài của phần mềm, không cần biết code bên trong. Tester chỉ quan tâm: nhập gì vào thì ra kết quả gì.

White-box Testing (Kiểm thử hộp trắng): White-box testing là kỹ thuật kiểm thử dựa trên cấu trúc mã nguồn bên trong, như các nhánh lệnh và luồng điều khiển. Nó đòi hỏi tester đọc hiểu code để thiết kế test bao phủ được các đường đi.

Equivalence Partitioning (Phân vùng tương đương): Equivalence partitioning là kỹ thuật chia dữ liệu đầu vào thành các nhóm cho kết quả tương tự nhau, rồi chỉ cần test một đại diện cho mỗi nhóm. Ví dụ ô nhập tuổi hợp lệ 18–60: thay vì test mọi con số, ta chỉ cần một giá trị nhỏ hơn 18, một giá trị trong khoảng 18–60 và một giá trị lớn hơn 60.

Boundary Value Analysis (Phân tích giá trị biên): Boundary value analysis là kỹ thuật tập trung kiểm thử ngay tại các giá trị biên của vùng dữ liệu, vì lỗi thường "ẩn nấp" ở ranh giới. Với ô tuổi 18–60, ta nên test các mốc 17, 18, 60, 61 — đúng những chỗ lập trình viên dễ nhầm dấu "<" với "≤".

Decision Table Testing (Kiểm thử bảng quyết định): Decision table testing là kỹ thuật lập bảng liệt kê các tổ hợp điều kiện và kết quả tương ứng để thiết kế test cho logic nghiệp vụ phức tạp. Nó đặc biệt hữu ích khi có nhiều điều kiện "nếu… thì…" đan xen nhau.

State Transition Testing (Kiểm thử chuyển trạng thái): State transition testing là kỹ thuật kiểm thử dựa trên các trạng thái của hệ thống và những sự kiện làm chuyển trạng thái. Ví dụ: một đơn hàng đi qua các trạng thái Chờ xác nhận → Đang giao → Hoàn tất, và ta kiểm thử từng bước chuyển đó.

Exploratory Testing (Kiểm thử thăm dò): Exploratory testing là cách kiểm thử trong đó tester đồng thời học, thiết kế và thực thi test một cách linh hoạt, không theo kịch bản viết sẵn. Nó dựa nhiều vào kinh nghiệm và sự tò mò để phát hiện những lỗi bất ngờ.

Error Guessing (Đoán lỗi): Error guessing là kỹ thuật dựa trên kinh nghiệm để phán đoán những nơi phần mềm dễ lỗi rồi test thẳng vào đó. Ví dụ: một tester kỳ cựu sẽ thử ngay ô để trống, ký tự đặc biệt hay nhập số âm.

Pesticide Paradox (Nghịch lý thuốc trừ sâu): Pesticide paradox là hiện tượng khi cùng một bộ test được chạy đi chạy lại nhiều lần thì dần mất tác dụng, vì không còn tìm ra lỗi mới — giống như một loại thuốc trừ sâu dùng mãi thì sâu sẽ "lờn thuốc". Cách khắc phục là thường xuyên rà soát, làm mới và bổ sung test case. (Đây là một trong bảy nguyên tắc kiểm thử nền tảng theo chuẩn ISTQB.)

🤖 Nhóm 4 — Công cụ & Automation

Khi đã vững manual, đây là cánh cửa bước sang thế giới tự động hóa.

Test Automation (Kiểm thử tự động): Test automation là việc dùng công cụ và mã lệnh để thực thi test case một cách tự động thay cho thao tác tay, giúp chạy nhanh hơn và lặp lại ổn định. Nó phù hợp nhất cho regression và các kịch bản phải chạy nhiều lần. Muốn đi sâu, hãy xem khóa Playwright Automation.

Test Script (Kịch bản tự động): Test script là đoạn mã ra lệnh cho công cụ tự động thực hiện các bước kiểm thử và kiểm chứng kết quả. Ví dụ: một script Playwright mở trang, nhập dữ liệu, bấm nút và kiểm tra thông báo hiển thị.

Automation Framework (Khung tự động hóa): Automation framework là tập hợp các quy ước, thư viện và cấu trúc giúp viết và bảo trì test tự động một cách nhất quán. Các framework phổ biến hiện nay gồm Playwright, Selenium và Cypress.

Locator / Selector (Bộ định vị phần tử): Locator là cách chỉ cho công cụ tự động biết "phần tử nào trên trang cần thao tác", dựa vào id, class, text hoặc XPath/CSS. Một locator tốt là locator ổn định, ít bị "vỡ" khi giao diện thay đổi.

API Testing (Kiểm thử API): API testing là kiểm thử trực tiếp các điểm giao tiếp dữ liệu giữa những hệ thống ở tầng bên dưới giao diện, thường thực hiện bằng Postman. Nó kiểm tra request/response, mã trạng thái và dữ liệu trả về mà không cần thao tác qua UI. Xem thêm khóa API Testing với Postman.

Assertion (Điểm kiểm chứng): Assertion là câu lệnh trong test tự động dùng để khẳng định rằng kết quả thực tế khớp với kết quả mong đợi; nếu không khớp, test sẽ fail. Ví dụ: assert rằng tiêu đề trang đúng bằng "Trang chủ".

CI/CD (Tích hợp & Triển khai liên tục): CI/CD là quy trình tự động tích hợp code, chạy test và triển khai phần mềm liên tục, thường được dựng bằng GitHub Actions hoặc Jenkins. Test tự động được "treo" vào pipeline để mỗi lần đẩy code đều được kiểm tra ngay lập tức.

Performance Testing (Kiểm thử hiệu năng): Performance testing là kiểm thử tốc độ, độ ổn định và khả năng chịu tải của hệ thống dưới các mức truy cập khác nhau, thường dùng JMeter. Ví dụ: mô phỏng 1.000 người dùng cùng đặt hàng để xem hệ thống có "đứng" hay không. Tìm hiểu thêm tại khóa Performance với JMeter.

Test Coverage (Độ bao phủ kiểm thử): Test coverage là chỉ số đo lường phần trăm phạm vi (yêu cầu, dòng code, nhánh lệnh…) đã được test chạm tới. Coverage cao giúp yên tâm hơn, nhưng đạt 100% coverage không đồng nghĩa là phần mềm hết lỗi.

🚀 Nhóm 5 — Agile & AI Testing

Phần "mới và hot" nhất — nơi tester gặp gỡ AI. 🤝

Agile Testing: Agile testing là cách kiểm thử diễn ra liên tục và song song với phát triển trong từng sprint, thay vì dồn vào cuối dự án. Tester tham gia sớm và cộng tác chặt chẽ với lập trình viên và Product Owner ngay từ khi có yêu cầu.

Shift-left Testing: Shift-left testing là tư duy đưa hoạt động kiểm thử về sớm nhất có thể trong vòng đời phát triển, thay vì đợi code xong mới test. Triết lý đằng sau rất đơn giản: lỗi được bắt càng sớm thì chi phí sửa càng rẻ.

Prompt (Câu lệnh cho AI): Prompt là phần đầu vào bằng ngôn ngữ tự nhiên mà ta cung cấp cho mô hình AI để nhận về phản hồi mong muốn. Với tester, một prompt tốt giúp AI sinh ra test case hoặc dữ liệu test sát với yêu cầu. Đây là kỹ năng trọng tâm của khóa AI cho Tester.

Prompt Engineering (Kỹ thuật viết prompt): Prompt engineering là kỹ năng thiết kế và tinh chỉnh câu lệnh để AI trả về kết quả chính xác, hữu ích và đúng ngữ cảnh. Trong thời đại AI, đây đang dần trở thành kỹ năng "must-have" của tester.

Zero-shot Prompting: Zero-shot prompting là cách ra lệnh cho AI mà không kèm theo ví dụ mẫu nào, để mô hình tự dựa vào kiến thức sẵn có mà trả lời. Ví dụ: "Viết 5 test case cho chức năng đăng nhập" — bạn không đưa trước bất kỳ mẫu nào.

Few-shot Prompting: Few-shot prompting là cách đưa kèm một vài ví dụ mẫu trong prompt để định hướng AI trả lời theo đúng định dạng mong muốn. Ví dụ: cho AI xem 2 test case mẫu rồi yêu cầu nó viết tiếp theo đúng phong cách đó.

Human-in-the-Loop (HITL): Human-in-the-Loop là mô hình trong đó con người vẫn giữ vai trò xem xét, kiểm chứng và phê duyệt kết quả do AI tạo ra, thay vì tin tưởng tuyệt đối vào máy. Trong kiểm thử, tester luôn là người rà soát lại test case và đánh giá rủi ro mà AI đề xuất trước khi đưa vào sử dụng.

Hallucination (Ảo giác AI): Hallucination là hiện tượng AI tạo ra thông tin nghe có vẻ hợp lý nhưng thực chất sai hoặc bịa đặt. Ví dụ: AI "chế" ra một API hay một tên hàm vốn không hề tồn tại — chính là lý do tester cần luôn kiểm chứng đầu ra của AI.

RAG (Retrieval-Augmented Generation): RAG là kỹ thuật cho AI truy xuất dữ liệu thật từ nguồn bên ngoài (tài liệu, cơ sở tri thức) rồi mới sinh ra câu trả lời, giúp giảm bịa đặt và bám sát ngữ cảnh dự án. Ví dụ: AI đọc tài liệu đặc tả của bạn rồi mới gợi ý test case dựa trên đó.

🎓 Kết & bước tiếp theo

Đây là 45 thuật ngữ "xương sống" cho người mới — bạn không cần thuộc lòng, chỉ cần lưu lại trang này để tra mỗi khi gặp từ lạ. Trang sẽ được bổ sung dần theo nhu cầu thực tế.

Sẵn sàng học bài bản? Bắt đầu với khóa Manual Testing cho người mới, rồi tiến lên Playwright Automation và AI cho Tester. Hành trình của một tester giỏi luôn bắt đầu từ những khái niệm vững vàng. 💪