QA and testing glossary

The terms this course uses, and the ones an interview might, defined in plain words. Search by term or by definition. This is the reference; your own cheat sheet from week one is the version that will actually stick, because you wrote it.

65 of 65 terms

A

Acceptance criteria: The specific, checkable conditions a feature must meet to count as done. Good ones read like ready-made test cases, which is not a coincidence.
Acceptance testing: Checking whether the software does what the user actually needed, as opposed to merely what the spec said. Often the last gate before release.
Accessibility testing: Checking that software works for people using assistive technology or a keyboard, not just a mouse and perfect eyesight. A quality effort that ignores it is quality for some.
APIApplication Programming Interface: The contract by which one piece of software talks to another. Testing an API means checking that contract directly, below the visible interface.
Appium: A cross-platform mobile automation tool that drives both iOS and Android. It has JavaScript bindings and a WebDriver-style approach, which makes it the shortest bridge from web automation to native.
Assertion: The line in a test that states what must be true. Without one you have a script that clicks things and a comforting illusion.

B

Boundary value analysis: Testing at the edges of an input range and just past them, because that is where off-by-one bugs live. For a field accepting 1 to 10, you test 0, 1, 10, and 11.
BugDefect: A place where the software behaves differently from what was intended or required. Also called a defect. See also error, failure, fault.

C

Component testingUnit testing: Testing a single unit of code in isolation from the rest of the system. Also called unit testing.
Continuous deliveryCD, Continuous deployment: Extending continuous integration so that code which passes its tests can be released automatically, or at the press of a single button.
Continuous integrationCI: Running your build and tests automatically on a shared server every time code is pushed, so breakage is caught in minutes rather than on Friday afternoon.
Coverage: How much of the code, or of the requirements, your tests actually exercise. High coverage is reassuring, not proof; you can run a line without checking it does the right thing.
Cypress: A JavaScript end-to-end testing framework that runs in the browser. The main automation tool in this course, chosen because it speaks the language you already know.

D

Data-driven testing: Running the same test logic over many sets of input data, rather than copying and pasting the test once per case.
Decision table: A grid of every combination of conditions and the outcome each should produce. Used when behaviour depends on several inputs at once and testing them one at a time would miss the interactions.
Device fragmentation: The vast spread of screen sizes, resolutions, and OS versions across mobile devices. You cannot test them all, so you choose a representative set by risk.
DOMDocument Object Model: The browser's live, structured representation of a page. Your selectors query it and your tests inspect it.

E

Edge case: An input or situation at the extremes of what is expected, where behaviour is most likely to surprise you. The interesting part of the map.
Emulator and simulator: Software that mimics a device on your computer: an emulator on Android, a simulator on iOS. Fast and free for early checks, but not a substitute for a real device.
End-to-end testingE2E: Driving the whole system the way a user would, from the interface down, to check that the parts work together and not just alone.
Environment: The specific setup a test ran in: browser, operating system, data, and versions. Half of every 'cannot reproduce' turns out to be a mismatched environment.
Equivalence partitioning: Grouping inputs that all behave the same way and testing one representative from each group, instead of every value. The technique that makes thorough testing finite.
Error, failure, fault: In careful usage: a person makes an error, which introduces a fault (a defect) in the code, which may cause a failure when the code runs. Interviews sometimes ask for the distinction.
Exploratory testing: Skilled, unscripted investigation of the software, where you design and run tests as you learn. Not random clicking, though it can look like it from across the room.

F

Fixture: A file of predefined test data that a test loads, so the data lives in one place and the test itself reads cleanly.
Flaky test: A test that passes and fails without the code changing, usually thanks to timing or a dependency it should have controlled. Trusted less than a coin flip and roughly twice as annoying.
Functional testing: Checking that the software does the right thing, measured against a requirement.

G

Gesture testing: Testing touch input beyond a click: tap, swipe, pinch, long-press, and coping with the on-screen keyboard that covers the field you were using.

H

Happy path: The scenario where everything goes right and the user behaves. Necessary to test, and never sufficient on its own.
Headless and headed: A test run without a visible browser window (headless) versus with one (headed). Headless is faster and how a CI server runs; headed is for watching tests while you build them.
HTTP methods: The verbs of the web. GET reads, POST creates, PUT updates, DELETE removes.
Hybrid app: A mobile app that wraps web content inside a native shell, so one codebase runs on both platforms. Part web, part native, and it tests like both.

I

Integration testing: Checking that two or more components work together at the point where they meet.
Interruption testing: Checking that a mobile app survives the things a phone does to it: incoming calls, notifications, being backgrounded and resumed, or a dying battery.
ISTQB: A widely recognised testing certification body whose Foundation syllabus is a free and decent source of shared vocabulary. Read it for the concepts; the exam is optional.

J

JSON: A lightweight data format that looks like a JavaScript object. How most APIs send their data, which is why your JavaScript background helps.

M

Mobile webResponsive design: A normal website viewed on a phone. Testing it is the closest mobile work to this course, and your browser's device emulation is enough to start.
Mock and stub: Stand-ins for a real dependency, so a test does not rely on something slow, flaky, or absent. A stub returns canned answers; a mock also records how it was called.

N

Native app: A mobile app built for one platform using its own language (Swift for iOS, Kotlin for Android) and installed from a store. The furthest from the web you already know.
Negative testing: Deliberately feeding bad input to check the software fails safely and helpfully, rather than falling over. Testing the unhappy path is the job, not pessimism.

P

Page Object Model: A pattern that keeps the selectors and actions for a page in one place, so tests read at a high level and a redesign breaks one file instead of fifty.
Playwright: Another major browser automation framework. Worth knowing it exists, even though this course leans on Cypress.
Postman: A tool for sending API requests and asserting on the responses, with no code required to get started and JavaScript available when you want it.
Priority: How soon a bug should be fixed. A business call, and distinct from severity: a typo in the logo can be high priority yet low severity.
Progressive web appPWA: A website that behaves more like an installed app: it can work offline and live on the home screen, while still being, underneath, a website.

Q

QA and QCQuality assurance, Quality control: Quality assurance is the process side, building quality in; quality control is checking the finished product for defects. In practice the titles blur, and most 'QA' roles do plenty of QC.

R

Real device testingDevice farm, Device cloud: Testing on actual hardware, where real performance, touch, and network conditions show up. A device cloud, such as BrowserStack or Sauce Labs, rents the devices you do not own.
Regression testing: Re-checking things that used to work, to catch what a change quietly broke. The quiet majority of real testing.
Requirement: A statement of what the software should do. Test cases trace back to these, and where a requirement is vague, testing gets interesting.
REST: A common convention for APIs that maps tidy URLs to HTTP methods. Not a law, but a widely followed habit.
Risk based testing: Spending your limited testing time where a failure would hurt most, rather than spreading it evenly and running out of week. A broken checkout is a catastrophe; a misaligned footer is a Tuesday.

S

Sanity test: A quick, narrow check that one specific function works after a change, before you commit to deeper testing.
Selector: How a test locates an element on a page, the same thinking as a CSS selector. Prefer stable attributes, like data-test, over selectors based on styling that a redesign will rename.
Severity: How bad a bug's impact is. A technical call, and distinct from priority: something can be severe but rare, or minor but urgent.
Smoke test: A fast, shallow pass over the core functions to decide whether a build is even worth testing further. If it fails, do not bother with the rest yet.
Status code: The number an HTTP response returns to say how it went. 200 fine, 400 your fault, 401 not allowed, 404 not found, 500 the server broke.
System testing: Testing the complete, integrated system as a whole, rather than any single part of it.

T

Test case: A single documented check: a title, any preconditions, the steps, and the expected result.
Test oracle: The source of truth a test uses to decide pass or fail: a specification, a known-good result, or a rule you can state.
Test plan: A short document setting out what you will test, what you will not, and why. A page is usually plenty.
Test runner: The tool that executes your tests and reports the results, such as Cypress.
Test suite: A collection of related tests that are run together.
Traceability: The links from requirements to the test cases that cover them, so you can see at a glance what is tested and, more usefully, what is not.

U

User acceptance testingUAT: Testing by, or on behalf of, the eventual users, to confirm the software meets their real needs before it goes live.

V

Verification and validation: Verification asks 'did we build it right', against the spec. Validation asks 'did we build the right thing', against the actual need. You can pass one and fail the other.