100 Software Testing Terminology You Need to Know

Software Testing is the process of evaluating a software application to find defects, ensure it meets requirements, and verify its quality. It's about making sure the software works as expected and is ready for users.

A Test Case is a set of conditions or variables under which a tester will determine if a system is working correctly. It includes steps, input data, and expected results. For example, a test case for a login feature might be: 'Enter valid username, enter valid password, click login button, expect user dashboard to load'.

A Bug or Defect is a flaw or error in the software that causes it to produce an incorrect or unexpected result, or to behave in an unintended way. It's essentially something that prevents the software from working as it should.

Quality Assurance (QA) is a proactive process focused on preventing defects throughout the software development lifecycle. It involves setting standards, processes, and procedures to ensure quality is built into the product from the start.

Quality Control (QC) is a reactive process focused on identifying and correcting defects in the finished software product. It involves activities like testing, inspections, and reviews to ensure the product meets quality standards.

A Test Plan is a detailed document that outlines the scope, objectives, resources, and schedule of a testing effort. It defines what will be tested, how it will be tested, when, by whom, and what criteria will be used to declare testing complete.

Test Strategy is a high-level document that defines the overall approach to testing for an entire project or organization. It guides the creation of test plans and outlines the types of testing to be performed.

A Test Bed is the environment configured for testing. It includes the hardware, software, network configurations, and data needed to execute tests. Think of it as the laboratory where testing takes place.

Test Environment refers to the setup of software and hardware for the test teams to execute test cases. It's essentially the complete setup where the software under test is deployed and run.

Test Data is the input provided to the software during testing to verify its functionality. This data can be valid, invalid, or edge cases designed to thoroughly test different scenarios.

A Requirements Traceability Matrix (RTM) is a document that maps and traces user requirements with test cases. It helps ensure that every requirement is covered by at least one test case and vice versa.

Unit Testing is the first level of testing, where individual components or 'units' of software are tested in isolation. Developers usually perform this to ensure their code modules work correctly before integration.

Integration Testing is performed to test the interfaces between integrated units/modules. It checks if different parts of the software work together correctly after they have been individually unit tested.

System Testing is a level of testing that tests the complete and integrated software system. It evaluates the system's compliance with specified requirements, often in an environment that mirrors production.

Acceptance Testing is a formal testing process to determine if the software meets the user requirements and is ready for deployment. It's often performed by end-users or clients.

User Acceptance Testing (UAT) is a type of acceptance testing performed by the actual end-users to verify if the system meets their business needs and is fit for purpose in a real-world scenario.

Alpha Testing is a type of acceptance testing performed by internal employees (developers or QA staff) at the development site. It's typically done before the software is released to external users.

Beta Testing is a type of acceptance testing performed by a limited group of real users (beta testers) in a real environment outside the development site. It helps identify issues that might be missed in internal testing.

Regression Testing is performed to ensure that new code changes, bug fixes, or new features have not negatively impacted existing functionalities. It's about making sure old features still work after new changes.

Re-testing (or Confirmation Testing) is performed to verify that a previously reported defect has been successfully fixed. It involves running the specific test cases that failed due to the bug.

Functional Testing is a type of testing that verifies if each function of the software application operates in conformance with the functional requirements. It focuses on 'what' the system does.

Non-Functional Testing is a type of testing that verifies non-functional aspects of a software application, such as performance, usability, reliability, and security. It focuses on 'how' the system performs.

Performance Testing is a non-functional testing type that assesses how a system performs under a particular workload. It evaluates speed, responsiveness, and stability under various conditions.

Load Testing is a type of performance testing that measures the system's behavior under expected peak load conditions. It checks if the system can handle the anticipated number of users or transactions.

Stress Testing is a type of performance testing that evaluates the system's robustness beyond normal operating capacity, often by pushing it to its breaking point. It checks how the system recovers from extreme conditions.

Volume Testing is a type of performance testing that evaluates the system's performance and behavior when subjected to a large amount of data. It checks how the system handles large databases or files.

Scalability Testing is a type of performance testing that determines the software's ability to scale up or down to meet increasing or decreasing user demands. It checks if the system can handle growth.

Usability Testing is a non-functional testing type that evaluates how easy and intuitive a software application is to use for its intended users. It focuses on user experience.

Security Testing is a non-functional testing type that aims to uncover vulnerabilities in the software system and protect data from potential threats. It ensures the system is secure against attacks.

Compatibility Testing is a non-functional testing type that verifies how well the software performs in different environments (e.g., operating systems, browsers, devices, hardware configurations). It ensures the software works across various setups.

Reliability Testing is a non-functional testing type that ensures the software performs its specified functions under stated conditions for a specified period of time. It checks the system's ability to operate without failure.

Maintainability Testing is a non-functional testing type that evaluates how easy it is to modify, update, or fix the software after it has been deployed. It checks the ease of future changes.

Portability Testing is a non-functional testing type that verifies how easily the software can be transferred from one environment to another. It checks if the software can run on different platforms.

Localization Testing is a type of testing that ensures the software is adapted correctly for a specific locale or region, including language, currency, date formats, and cultural conventions.

Internationalization Testing (I18n Testing) ensures that a software application can be adapted to various languages and regions without requiring significant engineering changes. It checks the software's ability to support multiple locales.

Ad-hoc Testing is an informal testing type performed without any formal test plan or documentation. It's often done randomly to find defects that might be missed by structured testing.

Exploratory Testing is a simultaneous learning, test design, and test execution process. Testers actively learn about the software while testing, designing new tests on the fly based on their discoveries.

Smoke Testing (or Build Verification Testing) is a quick set of tests performed on a new build to ensure that the most critical functions work and the build is stable enough for further testing. It's like a 'sanity check'.

Sanity Testing is a quick, narrow regression test performed after a small change or bug fix to ensure that the change works as expected and hasn't broken any related functionality. It's more focused than smoke testing.

Black Box Testing is a testing method where the internal structure, design, and implementation of the software are unknown to the tester. The tester interacts with the software through its user interface, focusing on inputs and outputs.

White Box Testing (or Glass Box Testing) is a testing method where the internal structure, design, and implementation (code) of the software are known to the tester. The tester designs test cases based on the code's logic.

Grey Box Testing is a combination of Black Box and White Box testing. The tester has partial knowledge of the internal structure, enough to design more informed test cases but not full access to the code.

Static Testing is a type of testing that involves examining the software's code and documentation without actually executing the program. Examples include code reviews, walkthroughs, and inspections.

Dynamic Testing is a type of testing that involves executing the software application to observe its behavior and identify defects. It's about running the code and seeing what happens.

Test Automation is the use of software to control the execution of tests, comparison of actual outcomes with predicted outcomes, and reporting of test results. It helps run tests faster and more reliably.

A Test Script is a set of instructions written in a programming language or scripting language that automates the execution of a test case. It's the coded version of a manual test case.

Test Coverage is a metric used to describe the degree to which the source code of a program is executed when a particular test suite is run. It helps identify areas of code not covered by tests.

Defect Life Cycle (or Bug Life Cycle) describes the various states a defect goes through from its discovery to its closure. It typically includes states like New, Open, Fixed, Retest, Closed, Reopen, Deferred.

Severity is the impact a defect has on the functionality or performance of the software. It indicates how serious the bug is from a technical perspective (e.g., Critical, Major, Minor, Low).

Priority is the urgency with which a defect needs to be fixed. It indicates how quickly the bug should be addressed, often based on business impact (e.g., High, Medium, Low).

A Test Harness is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs. It provides the necessary environment to run tests.

A Test Stub is a small piece of code that simulates the behavior of a component that is not yet developed or is too complex to include in the test environment. It's used when testing a module that calls another module.

A Test Driver is a piece of code that calls the component being tested and passes test data to it. It's used when testing a module that calls other modules, simulating the calling environment.

Test Case Design Techniques are systematic methods used to create effective test cases. Examples include Equivalence Partitioning, Boundary Value Analysis, Decision Table Testing, and State Transition Testing.

Equivalence Partitioning is a black-box test case design technique that divides input data into partitions (classes) where all values in a partition are expected to behave similarly. You pick one representative from each partition.

Boundary Value Analysis (BVA) is a black-box test case design technique that focuses on testing the boundary values of input partitions. Experience shows that defects often occur at the edges of valid input ranges.

Decision Table Testing is a black-box test case design technique used for systems with complex logic or multiple conditions. It maps combinations of inputs to corresponding actions or outcomes in a table format.

State Transition Testing is a black-box test case design technique used for systems that behave differently based on their current state and specific events. It tests transitions between different states of the system.

Error Guessing is an experience-based test technique where the tester uses their knowledge and intuition about common software errors to anticipate where defects might exist and design tests to find them.

Defect Seeding is a technique where known defects are intentionally inserted into a program to estimate the number of unknown defects present. It helps evaluate the effectiveness of the testing process.

Test Metrics are quantitative measures used to evaluate the progress, quality, and effectiveness of the testing process and the software product. Examples include defect density, test case execution rate, etc.

Defect Density is a test metric that measures the number of defects found per unit of code size (e.g., defects per thousand lines of code). It helps assess the quality of the software.

Test Reporting is the process of summarizing and communicating the results of testing activities. It provides stakeholders with information about the quality of the software and the progress of testing.

Test Closure is the phase where all testing activities are completed, and the test team prepares a test summary report, archives test artifacts, and conducts a lessons learned meeting.

Traceability in software testing refers to the ability to link requirements to test cases, code, and defects. It ensures that all aspects of the software are covered and trackable.

Test Case Prioritization is the process of ordering test cases to run higher-priority tests earlier in the testing cycle. This ensures critical functionalities are tested first.

Test Execution is the process of running the test cases on the software under test, recording the results, and logging any defects found.

A Test Management Tool is a software application used to manage testing activities, including test case creation, execution, defect tracking, and reporting. Examples include Jira, TestLink, ALM.

A Defect Tracking Tool is a software application used to log, track, and manage defects throughout their lifecycle. It helps teams collaborate on resolving bugs. Examples include Jira, Bugzilla.

An Automation Testing Tool is software used to automate the execution of tests, reducing manual effort and speeding up the testing process. Examples include Selenium, Cypress, Playwright.

Continuous Integration (CI) is a development practice where developers frequently merge their code changes into a central repository, after which automated builds and tests are run. It aims to detect integration errors early.

Continuous Delivery (CD) is an extension of CI where code changes are automatically built, tested, and prepared for a release to production. It ensures the software is always in a deployable state.

Continuous Testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. It's testing early and often.

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the systems development life cycle and provide continuous delivery with high software quality. Testing is an integral part of DevOps.

Agile Testing is a software testing practice that follows the principles of agile software development. It involves testing continuously from the initial stages of development, with close collaboration between developers and testers.

Scrum is an agile framework for managing complex knowledge work, with an emphasis on software development. It involves short iterations (sprints), daily stand-ups, and continuous feedback, all of which impact testing.

In Scrum, a Sprint is a short, time-boxed period (usually 1-4 weeks) during which a 'Done,' useable, and potentially releasable product increment is created. Testing activities are performed within each sprint.

The Sprint Backlog is a set of Product Backlog items selected for the Sprint, plus the plan for delivering the product Increment and realizing the Sprint Goal. It defines the work the development team will do in a sprint, including testing tasks.

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product, which informs testing efforts.

Test Driven Development (TDD) is a software development approach where tests are written before the actual code. The cycle is: write a failing test, write minimal code to pass the test, then refactor the code.

Behavior Driven Development (BDD) is a software development process that encourages collaboration among developers, QA, and non-technical or business participants. It describes software behavior in plain English using Gherkin syntax (Given-When-Then).

Gherkin is a business-readable, domain-specific language that describes software behavior without detailing implementation. It's used in BDD frameworks (like Cucumber) with 'Given-When-Then' syntax to write executable specifications.

Acceptance Test Driven Development (ATDD) is a development methodology where the team collaborates to define acceptance criteria for a feature as executable tests before development begins. It's similar to BDD but focuses more on customer-facing tests.

Test Data Management (TDM) is the process of planning, designing, creating, and managing test data for various testing activities. It ensures that testers have the right data for their tests.

Data Driven Testing is an automation testing framework where test data is separated from the test logic. This allows running the same test script with multiple sets of input data, often stored in external files (e.g., Excel, CSV).

Keyword Driven Testing is an automation testing framework where test steps are written using keywords that represent actions or operations. These keywords are then mapped to underlying test automation code.

A Hybrid Framework in test automation combines the advantages of two or more frameworks, such as Data Driven and Keyword Driven frameworks, to create a more flexible and robust solution.

A Test Suite is a collection of test cases that are grouped together to test a particular functionality or an entire module of a software application. It helps organize and execute related tests.

A Test Cycle is a complete execution of the test process, from test planning to test closure, for a specific build or release of the software. It represents one round of testing.

A Test Point typically refers to a specific condition or aspect of the software that needs to be verified during testing. It's a granular item within a test case or a test objective.

A Test Log is a chronological record of relevant details about the execution of tests, including test case IDs, execution status (pass/fail), actual results, and any defects found. It's a detailed history of testing.

A Test Summary Report is a document that provides an overview of the testing activities, including test coverage, defects found, risks, and the overall quality assessment of the software. It's a high-level report for stakeholders.

Entry Criteria are the conditions that must be met before a particular test phase or activity can begin. For example, 'all unit tests passed' might be an entry criterion for integration testing.

Exit Criteria are the conditions that must be met before a particular test phase or activity can be considered complete. For example, '95% of critical defects fixed' might be an exit criterion for system testing.

Test Sign-off is a formal approval that indicates the completion of the testing phase and that the software is deemed ready for the next stage (e.g., release to production or UAT). It's a formal agreement.

Defect Leakage refers to the number of defects that escape a testing phase and are found in a later stage (e.g., defects found in UAT that should have been caught in system testing, or defects found by end-users).

Defect Escape Rate is a metric that measures the percentage of defects that were not found during the testing phase but were discovered by the end-user in production. A lower rate indicates better testing effectiveness.

The Test Maturity Model (TMM) is a framework used to assess and improve the maturity level of an organization's software testing process. It has five levels, from initial to optimizing.

Capability Maturity Model Integration (CMMI) is a process improvement training and appraisal program. While not specific to testing, it includes practices that improve the overall software development process, including quality and testing.

Test Plan Review is the process of having stakeholders and peers examine the test plan document to ensure its completeness, accuracy, and alignment with project goals before testing begins.