Software Quality
Definitions

Formal testing conducted to determine whether a system satisfies acceptance criteria and to enable the customer to determine whether to accept the system. Typically the last phase of testing before production release.

A testing methodology that follows agile principles — testing is continuous and integrated throughout the sprint rather than performed at the end of development.

Testing of Application Programming Interfaces directly to determine if they meet expectations for functionality, reliability, performance, and security. Performed independently of a UI.

A structured environment with guidelines, best practices, and reusable components for automated test creation and execution. Examples include Selenium, Playwright, and Cypress.

Testing without knowledge of the internal code structure. Testers focus on inputs and outputs based on specifications, not implementation details.

A flaw, error, or fault in software that causes it to produce incorrect or unexpected results, or behave in unintended ways.

A test technique that checks values at the boundaries of input domains — minimum, just above minimum, just below maximum, and maximum values.

Continuous Integration / Continuous Delivery. Automated pipelines that build, test, and deploy code on every commit, enabling faster and more reliable releases.

A metric measuring the percentage of source code executed during testing. High coverage doesn’t guarantee quality, but low coverage signals undertested areas.

Testing to ensure a system works correctly across different environments, browsers, devices, operating systems, and network conditions.

Security testing performed on a running application — simulating real-world attacks from the outside without access to source code.

The progression of a defect from discovery through closure: New → Assigned → Open → Fixed → Retest → Closed (or Reopened).

Testing of a complete application workflow from start to finish, simulating real user scenarios across all system components and integrations.

A test design technique that divides input data into groups (partitions) that should be treated equivalently by the software, then tests one value from each partition.

Testing that verifies each function of the software operates in conformance with the requirement specification, focused on what the system does.

A test that produces inconsistent results — passing and failing on the same code without changes. Flaky tests erode trust in automation suites.

Testing of combined system components or modules to verify they work together correctly. Identifies interface defects between integrated units.

A formal document recording a deviation from expected behavior in a test — including steps to reproduce, expected vs. actual results, and severity.

Measurable values used to track quality engineering effectiveness — e.g., defect escape rate, test coverage, automation ROI, mean time to detect.

Performance testing that evaluates system behavior under expected and peak load conditions to ensure it meets performance requirements.

Testing performed by a human tester without automation tools, exploring the application as an end user would to find defects.

Testing of applications on mobile devices and emulators across different screen sizes, OS versions, and network conditions.

An authorized simulated cyberattack on a system to evaluate its security — identifying vulnerabilities that could be exploited by malicious actors.

Testing to evaluate a system’s speed, responsiveness, and stability under various workloads. Includes load, stress, spike, and endurance testing.

Activities focused on providing confidence that quality requirements will be fulfilled — a proactive process of preventing defects through process improvement.

An evolution of QA that embeds quality practices throughout the SDLC using engineering principles, automation, and data-driven decision making.

Testing to confirm that recent code changes have not adversely affected existing features. Often automated to enable frequent execution.

A strategy that prioritizes test cases based on the probability and impact of failure — ensuring highest-risk areas receive the most testing attention.

Security analysis of source code, bytecode, or binaries without executing the program — identifying vulnerabilities early in development.

The structured process for planning, creating, testing, and deploying software — includes phases like requirements, design, development, testing, and maintenance.

A role that combines software development skills with QA expertise to build robust automated testing frameworks and tooling.

Moving testing activities earlier in the SDLC to detect and fix defects when they’re cheapest to resolve — reducing overall cost and risk.

A quick, surface-level test suite to verify that the most critical functions of a build work before investing in deeper testing.

Artificially generated data that mimics real production data — enabling realistic testing without privacy risks associated with using actual user data.

A set of conditions, inputs, actions, and expected results used to determine if a specific feature or function works correctly.

A document describing the scope, approach, resources, and schedule of testing activities — the strategic blueprint for a testing effort.

A high-level document outlining the testing approach, types of testing to be performed, tools, environments, and risk management approach.

Testing of individual functions or components in isolation, typically written and run by developers as part of the coding process.

Final testing phase where end users verify the system meets their requirements and is ready for production deployment.

A software development and testing model where each development phase has a corresponding test phase — emphasizing test planning early.

Simulating a component (service, database, API) that isn’t available during testing — enabling test execution without full environment dependencies.

Testing with full knowledge of the internal code structure — testers design tests based on implementation details, logic paths, and code coverage.