Team language is useful shorthand
Technology teams shorten repeated ideas into compact terms. This language helps experienced colleagues move quickly, but it can make a normal discussion feel inaccessible.
Some expressions have formal definitions. Others are local slang. Two teams can use the same word differently, especially terms such as mock, staging, done, and release.
Do not pretend that you understand an unclear term. Ask what it means in that product and repeat the meaning with a concrete example.
This guide groups common terms by the situations where a QA engineer will hear them. Use it as a translation aid, not as a rigid dictionary.
Tickets, backlogs, and daily delivery work
A ticket, issue, or work item is a recorded unit of work. It can describe a feature, defect, investigation, technical task, or customer request.
The backlog is the ordered collection of possible work. A sprint is a fixed period in Scrum during which the team works toward a defined goal.
A stand-up is a short coordination discussion. A blocker is a problem that prevents meaningful progress, while a dependency is something the work requires from another task or system.
Scope states what work is included. Acceptance criteria describe conditions for accepting a work item. The Definition of Done applies shared completion standards to completed work.
Teams also use spike for a time-limited investigation and refinement for making future work clearer. Confirm the expected output before starting either activity.
Repositories, branches, commits, and pull requests
A repository, often called a repo, stores source code and its change history. A branch is a separate line of work based on part of that history.
A commit records a specific set of changes with an identifier and message. Push sends local commits to a remote repository, while pull retrieves remote changes.
A pull request, or PR, proposes merging one branch into another. Team members review the changes, discuss risks, and wait for required automated checks.
A merge combines changes. A merge conflict means the version-control tool cannot safely combine some changes without a person deciding the correct result.
Code review examines a proposed change before integration. QA professionals can review acceptance criteria, testability, automated checks, configuration, and product risk without reviewing every implementation detail.
Local, test, staging, and production environments
An environment is the hardware, software, configuration, services, accounts, and data used to run a product. Environment names are conventions, not universal guarantees.
Local usually means a developer's computer. Development and test environments support active work. A QA environment is often a shared test environment owned by no single person.
Staging or preproduction usually resembles production more closely. User acceptance testing, or UAT, lets business representatives evaluate whether the product supports their needs.
Production, often shortened to prod, is the live environment used for real operations. Do not assume that test actions, test accounts, or destructive queries are safe there.
A sandbox is an isolated place for experiments with controlled impact. Ask which integrations are real, which data can be reset, and which actions can still affect external systems.
Dummy data, test data, and production-like data
Test data is any data used to exercise and evaluate software. It includes inputs, stored records, files, account states, expected results, and dependency responses.
Dummy data is placeholder data with little behavioral meaning. A name such as Test User can satisfy a required field, but it rarely represents important rules or risks.
Synthetic data is artificially created to represent useful patterns without copying a real person's record. Good synthetic data includes realistic relationships, boundaries, formats, and uncommon states.
Masked or anonymized data starts from real data and transforms identifying information. Masking does not automatically remove privacy risk, so approved handling rules still apply.
Seed data is a repeatable starting data set loaded into an environment or test. A fixture is the known setup that a test requires, which can include data, files, objects, and configuration.
Production-like data resembles relevant production characteristics. It must not become an excuse to copy sensitive production records into an uncontrolled test environment.
Mocks, stubs, fakes, dummies, and test doubles
A test double replaces a real dependency during a test. The name comes from a stunt double who stands in for another person during a controlled scene.
A dummy value is passed because an interface requires it, but the tested behavior does not use it. Dummy objects and dummy data are related ideas, but they are not identical.
A stub returns controlled answers. For example, a payment stub can return a declined response without contacting a real payment provider.
A mock is commonly used to verify an interaction. A test can verify that the application requested one refund with the correct order identifier.
A fake is a working but simplified implementation, such as an in-memory message store. A simulator models richer external behavior, often across a network boundary.
Testing literature and tools do not use these labels consistently. State what the replacement does, and remember that a double does not prove the real integration works.
Happy paths, edge cases, and regression checks
The happy path is the expected successful journey under normal conditions. It is a useful starting point, but it provides little evidence about failure handling.
A negative test uses invalid input or an invalid action. An edge case is an unusual condition near the limits of expected use.
A boundary is the point where behavior or an input category changes. Values immediately below, at, and above a boundary often reveal inconsistent rules.
A smoke test is a small set of checks for critical stability after a build or deployment. Sanity check is an informal term for a focused confidence check.
Regression testing looks for unwanted effects after change. Retesting confirms a specific fix, while exploratory testing uses active learning to guide the next test action.
A flaky test gives inconsistent results without a relevant product change. Treat that instability as a problem to investigate, not as a reason for routine retries.
Bug reports, reproduction, severity, and priority
Teams use bug, defect, and issue for observed product problems. These words can have local distinctions, but clear evidence matters more than the preferred label.
Repro is shorthand for reproduction. Steps to reproduce describe the actions and conditions that produce the behavior. Expected and actual results make the disagreement visible.
Severity describes the impact of a problem. Priority describes when the team intends to address it. A severe defect can have lower priority when exposure is safely controlled.
Triage is the process of reviewing new findings and deciding impact, urgency, ownership, and next action. A known issue is documented and accepted temporarily, not silently ignored.
Cannot reproduce means the investigator did not observe the reported result under the available conditions. It does not prove that the original observation was false.
A root cause is the underlying condition that enabled a failure. A workaround reduces immediate impact without necessarily removing that cause.
Builds, pipelines, deployments, and releases
A build converts source code and dependencies into runnable output. The resulting package, archive, or container image is often called an artifact.
A pipeline automates steps such as building, testing, scanning, packaging, and deployment. Continuous integration, or CI, gives feedback when developers integrate code changes.
Continuous delivery keeps verified changes ready for a production decision. Continuous deployment releases qualifying changes automatically. Teams often use CD without stating which meaning they intend.
Deployment moves a software version into an environment. Release makes functionality available to users. Feature flags can separate those events by controlling access after deployment.
A canary release exposes a change to a limited group before wider use. A hotfix is an urgent correction, while rollback restores an earlier version or state.
Ship means release or complete a change. Confirm whether the speaker means merged, deployed, enabled, or available to every intended user.
API and troubleshooting vocabulary
An application programming interface, or API, defines how software components communicate. An endpoint is a specific address and operation exposed by an API.
A request asks a service to do something. A response reports the outcome. The payload is the meaningful data carried by either message.
Headers carry message metadata, while an HTTP status code communicates a response category. A successful status code does not prove that the returned business result is correct.
Authentication establishes who or what is making a request. Authorization determines which actions that identity can perform. Teams often shorten both topics to auth, so ask which one applies.
Logs record discrete events. Metrics measure values over time. Traces connect work across services. Together, these signals can explain behavior that the user interface does not show.
Latency is the time required for an operation. A timeout stops waiting after a defined limit. A retry repeats an operation and can create duplicate effects when the operation is unsafe.
Informal phrases you will hear
WIP means work in progress. LGTM means looks good to me. A nit is a small review comment that should not usually block approval.
Tech debt describes a design or implementation compromise that creates future cost. A workaround solves an immediate problem, while a hack suggests a rough or fragile shortcut.
Dogfooding means using your own product. Rubber-duck debugging means explaining a problem step by step, which can expose a mistaken assumption.
Bikeshedding is spending excessive attention on a minor issue. Yak shaving is completing a surprising chain of supporting tasks before reaching the original goal.
On-call describes responsibility for responding to operational problems during a period. Blast radius describes the possible extent of damage from a failure or change.
Slang can help established teams, but it can also exclude new colleagues. Prefer the full term when accuracy, safety, or shared understanding matters.
Build your vocabulary through evidence
Keep a small personal glossary during your first projects. Record the term, the team's meaning, one example, and any question that remains open.
When someone requests mocked data, ask whether they need placeholder records, synthetic test data, or a simulated dependency response. Those choices create different evidence.
When someone says test it in staging, confirm the version, configuration, integrations, accounts, and data. An environment name alone does not define the test conditions.
Use precise language in bug reports and release notes. Expand an abbreviation on first use when the audience might not know it.
You do not need to memorize every expression before joining a team. Learn the terms that support your next decision, and ask for concrete meaning when language is unclear.