Thuật Ngữ Cốt Lõi (Glossary)

​

Nói Cùng Một Ngôn Ngữ Khi Học Và Review

Glossary này là nơi chốt nghĩa của các thuật ngữ xuất hiện xuyên suốt trong QC System Training. Học viên mới nên dùng khi đọc weekly plan, template, learner guide hoặc mentor feedback mà gặp từ chưa chắc nghĩa. Mentor cũng có thể dùng trang này để giữ wording nhất quán khi review. Nguyên tắc của glossary này là ưu tiên hiểu theo ngữ cảnh làm việc thực tế của QC hệ thống, không chỉ theo định nghĩa sách vở.

​

Cách Dùng Glossary

• Khi gặp một thuật ngữ lạ trong tài liệu, hãy quay lại trang này để chốt nghĩa trước khi đọc tiếp.
• Glossary không thay thế bài học chính; nó chỉ giúp bạn hiểu đúng ngôn ngữ chung để học nhanh hơn.
• Nếu hai thuật ngữ gần nhau, hãy xem mục Dễ nhầm với hoặc bảng Phân biệt nhanh ngay sau nhóm đó.
• Với những term xuất hiện nhiều theo tuần, phần Giải thích thực tế sẽ nói nhẹ nhàng term đó thường gặp ở đâu trong chương trình.

​

A. Nhóm Khái Niệm Nghề QC

​

QC

Định nghĩa ngắn: QC (Quality Control) là hoạt động kiểm tra đầu ra của sản phẩm để phát hiện sai lệch so với requirement, flow hoặc expected behavior.
Giải thích thực tế: Trong chương trình này, QC gắn với việc đọc requirement, thiết kế test, execute, log bug, verify UI/API/DB/workflow và báo cáo risk.
Dễ nhầm với: QA.

​

QA

Định nghĩa ngắn: QA (Quality Assurance) là hoạt động bảo đảm quy trình làm việc có khả năng tạo ra sản phẩm ổn định và giảm lỗi từ sớm.
Giải thích thực tế: QA thường quan tâm process, standard, release discipline, improvement loop và cách team phối hợp; không chỉ xoay quanh một bug cụ thể.
Dễ nhầm với: QC.

​

Tester

Định nghĩa ngắn: Tester là người thực hiện các hoạt động kiểm thử để xác minh chất lượng sản phẩm.
Giải thích thực tế: Trong môi trường nội bộ này, tester có thể làm từ test design, execute test, log bug đến verify API, DB, workflow tùy level và scope.

​

Manual Testing

Định nghĩa ngắn: Manual Testing là kiểm thử bằng thao tác thủ công, không dựa vào script automation để execute case.
Giải thích thực tế: Manual không có nghĩa là làm cảm tính. Bạn vẫn phải có logic test, evidence và expected result rõ. Đây là nền của các tuần đầu chương trình.

​

System QC

Định nghĩa ngắn: System QC là cách làm QC ở mức hệ thống, không chỉ test một màn hình đơn lẻ.
Giải thích thực tế: Nó bao gồm flow nghiệp vụ, role, permission, API, data, workflow và tác động giữa nhiều lớp. Đây là hướng chính của toàn bộ bộ training này.
Dễ nhầm với: UI testing đơn thuần.

​

Quality

Định nghĩa ngắn: Quality là mức độ sản phẩm đáp ứng requirement, nghiệp vụ, dữ liệu, usability và tính ổn định mong đợi.
Giải thích thực tế: Quality không chỉ là “ít bug”. Một hệ thống ít bug bề mặt nhưng sai workflow, sai permission hoặc sai data vẫn là chất lượng kém.

​

Defect

Định nghĩa ngắn: Defect là sai lệch đã được xác định giữa sản phẩm thực tế và kỳ vọng đúng theo requirement, design hoặc rule.
Giải thích thực tế: Trong tài liệu và report chính thức, defect thường là cách gọi trung tính hơn bug, đặc biệt khi nói về lifecycle hoặc quality metrics.
Dễ nhầm với: Bug, Issue.

​

Bug

Định nghĩa ngắn: Bug là lỗi quan sát được khi hệ thống hành xử sai so với expected behavior.
Giải thích thực tế: Đây là từ học viên gặp nhiều ở Tuần 3, Tuần 7, Tuần 8 khi log lỗi, retest và tổng hợp test summary.
Dễ nhầm với: Defect, Issue.

​

Issue

Định nghĩa ngắn: Issue là một vấn đề cần xử lý, nhưng chưa chắc đã là bug phần mềm đã được xác nhận.
Giải thích thực tế: Một issue có thể là bug, câu hỏi requirement, blocker môi trường, thiếu test data hoặc risk chưa rõ.
Dễ nhầm với: Bug thường hẹp hơn issue; defect thường là issue đã xác nhận là sai lệch thật.

​

Phân biệt nhanh: QC vs QA

​

Phân biệt nhanh: Defect vs Bug vs Issue

​

B. Nhóm Quy Trình Phát Triển & Kiểm Thử

​

SDLC

Định nghĩa ngắn: SDLC (Software Development Life Cycle) là vòng đời phát triển phần mềm từ lúc hình thành yêu cầu đến khi release và bảo trì.
Giải thích thực tế: QC cần hiểu SDLC để biết requirement đến từ đâu, bug quay về ai xử lý, và test đang đứng ở đoạn nào của dòng công việc.

​

STLC

Định nghĩa ngắn: STLC (Software Testing Life Cycle) là vòng đời các hoạt động kiểm thử trong một scope cụ thể.
Giải thích thực tế: Trong training, STLC được phản ánh qua việc phân tích requirement, thiết kế test, execute, log bug, retest, summary và closure.

​

Requirement Analysis

Định nghĩa ngắn: Requirement Analysis là bước đọc và bóc tách yêu cầu trước khi viết test hoặc execute test.
Giải thích thực tế: Đây là năng lực nền của Tuần 1 và Tuần 8. QC không chỉ đọc câu chữ, mà phải nhìn ra flow, rule, permission, workflow, risk và assumption cần chốt.

​

Test Planning

Định nghĩa ngắn: Test Planning là bước xác định phạm vi, chiến lược, nguồn lực và cách tổ chức hoạt động test.
Giải thích thực tế: Ở mức learner, test planning có thể xuất hiện dưới dạng scope test, regression scope, smoke checklist hoặc plan cho mini project.

​

Test Execution

Định nghĩa ngắn: Test Execution là bước chạy test theo scenario, case hoặc checklist để thu kết quả thực tế.
Giải thích thực tế: Execute test không phải chỉ bấm theo steps. Bạn phải quan sát result, check evidence, verify data và quyết định có log bug hay không.

​

Defect Lifecycle

Định nghĩa ngắn: Defect Lifecycle là vòng đời của một lỗi từ lúc được log đến lúc được đóng hoặc mở lại.
Giải thích thực tế: Dạng đơn giản thường là: New -> Assigned -> Fixed -> Retest -> Closed / Reopened. QC cần hiểu để biết khi nào retest, khi nào reopen.

​

Test Closure

Định nghĩa ngắn: Test Closure là bước kết thúc một vòng test bằng cách tổng hợp kết quả, risk, phạm vi đã test và điểm còn tồn đọng.
Giải thích thực tế: Trong training, năng lực này thể hiện rõ ở Tuần 7 và Tuần 8 qua test summary report và final summary.

​

C. Nhóm Test Design

​

Test Scenario

Định nghĩa ngắn: Test Scenario là mô tả các hướng kiểm thử chính ở mức nghiệp vụ hoặc flow.
Giải thích thực tế: Scenario giúp mentor thấy bạn đang bao phủ phần nào của scope, trước khi đi vào từng bước chi tiết. Đây là trọng tâm lớn của Tuần 2.
Dễ nhầm với: Test Case, Test Checklist.

​

Test Case

Định nghĩa ngắn: Test Case là hướng dẫn kiểm thử chi tiết có thể execute lại được.
Giải thích thực tế: Một test case tốt thường có precondition, steps và expected result đủ rõ để người khác chạy lại mà không phải đoán.
Dễ nhầm với: Scenario, Checklist.

​

Test Checklist

Định nghĩa ngắn: Test Checklist là danh sách các điểm cần rà soát nhanh ở mức khái quát.
Giải thích thực tế: Checklist phù hợp khi scope đơn giản, lặp lại hoặc cần rà nhanh như smoke/sanity; không phù hợp để thay test case trong bài có nhiều rule.
Dễ nhầm với: Scenario, Test Case.

​

Test Data

Định nghĩa ngắn: Test Data là dữ liệu, account, record hoặc input được chuẩn bị để chạy test.
Giải thích thực tế: Test data tốt giúp bạn reproduce đúng case, retest đúng bug và đối chiếu UI/API/DB nhất quán. Tuần 7 và Tuần 8 dùng nhiều khái niệm này.

​

Positive Test

Định nghĩa ngắn: Positive Test là kiểm thử với dữ liệu và điều kiện hợp lệ để xác minh hệ thống chạy đúng đường chuẩn.
Giải thích thực tế: Đây là nơi bạn xác nhận happy path hoạt động ổn trước khi đi sâu vào negative hoặc edge cases.

​

Negative Test

Định nghĩa ngắn: Negative Test là kiểm thử với dữ liệu hoặc hành động không hợp lệ để xác minh hệ thống chặn đúng.
Giải thích thực tế: Negative test rất quan trọng với validation, permission, API auth và workflow invalid action.

​

Edge Case

Định nghĩa ngắn: Edge Case là tình huống ở rìa điều kiện sử dụng bình thường nhưng vẫn có khả năng xảy ra.
Giải thích thực tế: Đây thường là nơi bug dễ lộ hơn happy path, ví dụ dữ liệu rất dài, state đặc biệt, list rỗng hoặc transition hiếm.

​

Boundary Value

Định nghĩa ngắn: Boundary Value là kỹ thuật kiểm tra các giá trị sát ngưỡng cho phép.
Giải thích thực tế: Ví dụ field cho phép 1-50 ký tự thì nên test 0, 1, 50, 51. Đây là kỹ thuật nền ở Tuần 2.

​

Equivalence Partitioning

Định nghĩa ngắn: Equivalence Partitioning là kỹ thuật chia input thành các nhóm tương đương để giảm số test nhưng vẫn giữ ý nghĩa bao phủ.
Giải thích thực tế: Thay vì test mọi giá trị, QC chọn đại diện cho nhóm hợp lệ và nhóm không hợp lệ.

​

Decision Table

Định nghĩa ngắn: Decision Table là cách biểu diễn điều kiện và kết quả mong đợi theo dạng bảng quyết định.
Giải thích thực tế: Nó hữu ích khi nhiều rule kết hợp với nhau, ví dụ quyền theo role + state + condition.

​

State Transition

Định nghĩa ngắn: State Transition là hành vi thay đổi của hệ thống theo từng trạng thái và hành động.
Giải thích thực tế: Khái niệm này xuất hiện sớm ở Tuần 2 như kỹ thuật test design, và trở thành trọng tâm ở Tuần 6 khi test workflow.
Dễ nhầm với: Status, State Transition Matrix.

​

Phân biệt nhanh: Scenario vs Test Case vs Checklist

​

D. Nhóm UI / Form / List Testing

​

Label

Định nghĩa ngắn: Label là tên hiển thị cho field, nút hoặc vùng thông tin trên giao diện.
Giải thích thực tế: QC nhìn label để kiểm tra nghĩa, ngôn ngữ, tính nhất quán và xem user có hiểu phải nhập hoặc bấm gì không.

​

Placeholder

Định nghĩa ngắn: Placeholder là đoạn gợi ý hiển thị trong ô input trước khi user nhập dữ liệu.
Giải thích thực tế: Placeholder chỉ là gợi ý, không thay thế label. Đây là lỗi UX rất hay bị nhầm khi review form.
Dễ nhầm với: Label.

​

Required Field

Định nghĩa ngắn: Required Field là trường bắt buộc phải có dữ liệu trước khi submit hoặc hoàn tất thao tác.
Giải thích thực tế: Khi test form, QC cần kiểm cả dấu hiệu trên UI lẫn hành vi chặn thật khi field này để trống.

​

Validation

Định nghĩa ngắn: Validation là lớp kiểm tra dữ liệu đầu vào có đúng format, đúng điều kiện cơ bản và đúng tính hợp lệ kỹ thuật hay không.
Giải thích thực tế: Ví dụ email đúng định dạng chưa, field bắt buộc có bỏ trống không, ngày nhập có đúng format không.
Dễ nhầm với: Business Rule.

​

Business Rule

Định nghĩa ngắn: Business Rule là quy tắc nghiệp vụ quyết định dữ liệu hoặc hành động có được chấp nhận trong bối cảnh thực tế hay không.
Giải thích thực tế: Ví dụ mã nhân viên không được trùng, người chưa có quyền không được approve, đơn nghỉ phép không được submit khi vượt quota.
Dễ nhầm với: Validation.

​

Error Message

Định nghĩa ngắn: Error Message là thông báo lỗi hiển thị cho user khi hệ thống chặn dữ liệu hoặc hành động không hợp lệ.
Giải thích thực tế: QC không chỉ kiểm “có message hay không”, mà còn kiểm message đúng lúc, đúng nội dung, đúng field và dễ hiểu không.

​

Empty State

Định nghĩa ngắn: Empty State là trạng thái giao diện khi không có dữ liệu để hiển thị.
Giải thích thực tế: List rỗng không nên nhìn như màn hình hỏng. QC cần kiểm message, CTA và hành vi filter/search khi trả về 0 record.

​

Loading State

Định nghĩa ngắn: Loading State là trạng thái giao diện trong lúc hệ thống đang lấy dữ liệu hoặc xử lý thao tác.
Giải thích thực tế: Đây là chỗ QC kiểm spinner, skeleton, disable button tạm thời và tránh double submit.

​

Disabled State

Định nghĩa ngắn: Disabled State là trạng thái một control xuất hiện nhưng không thể thao tác được.
Giải thích thực tế: QC cần phân biệt disabled vì validation, disabled vì permission hay disabled vì chờ xử lý.

​

Pagination

Định nghĩa ngắn: Pagination là cơ chế chia dữ liệu thành nhiều trang thay vì hiển thị hết một lần.
Giải thích thực tế: QC thường kiểm page size, total count, chuyển trang, giữ filter/sort khi đổi trang và edge case trang cuối.

​

Filter

Định nghĩa ngắn: Filter là cơ chế thu hẹp dữ liệu hiển thị theo điều kiện chọn trước.
Giải thích thực tế: Lỗi filter thường không nằm ở UI control, mà ở việc logic lọc sai, reset sai hoặc không khớp DB/API.

​

Sort

Định nghĩa ngắn: Sort là cơ chế sắp xếp dữ liệu theo một tiêu chí và thứ tự xác định.
Giải thích thực tế: QC cần nhìn rõ sort theo field nào, tăng hay giảm, sort mặc định là gì và có ổn qua các page dữ liệu hay không.

​

UX Consistency

Định nghĩa ngắn: UX Consistency là mức độ nhất quán của giao diện và hành vi sử dụng giữa các màn hình, module hoặc trạng thái.
Giải thích thực tế: Đây không phải chỉ là “đẹp”. QC dùng khái niệm này để bắt các sai lệch như wording, button position, feedback pattern hoặc flow dùng không thống nhất.

​

Phân biệt nhanh: Validation vs Business Rule

​

E. Nhóm Bug Reporting

​

Bug Report

Định nghĩa ngắn: Bug Report là artifact mô tả một lỗi đủ rõ để người khác tái hiện, hiểu impact và xử lý.
Giải thích thực tế: Trong chương trình, đây là output trọng tâm của Tuần 3 và là năng lực bắt buộc ở Tuần 8.
Dễ nhầm với: Issue note chung chung.

​

Severity

Định nghĩa ngắn: Severity là mức độ nghiêm trọng của lỗi đối với chức năng, dữ liệu, nghiệp vụ hoặc user experience.
Giải thích thực tế: Severity trả lời câu hỏi “lỗi này nặng tới đâu nếu tồn tại”. Nó phản ánh impact, không phản ánh dev fix nhanh hay chậm.
Dễ nhầm với: Priority.

​

Priority

Định nghĩa ngắn: Priority là mức ưu tiên xử lý của team đối với một lỗi hoặc công việc.
Giải thích thực tế: Priority trả lời câu hỏi “nên xử lý cái này trước hay sau”. Một bug severity không quá cao vẫn có thể priority cao vì chạm release hoặc critical path.
Dễ nhầm với: Severity.

​

Preconditions

Định nghĩa ngắn: Preconditions là các điều kiện phải có trước khi lỗi hoặc test case có thể xảy ra đúng cách.
Giải thích thực tế: Nếu bug chỉ xuất hiện với role, state, data hoặc môi trường đặc biệt, mà không ghi preconditions, dev rất dễ reproduce sai.

​

Steps to Reproduce

Định nghĩa ngắn: Steps to Reproduce là các bước tái hiện lỗi theo thứ tự đủ rõ để người khác làm lại.
Giải thích thực tế: Steps tốt phải ngắn, đúng thứ tự và không nhảy ý. Đây là phần khiến bug “dùng được” hay “khó dùng”.

​

Actual Result

Định nghĩa ngắn: Actual Result là hành vi thực tế hệ thống đang trả ra khi lỗi xảy ra.
Giải thích thực tế: Nó phải mô tả đúng cái đang xảy ra, không xen cảm nhận cá nhân và không nhảy thẳng sang nguyên nhân.

​

Expected Result

Định nghĩa ngắn: Expected Result là hành vi đúng mà hệ thống lẽ ra phải có theo requirement, rule hoặc design.
Giải thích thực tế: Expected tốt thường nói rõ UI message, state hoặc data outcome, không viết kiểu “hệ thống hoạt động đúng”.

​

Evidence

Định nghĩa ngắn: Evidence là bằng chứng đi kèm để hỗ trợ việc hiểu và tái hiện bug.
Giải thích thực tế: Evidence có thể là screenshot, video, log, request/response, query hoặc dữ liệu record. Evidence tốt giúp giảm vòng hỏi lại.

​

Retest

Định nghĩa ngắn: Retest là việc chạy lại bug cũ sau khi dev báo fixed để xác minh lỗi đã được sửa đúng.
Giải thích thực tế: Retest phải bám lại đúng precondition, role, state và data của bug ban đầu; không chỉ test đại khái một lần.
Dễ nhầm với: Regression.

​

Reopen

Định nghĩa ngắn: Reopen là mở lại bug đã từng được đánh dấu fixed/closed nhưng khi retest vẫn còn lỗi hoặc fix chưa đúng.
Giải thích thực tế: QC reopen khi có cơ sở rõ ràng, không phải vì cảm giác chưa yên tâm. Cần mô tả rõ bug còn lại nằm ở đâu.

​

Phân biệt nhanh: Severity vs Priority

​

F. Nhóm API Testing

​

API

Định nghĩa ngắn: API (Application Programming Interface) là giao diện cho phép các hệ thống hoặc lớp khác nhau trao đổi dữ liệu và hành động với nhau.
Giải thích thực tế: Với QC hệ thống, test API giúp nhìn được data flow sau UI, verify auth/permission và tách lỗi UI với lỗi backend. Đây là trọng tâm của Tuần 4.

​

Endpoint

Định nghĩa ngắn: Endpoint là điểm truy cập cụ thể của một API, thường gắn với URL và method.
Giải thích thực tế: Ví dụ GET /employees và POST /employees là hai endpoint khác nhau dù cùng một resource.

​

Request

Định nghĩa ngắn: Request là dữ liệu và thông tin client gửi lên server khi gọi API.
Giải thích thực tế: QC cần đọc request để hiểu mình đang gửi method gì, header gì, body gì và input đó có khớp thao tác UI hay không.

​

Response

Định nghĩa ngắn: Response là dữ liệu và trạng thái server trả về sau khi nhận request.
Giải thích thực tế: Đừng chỉ nhìn status code. QC phải đọc cả response body, message, data shape và business meaning.

​

Header

Định nghĩa ngắn: Header là phần metadata đi kèm request hoặc response.
Giải thích thực tế: Header thường chứa token, content type hoặc các thông tin điều khiển cách server hiểu request.

​

Query Parameter

Định nghĩa ngắn: Query Parameter là tham số nằm sau dấu ? trong URL, thường dùng để lọc, sort, search hoặc phân trang.
Giải thích thực tế: QC hay gặp query param khi test list API, pagination, filter và report API.

​

Path Parameter

Định nghĩa ngắn: Path Parameter là biến nằm trực tiếp trong đường dẫn API, thường dùng để chỉ resource cụ thể.
Giải thích thực tế: Ví dụ /employees/{id} dùng id làm path param để lấy chi tiết một record.

​

Request Body

Định nghĩa ngắn: Request Body là phần payload gửi trong request, thường dùng với POST, PUT, PATCH.
Giải thích thực tế: QC cần đối chiếu request body với input UI để xem dữ liệu map có đúng không.

​

Response Body

Định nghĩa ngắn: Response Body là phần dữ liệu chính server trả về trong response.
Giải thích thực tế: Một API có thể trả 200 nhưng response body vẫn sai field, sai value, sai total count hoặc sai business meaning.

​

Status Code

Định nghĩa ngắn: Status Code là mã HTTP cho biết kết quả tổng quát của request.
Giải thích thực tế: Đây là tín hiệu đầu tiên, không phải kết luận cuối cùng. QC phải đọc thêm response body và đối chiếu với kỳ vọng nghiệp vụ.

​

Authentication

Định nghĩa ngắn: Authentication là quá trình xác thực bạn là ai.
Giải thích thực tế: Trong test API, authentication thường gắn với token, session hoặc credential hợp lệ trước khi gọi API.
Dễ nhầm với: Authorization.

​

Authorization

Định nghĩa ngắn: Authorization là quá trình xác định bạn được phép làm gì sau khi đã được xác thực.
Giải thích thực tế: Một user có token hợp lệ vẫn có thể bị chặn hành động vì không đủ quyền theo role hoặc scope.
Dễ nhầm với: Authentication.

​

401 Unauthorized

Định nghĩa ngắn: 401 là mã phản ánh request chưa được xác thực hợp lệ.
Giải thích thực tế: Thiếu token, token sai, token hết hạn hoặc auth header không đúng thường dẫn tới 401.
Dễ nhầm với: 403 Forbidden.

​

403 Forbidden

Định nghĩa ngắn: 403 là mã phản ánh request đã được xác thực nhưng không được phép làm hành động đó.
Giải thích thực tế: Đây là lỗi quyền, không phải lỗi đăng nhập. Tuần 4 và Tuần 6 dùng khái niệm này rất nhiều.
Dễ nhầm với: 401 Unauthorized.

​

CRUD API

Định nghĩa ngắn: CRUD API là nhóm API phục vụ Create, Read, Update, Delete dữ liệu.
Giải thích thực tế: Đây là lớp API cơ bản nhất để learner làm quen trước khi nối sang DB verification và workflow testing.

​

Phân biệt nhanh: Authentication vs Authorization

​

Phân biệt nhanh: 401 vs 403

​

G. Nhóm Dữ Liệu & Database Verification

​

Database

Định nghĩa ngắn: Database là nơi hệ thống lưu trữ dữ liệu để phục vụ nghiệp vụ và hiển thị.
Giải thích thực tế: Với QC, database không phải nơi để “lập trình”, mà là nơi để verify record, field, state và data mapping. Đây là trọng tâm của Tuần 5.

​

Record

Định nghĩa ngắn: Record là một đơn vị dữ liệu hoàn chỉnh đại diện cho một đối tượng nghiệp vụ.
Giải thích thực tế: Ví dụ một nhân viên, một đơn nghỉ phép, một ticket đều có thể được xem là một record.
Dễ nhầm với: Row.

​

Field

Định nghĩa ngắn: Field là một thuộc tính dữ liệu của record.
Giải thích thực tế: Ở mức QC, bạn thường nói field email, field status, field deleted_at khi verify data hoặc bug.
Dễ nhầm với: Column.

​

Row

Định nghĩa ngắn: Row là một dòng dữ liệu trong bảng database.
Giải thích thực tế: Trong thực hành QC, record và row đôi khi được dùng gần nghĩa nhau, nhưng row nhấn mạnh góc nhìn table.
Dễ nhầm với: Record.

​

Column

Định nghĩa ngắn: Column là cột trong bảng database, chứa cùng một loại dữ liệu cho nhiều row.
Giải thích thực tế: Column là góc nhìn schema/table; field thường là cách nói gần với nghiệp vụ hoặc output.

​

Query

Định nghĩa ngắn: Query là câu lệnh dùng để lấy, lọc hoặc tổng hợp dữ liệu từ database.
Giải thích thực tế: Trong chương trình, query là công cụ verify dữ liệu sau create/update/delete, không phải nơi khoe cú pháp khó.

​

SELECT

Định nghĩa ngắn: SELECT là câu lệnh dùng để lấy dữ liệu từ database.
Giải thích thực tế: Đây là lệnh cơ bản nhất của Tuần 5 vì QC chủ yếu cần đọc và verify data.

​

WHERE

Định nghĩa ngắn: WHERE là phần điều kiện dùng để lọc dữ liệu trong query.
Giải thích thực tế: Một query đúng cú pháp nhưng WHERE quá rộng vẫn có thể khiến QC kiểm nhầm record.

​

JOIN

Định nghĩa ngắn: JOIN là cách nối dữ liệu từ nhiều bảng có liên quan với nhau.
Giải thích thực tế: JOIN rất hữu ích khi một màn hình hiển thị dữ liệu đến từ nhiều table hoặc nhiều lớp mapping.
Dễ nhầm với: việc chỉ query từng bảng riêng lẻ.

​

COUNT

Định nghĩa ngắn: COUNT là hàm đếm số lượng record thỏa điều kiện.
Giải thích thực tế: QC dùng COUNT để check duplicate, số record active, số record sau filter hoặc sau thao tác tạo/xóa.

​

Soft Delete

Định nghĩa ngắn: Soft Delete là xóa mềm: record không mất hẳn khỏi database, mà được đánh dấu là đã xóa.
Giải thích thực tế: Dấu hiệu thường gặp là deleted_at, is_deleted hoặc status chuyển sang inactive.
Dễ nhầm với: Hard Delete.

​

Hard Delete

Định nghĩa ngắn: Hard Delete là xóa cứng: record bị loại khỏi database thật sự.
Giải thích thực tế: Sau hard delete, query theo key cũ sẽ không còn row đó nữa.
Dễ nhầm với: Soft Delete.

​

Audit Field

Định nghĩa ngắn: Audit Field là các field dùng để theo dõi lịch sử thay đổi dữ liệu.
Giải thích thực tế: Ví dụ created_at, updated_at, created_by, updated_by, deleted_at. QC dùng chúng để verify thao tác có ghi nhận đúng không.

​

Data Mapping

Định nghĩa ngắn: Data Mapping là mối liên hệ giữa dữ liệu ở UI, API và database.
Giải thích thực tế: Một value trên UI có thể được format khác với raw value trong DB. QC cần hiểu mapping để tránh kết luận sai.

​

Phân biệt nhanh: Soft Delete vs Hard Delete

​

H. Nhóm Workflow & Permission

​

Workflow

Định nghĩa ngắn: Workflow là tập luật mô tả một nghiệp vụ đi qua những trạng thái nào và bằng hành động nào.
Giải thích thực tế: Đây là “logic sống” của hệ thống doanh nghiệp. Tuần 6 dùng khái niệm này để test các luồng như Draft -> Submitted -> Approved/Rejected.
Dễ nhầm với: Permission.

​

State

Định nghĩa ngắn: State là trạng thái logic mà record đang đứng trong workflow.
Giải thích thực tế: State quyết định action nào hợp lệ, ai được làm gì và bước tiếp theo sẽ đi đâu.
Dễ nhầm với: Status.

​

Status

Định nghĩa ngắn: Status là trạng thái hiển thị hoặc trạng thái tóm tắt mà user nhìn thấy trên UI hoặc report.
Giải thích thực tế: Trong hệ thống đơn giản, status và state có thể trùng nhau. Trong hệ thống phức tạp, state là logic nội bộ còn status là cách biểu diễn ra ngoài.
Dễ nhầm với: State.

​

Transition

Định nghĩa ngắn: Transition là sự chuyển từ state này sang state khác khi một action được thực hiện và điều kiện phù hợp.
Giải thích thực tế: QC test transition để bắt lỗi skip state, sai next state hoặc thiếu điều kiện chặn.

​

Action

Định nghĩa ngắn: Action là hành động tác động lên record hoặc workflow.
Giải thích thực tế: Ví dụ Submit, Approve, Reject, Cancel, Resubmit. Một action luôn nên được nhìn cùng state và role.

​

Approver

Định nghĩa ngắn: Approver là người hoặc role có quyền duyệt một bước trong workflow.
Giải thích thực tế: Trong workflow nhiều tầng, approver đúng hay sai là một phần rất quan trọng của permission testing.

​

Permission

Định nghĩa ngắn: Permission là quy tắc xác định ai được làm gì, thấy gì hoặc sửa gì trong hệ thống.
Giải thích thực tế: Permission không chỉ là “thấy nút hay không”. Nó còn là chặn route, chặn API và chặn hành động theo role/scope.
Dễ nhầm với: Workflow.

​

Role

Định nghĩa ngắn: Role là nhóm quyền đại diện cho một loại người dùng trong hệ thống.
Giải thích thực tế: Ví dụ Employee, Manager, Admin, Viewer. Role thường là nền để map permission.

​

Scope

Định nghĩa ngắn: Scope là phạm vi dữ liệu hoặc phạm vi hành động mà role được phép chạm tới.
Giải thích thực tế: Cùng là role Manager nhưng scope có thể là team của mình, không phải toàn công ty.

​

UI Permission

Định nghĩa ngắn: UI Permission là lớp kiểm soát quyền thể hiện ở giao diện.
Giải thích thực tế: Ví dụ ẩn nút, disable control, chặn route hoặc không hiển thị menu. QC phải kiểm nhưng không được dừng ở đó.
Dễ nhầm với: API Permission.

​

API Permission

Định nghĩa ngắn: API Permission là lớp kiểm soát quyền ở backend hoặc API layer.
Giải thích thực tế: Đây mới là lớp chặn thật. Nếu UI ẩn nút nhưng API vẫn cho gọi action, hệ thống vẫn đang hở quyền.
Dễ nhầm với: UI Permission.

​

Role-State-Action Matrix

Định nghĩa ngắn: Role-State-Action Matrix là ma trận cho biết role nào được làm action nào ở state nào.
Giải thích thực tế: Đây là công cụ rất mạnh của Tuần 6 vì nó nối workflow và permission thành một artifact có thể review và execute.

​

State Transition Matrix

Định nghĩa ngắn: State Transition Matrix là ma trận mô tả current state, action, next state và điều kiện chuyển.
Giải thích thực tế: QC dùng nó để kiểm đường đi hợp lệ, invalid action, skip state và các condition chặn.

​

Phân biệt nhanh: Workflow vs Permission

​

Phân biệt nhanh: State vs Status

​

I. Nhóm Test Execution Nâng Cao

​

End-to-End Testing

Định nghĩa ngắn: End-to-End Testing là kiểm thử một hành trình nghiệp vụ xuyên nhiều bước, nhiều màn hình hoặc nhiều lớp hệ thống.
Giải thích thực tế: E2E không phải chỉ là ghép nhiều màn hình. Nó là kiểm logic của cả hành trình từ input đến data/state cuối cùng. Đây là trọng tâm của Tuần 7.

​

Smoke Test

Định nghĩa ngắn: Smoke Test là bộ kiểm nhanh các điểm sống còn để xem build có đủ ổn định để test tiếp hay không.
Giải thích thực tế: Smoke phải ngắn, chạm critical path và không biến thành full regression.
Dễ nhầm với: Sanity Test.

​

Sanity Test

Định nghĩa ngắn: Sanity Test là kiểm tra nhanh nhưng tập trung hơn vào một vùng vừa thay đổi để xem logic chính của vùng đó còn ổn hay không.
Giải thích thực tế: Sanity thường hẹp hơn smoke và bám sát change cụ thể sau fix hoặc after deploy nhỏ.
Dễ nhầm với: Smoke Test.

​

Regression Test

Định nghĩa ngắn: Regression Test là kiểm thử các vùng có nguy cơ bị ảnh hưởng sau khi có thay đổi, fix hoặc merge.
Giải thích thực tế: Regression scope nên chọn theo impact, shared component, critical flow và risk; không nên chọn theo cảm giác.
Dễ nhầm với: Retest.

​

Retest

Định nghĩa ngắn: Retest là kiểm lại đúng bug cũ sau khi dev báo fixed để xác minh fix đó có đúng không.
Giải thích thực tế: Trong execution cycle, retest đi sau bug fix và thường đi kèm regression, nhưng không thay thế regression.
Dễ nhầm với: Regression Test.

​

Critical Path

Định nghĩa ngắn: Critical Path là luồng nghiệp vụ quan trọng nhất, nếu hỏng sẽ ảnh hưởng trực tiếp đến khả năng dùng hệ thống.
Giải thích thực tế: Smoke, regression và final summary thường phải nhìn rõ critical path trước khi chọn scope.

​

Risk

Định nghĩa ngắn: Risk là khả năng xảy ra vấn đề và mức ảnh hưởng nếu vấn đề đó xảy ra.
Giải thích thực tế: Trong QC, risk không chỉ là bug đã thấy. Nó còn là vùng chưa test đủ, assumption chưa chắc hoặc dependency chưa ổn.

​

Risk Statement

Định nghĩa ngắn: Risk Statement là câu kết luận ngắn mô tả rủi ro đáng chú ý sau một vòng test.
Giải thích thực tế: Đây là phần rất quan trọng của Tuần 7 và Tuần 8 vì lead không chỉ cần biết defect count, mà cần biết nếu release thì có gì đáng lo.

​

Test Summary Report

Định nghĩa ngắn: Test Summary Report là báo cáo tổng hợp phạm vi test, kết quả, defect, risk và khuyến nghị sau một vòng test.
Giải thích thực tế: Report tốt phải usable cho mentor, lead hoặc PM ra quyết định; không chỉ là bảng số liệu pass/fail.

​

Phân biệt nhanh: Retest vs Regression

​

Phân biệt nhanh: Smoke vs Sanity

​

J. Nhóm Learner / Mentor Guide

​

Deliverable

Định nghĩa ngắn: Deliverable là output mà learner phải nộp cho một ngày, một tuần hoặc cuối khóa.
Giải thích thực tế: Deliverable có thể là note, sheet, matrix, bug set, collection, summary hoặc package tổng hợp. Trong bộ training, deliverable luôn gắn với expectation review.

​

Rubric

Định nghĩa ngắn: Rubric là bộ tiêu chí chấm chất lượng output theo các trục cụ thể.
Giải thích thực tế: Rubric giúp mentor chấm nhất quán và giúp learner hiểu “bài tốt” trông như thế nào, thay vì chỉ nghe góp ý cảm tính.

​

Feedback

Định nghĩa ngắn: Feedback là nhận xét có chủ đích nhằm chỉ ra điểm mạnh, điểm yếu và hướng cải thiện cho output.
Giải thích thực tế: Trong training này, feedback có giá trị khi learner biến nó thành hành động sửa bài và checklist tránh lỗi lặp.

​

Self-review

Định nghĩa ngắn: Self-review là bước learner tự soi output trước khi gửi mentor.
Giải thích thực tế: Self-review không thay mentor review, nhưng nó loại bớt lỗi cơ bản để mentor tập trung vào logic, coverage và maturity của bài.

​

Learning Log

Định nghĩa ngắn: Learning Log là nơi learner ghi lại điều đã hiểu rõ hơn, insight và nguyên tắc muốn mang sang bài sau.
Giải thích thực tế: Nó giúp việc học không bị rời rạc giữa các tuần và tạo ra đường cong tiến bộ có thể nhìn thấy.

​

Mistake Log

Định nghĩa ngắn: Mistake Log là nơi learner ghi lại lỗi lặp, feedback đáng nhớ, lỗi gốc và cách tránh ở lần sau.
Giải thích thực tế: Đây là công cụ rất mạnh để giảm việc bị góp ý cùng một lỗi qua nhiều tuần.
Dễ nhầm với: Learning Log.

​

Readiness

Định nghĩa ngắn: Readiness là mức sẵn sàng của learner để nhận task thật với mức giám sát phù hợp.
Giải thích thực tế: Readiness không chỉ nhìn vào số file nộp, mà nhìn vào logic, usability, defense quality và khả năng làm việc có cấu trúc. Thuật ngữ này xuất hiện nhiều ở Tuần 8 và phần graduation.

​

Usable Output

Định nghĩa ngắn: Usable Output là output đủ rõ, đủ logic và đủ dùng để người khác review, execute hoặc ra quyết định.
Giải thích thực tế: Một file đẹp nhưng mơ hồ chưa phải usable. Một output usable thường có mục tiêu rõ, logic đủ và ít làm người đọc bị mắc kẹt.

​

Enough File vs Enough to Use

Định nghĩa ngắn: Enough File vs Enough to Use là cách phân biệt giữa việc “nộp đủ hình thức” và “nộp đủ chất lượng để dùng thật”.
Giải thích thực tế: Đây là triết lý xuyên suốt learner guide: đủ cột, đủ file, đủ sheet chưa đồng nghĩa với đủ để review, execute, handover hoặc defense.
Dễ nhầm với: hoàn thành bài trên bề mặt.

​

Kết Thúc Trang

Glossary này nên được dùng như một điểm neo chung cho toàn bộ bộ docs training/. Nếu bạn là learner, hãy quay lại đây bất cứ khi nào thấy một term quen mà chưa chắc mình đang hiểu đúng. Nếu bạn là mentor, đây là nơi phù hợp để giữ wording review nhất quán giữa các tuần, template và rubric. Mục tiêu của trang này không phải là dạy thay bài học chính, mà là giúp cả người học lẫn người review nói cùng một ngôn ngữ đủ rõ để làm việc.