Trang chủ
QA Learning Hub
Chương 21 · Thuật Ngữ QA
Chương 21 Reference

Thuật Ngữ QA A–Z

Từ điển 70+ thuật ngữ QA quan trọng, acronyms và tools reference — tra cứu nhanh khi cần.

🔤 A – F
  • A/B TestingSo sánh 2 phiên bản (A vs B) với 2 nhóm user khác nhau để đo hiệu quả. QA verify cả 2 variants hoạt động đúng và data tracking accurate.
  • AC (Acceptance Criteria)Điều kiện cụ thể mà tính năng phải thỏa mãn để được stakeholder chấp nhận. Nền tảng để QA viết test cases. Format: Given/When/Then.
  • Ad-hoc TestingTest không có kế hoạch, dựa vào intuition và experience. Khác exploratory: không có session charter hay time-boxing.
  • Agile TestingTesting approach trong Agile: continuous, parallel với development, short cycles (sprints), collaboration over documentation.
  • API (Application Programming Interface)Interface cho phép các software components giao tiếp. REST API là phổ biến nhất. QA test API trực tiếp với Postman trước khi UI được build.
  • Automation Coverage% test cases được automated. Metric quan trọng cho team growth. Không phải 100% là goal — chọn đúng cases để automate.
  • BDD (Behavior-Driven Development)Development approach dùng natural language (Given/When/Then) để define behavior. Tools: Cucumber, SpecFlow. QA và BA cùng viết scenarios.
  • Black-box TestingTest không biết internal code — chỉ test từ góc độ input/output. Đây là approach chính của manual QA. Techniques: EP, BVA, Decision Table.
  • Boundary Value Analysis (BVA)Test tại giá trị biên: min-1, min, min+1, max-1, max, max+1. Lỗi thường xảy ra ở ranh giới điều kiện.
  • Bug / DefectDeviation từ expected behavior. Thuật ngữ "bug" thường dùng informally, "defect" là formal term trong documentation.
  • BuildCompiled/packaged version của software sẵn sàng để test. QA nhận "build" từ dev/CI sau mỗi deployment.
  • CI/CD (Continuous Integration/Delivery)Practice: developers merge code thường xuyên, automated build/test chạy sau mỗi merge. QA integrate automated tests vào CI pipeline.
  • Code Coverage% lines/branches của source code được thực thi bởi automated tests. Metric của Dev (unit tests), không phải QA. High coverage ≠ good test quality.
  • Defect DensitySố defects per unit (per feature, per KLOC). High density → risky area, cần thêm testing và code review.
  • Defect LeakageBugs tìm được sau khi release (production bugs) mà đáng lẽ nên tìm được trong testing phase. Metric quan trọng cho QA effectiveness.
  • E2E TestingEnd-to-End Testing: test complete user workflow từ đầu đến cuối, verify toàn bộ system integration. Thường automated với Playwright/Selenium.
  • Entry CriteriaĐiều kiện phải đạt được trước khi bắt đầu testing phase (e.g., build stable, env ready, requirements signed off).
  • Equivalence Partitioning (EP)Kỹ thuật chia input thành groups (partitions) có behavior tương tự. Test đại diện từ mỗi partition thay vì test mọi value.
  • Exit CriteriaĐiều kiện phải đạt được để kết thúc testing (e.g., pass rate ≥ 90%, 0 Critical open). Khác exit criteria của STLC phase vs sprint.
  • Exploratory TestingSimultaneous learning, test design, and test execution. Không theo predefined script. Hiệu quả tìm unexpected bugs. Thường có session charter (goal và time limit).
  • False NegativeTest passes nhưng có bug (miss). Nguy hiểm hơn false positive. Nguyên nhân: weak assertions, wrong test logic, insufficient coverage.
  • False PositiveTest fails nhưng không có bug thực sự. Thường do test code issue (flaky), environment issue, test data issue. Erodes trust in test suite.
  • Flaky TestAutomated test cho kết quả không nhất quán (sometimes pass, sometimes fail). Major problem — erodes confidence. Must be fixed or quarantined.
  • Functional TestingTesting that verifies software functions according to requirements. Checks WHAT the system does. Contrast with Non-Functional (HOW WELL it does it).
🔤 G – M
  • Happy PathTest case theo luồng chính khi mọi thứ hoạt động đúng như expected. Luôn test happy path trước, sau đó negative/edge cases.
  • IDOR (Insecure Direct Object Reference)Security vulnerability: thay đổi ID trong URL/request để truy cập data của user khác. Test: change user_id=123 → user_id=124, verify 403 returned.
  • Impact AnalysisPhân tích phạm vi ảnh hưởng của thay đổi code. Giúp QA quyết định scope regression testing. "This change touches payment module — need to regression test entire checkout."
  • Integration TestingTesting interaction giữa components/services. Checks that integrated units work together correctly. More scope than unit, less than system.
  • Intermittent BugBug không consistently reproducible. Nguyên nhân thường: race condition, timing issues, environment-specific. Document frequency và conditions khi xảy ra.
  • ISO 25010International standard cho software quality model. 8 quality characteristics: Functional Suitability, Performance, Compatibility, Usability, Reliability, Security, Maintainability, Portability.
  • ISTQBInternational Software Testing Qualifications Board. Cung cấp certifications: Foundation Level (CTFL), Advanced Level (CTAL), Expert Level. Widely recognized nhưng not mandatory.
  • JQL (JIRA Query Language)SQL-like language để query JIRA issues. Dùng để tạo saved filters và dashboard reports. Key operators: AND, OR, IN, ~, WAS, CHANGED.
  • Load TestingPerformance testing dưới expected user load. Verify system meets SLA under normal và peak conditions. Tools: JMeter, k6.
  • Mean Time Between Failures (MTBF)Reliability metric: average time hệ thống hoạt động giữa các failures. Higher MTBF = more reliable system.
  • Mean Time To Detect (MTTD)Average time từ khi bug tồn tại đến khi được phát hiện. Shorter MTTD = better testing effectiveness. Shift-left reduces MTTD.
  • Mean Time To Resolve (MTTR)Average time từ bug report đến bug fixed và verified. Key metric cho dev team velocity. Track by severity.
  • Mutation TestingTechnique để evaluate test suite quality: introduce small bugs (mutations) và check if tests catch them. High mutation score = strong test suite.
🔤 N – S
  • Negative TestingTest với invalid/unexpected inputs để verify hệ thống handles errors gracefully. Essential để catch security vulnerabilities và poor error handling.
  • Non-Functional TestingTesting HOW WELL the system performs: performance, security, usability, accessibility, compatibility, reliability. Often neglected but critical.
  • OWASP (Open Web Application Security Project)Non-profit org producing security resources. OWASP Top 10 = most critical web security risks. OWASP ZAP = free security testing tool.
  • Page Object Model (POM)Design pattern cho automation: UI elements và interactions encapsulated trong separate classes (page objects). Tests call page object methods, not locators directly.
  • Pass/Fail/Blocked/SkippedTest execution statuses. Blocked: cannot execute due to external dependency. Skipped: intentionally not run (out of scope, known issue). N/A: not applicable.
  • Performance BudgetSenior-level concept: define maximum acceptable values cho performance metrics (LCP < 2.5s, API P90 < 500ms). Enforced in CI — fail build if exceeded.
  • PriorityBusiness urgency of fixing a defect. P1 (urgent), P2 (high), P3 (medium), P4 (low). Set by PM/PO. Independent from severity.
  • QA vs QC vs QEQA (Quality Assurance): process improvement. QC (Quality Control): product inspection/testing. QE (Quality Engineering): build quality into the product from start, prevent defects.
  • Race ConditionBug occurring when 2+ concurrent processes access shared resource simultaneously. Intermittent, hard to reproduce. Common in e-commerce (inventory) and banking (transactions).
  • Regression TestingRe-running existing tests after code changes to verify existing functionality not broken. Should be automated for efficiency. Run every sprint in Agile.
  • Release Candidate (RC)Version of software intended for release if no critical bugs found. QA does final verification on RC before signing off for production deployment.
  • RTM (Requirement Traceability Matrix)Document mapping requirements → test cases → execution status. Ensures 100% requirement coverage. Must be maintained as requirements change.
  • Risk-Based TestingPrioritize testing based on risk (likelihood × impact). Focus testing effort where it matters most, especially when time is limited. Senior QA skill.
  • Sanity TestingNarrow testing of a specific area after a fix/change. Verify fix works without running full regression. Subset of regression, focused on changed area.
  • SDLCSoftware Development Life Cycle: Planning → Requirements → Design → Development → Testing → Deployment → Maintenance. QA is involved in all phases, not just testing.
  • SeverityTechnical impact of a defect on system functionality. Critical/Major/Minor/Trivial. Set by QA/Dev based on functional impact. Independent from priority.
  • Smoke TestingQuick test of critical functionality after a new build. If smoke fails → reject build without further testing. "Does the system start and basic functions work?"
  • State Transition TestingTest case design technique for systems with states. Map: states, events that cause transitions, actions. Ví dụ: Order states (Pending → Paid → Shipped → Delivered → Returned).
  • STLCSoftware Testing Life Cycle: Requirements Analysis → Test Planning → Test Case Development → Environment Setup → Execution → Test Closure. 6 phases, each with inputs/outputs.
  • Stress TestingPush system beyond normal capacity to find breaking point. Goal: discover maximum capacity AND verify graceful degradation/recovery when overloaded.
🔤 T – Z
  • TDD (Test-Driven Development)Dev writes failing test first, then writes minimum code to pass it. Red → Green → Refactor. QA supports by providing test scenarios, not typically writing the unit tests.
  • Test CaseDocument describing a specific test: ID, title, preconditions, steps, test data, expected result. Foundation of systematic testing.
  • Test CoverageExtent to which requirements/code are tested. Multiple dimensions: requirement coverage, branch coverage, path coverage. 100% coverage is rarely achievable or necessary.
  • Test DataSpecific inputs used during test execution. Must be managed (create, use, cleanup). Sensitive data must be masked/anonymized in non-production environments.
  • Test HarnessCollection of software/tools used to run automated tests. Includes test runner, assertion library, test data, mock objects, reporting tools.
  • Test OracleSource of truth for determining expected test results: spec, requirement, business rule, user story, domain knowledge, comparison with previous version.
  • Test PlanDocument describing testing scope, strategy, resources, schedule for a specific project/release. Living document — must be updated as project evolves.
  • Test StrategyHigh-level document defining overall testing approach for organization/project. Covers: test levels, types, techniques, tools, general guidelines. More stable than Test Plan.
  • Test SuiteCollection of related test cases grouped for a specific purpose (regression suite, smoke suite, payment test suite).
  • UAT (User Acceptance Testing)Final testing phase where business users/customers verify system meets business needs. QA supports by preparing environment, test data, and documentation. Acceptance = ready for production.
  • Unit TestingTesting smallest testable component (function/method) in isolation. Fastest, cheapest tests. Written by developers. Frameworks: JUnit (Java), pytest (Python), Jest (JS).
  • Use Case TestingTest case design based on use cases/user stories. Covers main flow, alternative flows, and exception flows. Good for complex business workflows.
  • Usability TestingEvaluate UX with real users performing tasks. Goal: identify usability issues. Different from functional testing — focuses on ease of use, not correctness.
  • VelocityStory points completed per sprint. Used to predict future sprint capacity. QA should factor testing effort into velocity planning.
  • WCAGWeb Content Accessibility Guidelines. International standard for web accessibility. Levels: A (minimum), AA (standard legal target in US/EU), AAA (optimal). Current version: 2.1, 2.2 in progress.
  • White-box TestingTesting with knowledge of internal code/architecture. Includes code coverage, path testing. Typically done by developers. QA may do grey-box (partial knowledge).
  • Zero-day VulnerabilitySecurity flaw unknown to software vendor, no patch available yet. High risk because no defense. QA should report suspected zero-days through responsible disclosure.
🔡 Acronyms Reference
AcronymFull FormContext
ACAcceptance CriteriaAgile, User Stories
APIApplication Programming InterfaceBackend, Integration
BDDBehavior-Driven DevelopmentAutomation, Agile
BRSBusiness Requirements SpecificationWaterfall, Planning
CI/CDContinuous Integration/Continuous DeploymentDevOps, Automation
CLSCumulative Layout ShiftCore Web Vitals
CRUDCreate, Read, Update, DeleteAPI, Database
DoDDefinition of DoneAgile, Sprint
DoRDefinition of ReadyAgile, Sprint Planning
DUTDevice Under TestHardware, Mobile
E2EEnd-to-EndTesting, Automation
EPEquivalence PartitioningTest Design
HARHTTP ArchiveNetwork, Browser DevTools
IDORInsecure Direct Object ReferenceSecurity
INPInteraction to Next PaintCore Web Vitals
ISTQBInt'l Software Testing Qualifications BoardCertification
JWTJSON Web TokenAuthentication, API
KPIKey Performance IndicatorMetrics, Reporting
LCPLargest Contentful PaintCore Web Vitals
MTTDMean Time To DetectQuality Metrics
MTTRMean Time To ResolveQuality Metrics
NFRNon-Functional RequirementRequirements
OWASPOpen Web Application Security ProjectSecurity
POMPage Object ModelAutomation
POProduct OwnerAgile, Scrum
QAQuality AssuranceGeneral
QCQuality ControlGeneral
QEQuality EngineeringAdvanced, Senior
RCRelease CandidateRelease Management
RESTRepresentational State TransferAPI
RTMRequirement Traceability MatrixTest Management
SDLCSoftware Development Life CycleProcess
SLAService Level AgreementPerformance, Business
SRSSoftware Requirements SpecificationRequirements
STLCSoftware Testing Life CycleProcess
TDDTest-Driven DevelopmentDevelopment Practice
TPSTransactions Per SecondPerformance
UATUser Acceptance TestingTesting Phase
UXUser ExperienceDesign, Usability
WCAGWeb Content Accessibility GuidelinesAccessibility
XSSCross-Site ScriptingSecurity
🧰 Tools Reference
CategoryToolUse Case
Test ManagementZephyr ScaleJIRA-native test cases, execution tracking
XrayBDD support, CI integration, reporting
TestRailStandalone, good reporting, large teams
Bug TrackingJIRAIndustry standard, full project management
LinearModern, fast, developer-friendly
AutomationPlaywrightModern E2E, TypeScript, all browsers
CypressFrontend-focused, JavaScript
SeleniumLegacy, multi-language, wide adoption
AppiumMobile native apps (iOS + Android)
API TestingPostmanManual + automated API testing, Newman CLI
InsomniaLightweight Postman alternative
SoapUISOAP/REST, enterprise features
PerformanceJMeterFree, powerful, Java-based, wide adoption
k6JavaScript, developer-friendly, cloud option
GatlingScala, good for high-load scenarios
SecurityOWASP ZAPFree automated security scanner
Burp SuiteIntercept/manipulate requests, professional
Cross-browserBrowserStackReal device/browser cloud, 3000+ configs
LambdaTestSimilar to BrowserStack, competitive pricing
Accessibilityaxe DevToolsChrome extension, automated scanning
WAVEVisual overlay, webaim.org
DatabaseDBeaverUniversal DB client, free
TablePlusClean GUI, MySQL/PostgreSQL/MongoDB