Glossary of Key Terms

How to Use This Glossary #

This glossary contains 70+ terms you’ll encounter throughout the course. Each entry includes:

• Term — the name (with abbreviation if applicable)
• Definition — a concise explanation in 1-2 sentences
• Module — where the term is covered in depth

Bookmark this page. Return to it whenever you encounter an unfamiliar term.

A #

Acceptance Testing — Testing conducted to determine whether a system satisfies its acceptance criteria, typically performed by the client or end user. Module 2

Accessibility Testing — Verifying that the application is usable by people with disabilities (visual, auditory, motor, cognitive), often following WCAG guidelines. Module 5

Active Recall — A study technique where you test yourself on material rather than passively re-reading it, proven to dramatically improve retention. Module 0

Ad Hoc Testing — Informal, unstructured testing without test cases or plans, relying on the tester’s intuition and experience. Module 2

Agile — An iterative software development methodology that delivers work in small increments (sprints), emphasizing collaboration, flexibility, and customer feedback. Module 1

API (Application Programming Interface) — A set of rules and protocols that allows different software applications to communicate with each other. Module 6

Assertion — A statement in test code that verifies an expected condition is true (e.g., “the status code should be 200”). Module 8

Automation Framework — A structured set of tools, libraries, and conventions for writing and running automated tests (e.g., Playwright, Cypress, Selenium). Module 8

B #

BDD (Behavior-Driven Development) — A development approach where tests are written in natural language (Given/When/Then) before code is implemented. Module 8

Black-Box Testing — Testing without knowledge of the internal code structure, based solely on requirements and specifications. Module 2

Boundary Value Analysis (BVA) — A test design technique that focuses on values at the edges of equivalence partitions (minimum, maximum, just inside, just outside). Module 3

Bug (Defect) — A flaw in the software that causes it to behave differently from the expected or specified behavior. Module 1

Bug Report — A document describing a defect, including steps to reproduce, expected vs. actual results, severity, and environment details. Module 4

C #

CI/CD (Continuous Integration / Continuous Delivery) — Practices where code changes are automatically built, tested, and prepared for release, enabling frequent and reliable deployments. Module 9

Compatibility Testing — Verifying the application works correctly across different browsers, devices, operating systems, and screen resolutions. Module 5

Contract Testing — Verifying that two services (consumer and provider) can communicate correctly based on a shared contract definition. Module 6

Cross-Browser Testing — Testing the application across multiple web browsers to ensure consistent behavior and appearance. Module 5

Cypress — A JavaScript-based end-to-end testing framework popular for web application testing. Module 8

D #

Decision Table — A test design technique that maps combinations of conditions (inputs) to expected actions (outputs) in a tabular format. Module 3

Defect Lifecycle — The stages a bug goes through from discovery to resolution: New → Assigned → Open → Fixed → Verified → Closed (or Reopened). Module 4

DevOps — A set of practices combining software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver updates continuously. Module 9

E #

E2E Testing (End-to-End Testing) — Testing a complete workflow from start to finish, simulating real user behavior across the entire system. Module 2

Equivalence Partitioning (EP) — A test design technique that divides input data into groups (partitions) where the system is expected to behave identically, reducing the number of test cases needed. Module 3

Exploratory Testing — A testing approach where the tester simultaneously designs and executes tests, using their knowledge and intuition to explore the application. Module 2

F #

Flaky Test — An automated test that sometimes passes and sometimes fails without any code changes, usually caused by timing issues, shared state, or external dependencies. Module 8

Functional Testing — Testing that verifies the application’s features work according to requirements and specifications. Module 2

G #

Git — A distributed version control system used to track changes in source code and test code. Module 9

Gray-Box Testing — Testing with partial knowledge of the internal structure, combining elements of both black-box and white-box approaches. Module 2

I #

Integration Testing — Testing the interaction between two or more components or systems to verify they work together correctly. Module 2

ISTQB (International Software Testing Qualifications Board) — The leading global organization providing standardized certifications for software testers. Module 0

J #

Jenkins — An open-source automation server commonly used to build CI/CD pipelines for automated testing and deployment. Module 9

K #

Kanban — An Agile methodology that visualizes work on a board with columns (To Do, In Progress, Done), focusing on continuous flow and limiting work in progress. Module 1

L #

Load Testing — Performance testing that simulates expected user load to verify the system handles normal traffic volumes. Module 11

Localization Testing — Verifying that the application is properly adapted for a specific locale, including translations, date formats, currency, and cultural elements. Module 5

M #

Mocking — Creating simulated objects or responses that mimic real dependencies, allowing tests to run in isolation without external services. Module 8

Monkey Testing — Random, unplanned testing where the tester inputs random data and performs random actions to find unexpected crashes or errors. Module 2

N #

Negative Testing — Testing with invalid, unexpected, or extreme inputs to verify the system handles errors gracefully. Module 3

Non-Functional Testing — Testing aspects not related to specific features: performance, security, usability, reliability, scalability. Module 2

O #

OWASP (Open Web Application Security Project) — A nonprofit foundation providing freely available resources for web application security, including the OWASP Top 10 vulnerability list. Module 11

P #

Page Object Model (POM) — A design pattern in test automation where each web page is represented as a class, encapsulating page elements and interactions. Module 8

Pair Testing — Two testers working together on the same test at the same workstation, combining their perspectives and knowledge. Module 2

Penetration Testing — Security testing that simulates real attacks to find vulnerabilities before malicious actors do. Module 11

Performance Testing — Testing the system’s speed, responsiveness, and stability under various conditions (load, stress, endurance). Module 11

Playwright — A modern test automation framework by Microsoft that supports cross-browser testing with auto-wait capabilities. Module 8

Positive Testing — Testing with valid, expected inputs to verify the system works correctly under normal conditions. Module 3

Priority — The business urgency for fixing a defect, indicating how soon it should be addressed (Critical, High, Medium, Low). Module 4

Q #

QA (Quality Assurance) — A process-oriented approach focused on preventing defects through improving development and testing processes. Module 1

QC (Quality Control) — A product-oriented approach focused on identifying defects through testing, inspection, and review. Module 1

R #

Regression Testing — Re-testing previously working functionality after code changes to ensure nothing is broken by new updates. Module 2

REST API — An architectural style for web services using standard HTTP methods (GET, POST, PUT, DELETE) for communication. Module 6

Risk-Based Testing — A testing approach that prioritizes test efforts based on the probability and impact of potential failures. Module 3

S #

Sanity Testing — A focused, narrow testing to verify a specific bug fix or new feature works correctly, without testing the entire system. Module 2

SDLC (Software Development Life Cycle) — The complete process of planning, creating, testing, and deploying a software application, from concept to retirement. Module 1

Selenium — An open-source test automation tool for web browsers, one of the oldest and most widely used automation frameworks. Module 8

Severity — The degree of impact a defect has on the system’s functionality (Blocker, Critical, Major, Minor, Trivial). Module 4

Shift-Left Testing — Moving testing activities earlier in the development process to find and fix defects sooner, when they are cheaper to resolve. Module 1

Smoke Testing — A quick, high-level test run to verify the most critical features work and the build is stable enough for further testing. Module 2

Spaced Repetition — A study technique that reviews material at gradually increasing intervals to strengthen long-term memory. Module 0

Sprint — A time-boxed iteration in Scrum (usually 1-4 weeks) during which a set of work is completed and made ready for review. Module 1

SQL (Structured Query Language) — A programming language for managing and querying relational databases, used by QA to verify data directly. Module 5

State Transition Diagram — A test design technique that models system behavior as states and transitions between them based on events or conditions. Module 3

STLC (Software Testing Life Cycle) — The sequence of testing phases: requirements analysis, test planning, test case design, environment setup, execution, and closure. Module 1

Stress Testing — Performance testing that pushes the system beyond normal capacity to determine its breaking point and failure behavior. Module 11

System Testing — Testing the complete, integrated system to verify it meets specified requirements. Module 2

T #

TDD (Test-Driven Development) — A development approach where tests are written before the production code, guiding the implementation. Module 8

Test Case — A documented set of conditions, inputs, actions, and expected results designed to verify a specific aspect of the system. Module 4

Test Environment — The hardware, software, network, and data configuration used to execute tests. Module 9

Test Plan — A document describing the scope, approach, resources, schedule, and deliverables for testing activities. Module 4

Test Suite — A collection of test cases grouped together for execution, often organized by feature, module, or test type. Module 4

Traceability Matrix — A document mapping requirements to test cases, ensuring every requirement is covered by at least one test. Module 4

U #

UAT (User Acceptance Testing) — The final phase of testing where real users validate the system meets their business needs before release. Module 2

Unit Testing — Testing individual components or functions in isolation, typically written by developers. Module 2

Usability Testing — Evaluating how easy and intuitive the application is for end users to accomplish their tasks. Module 5

V #

V-Model — A software development model where each development phase has a corresponding testing phase, emphasizing early test planning. Module 1

Verification — Ensuring the product is being built correctly according to specifications (“Are we building the product right?”). Module 1

Validation — Ensuring the right product is being built according to user needs (“Are we building the right product?”). Module 1

W #

Waterfall — A sequential software development model where each phase (requirements, design, implementation, testing, deployment) is completed before the next begins. Module 1

White-Box Testing — Testing with full knowledge of the internal code structure, examining code paths, branches, and logic. Module 2

X #

XSS (Cross-Site Scripting) — A security vulnerability where attackers inject malicious scripts into web pages viewed by other users. Module 11

Quick Reference: Commonly Confused Terms #

Next Steps #

You’ve completed Module 0: Orientation. You now have study strategies, a configured environment, career direction, and a vocabulary foundation.

It’s time to begin Module 1: Testing Fundamentals — where your real QA journey starts. Every term in this glossary will come alive as you work through the course.

Keep this page bookmarked. You’ll be coming back to it often.