This page discusses and defines many different terms related to the Software Testing developmental process used in the IT industry. This glossary should NOT be considered complete as there are MANY different terms and definitions that could be added or used interchangeably with the content already present on this page.


Alpha testing

This is the first major portion of testing. It is usually done after a prototype has been developed to test its integrity and if it completes the actions it was made to do. The alpha testing stage is normally completed by members of the development team, rarely is it given to anyone outside of the development circle.


Beta testing

This test is initiated after the alpha testing stage is complete and a newer prototype has been developed. At this stage the developers open the testing to allow professional software testers to even the public to test their software.

Black box testing

A black box test is a test that allows for a more thorough testing without bias. A tester that is testing a system or module via black box testing does not know how the system or module was created, therefore they will input data that is more random, giving better results.


A human error, such as a typo or incorrect coding syntax that leads to problems within the functionality of the compilation and execution of the program, module or subset; this terminology can be used interchangeably with defect, error and fault


Code coverage

Code coverage consists of statement, decision and conditional coverage. It is a method used by the testing software to determine which code has been covered and which code has not.

Commercial off the shelf software

A commercial of the shelf software package is software that is readily available to the general public, either through shops or online. The opposite of this is bespoke software; which is custom software designed for a company’s specific needs.


A software tool normally integrated into an IDE that allows high level languages such as C++, C# and Java to be translated or converted into a lower level language (assembler and binary) to allow the computer to interpret the code.

Component testing

This is the process of testing an individual component within the entire system. This is done by separating the component away from the rest of the system, feeding it input and observing its output

Confirmation Testing

Confirmation tests are tests that are run once the errors and bugs have been corrected to ensure that the result has been fixed and the results from the output are the desired results.

Control Flow

The control flow is the sequence in which the events of the program are executed in. The control flow can have many different events as the structure of the flow can be changed with conditional statements.

Cyclomatic Complexity

This is the complexity of the component or module. It is based around the amount of different paths (conditional statements) that can be executed. The formula for working out the complexity is: L – N + 2P

  • L, the number of links between statement blocks
  • N, the number of statement blocks
  • P, the number of external modules that can be called by the statement blocks


Data flow

This is a representation of the state of all data objects within the system. It observes all potential changes within the objects. The 3 states an object can be are: Constructed, In use and Deconstructed.


Debugging is the process of correcting errors that have been identified within the system being tested. Debugging tools are usually used to discover the errors, but it takes an analyst or programmer to fix them.

Decision and Code Coverage (what is the formula for coverage?)

Decision coverage is a subtype of code coverage. It examines the outcomes from the decisions that the code is able to make via conditional statements, whereas code coverage is the examination of the parts of the code that have and have not been executed by the system under analysis. The formula for coverage is the following:

       Number of coverage items exercised
   Coverage = --------------------------- X 100%
       Total Number of coverage items


A defect is a human error; these errors are created during the coding phase of the program, although some issues may originate from the development phases. This terminology can be used interchangeably with error, bug and fault.


A driver is a component that is used during the testing phase to replace the component that calls and controls the component being tested. It is used to save time by not having to call multiple components just to test one.

Dynamic testing

This is the testing of the code through means of using a compiler to see the result of runtime; this test is very common and is primarily used to detect syntax errors within the code.



This is another name for a defect or a bug, as with the previous, it is a human error that causes problems with the functionality of the compilation and execution of the program.

Exhaustive Testing

This is the process of testing each component as vigorously as possible within the bounds of the testing phase. During this process a software tester will test all or as many different combinations of input values and preconditions that are possible.

Exit Criteria

This criterion defines the requirements that the tested module must be able to perform before the testing of the module is allowed to cease. It is used to stop a module from being considered finished when there are still parts that have yet to be created.



A failure is when a program or module executes incorrectly and produces output that was not intended, hence failing its intended operation.


A fault is a term that can be used interchangeably with error, bug and defect. It is the lack of successful execution and leads to problems within the functionality of the module of application.

Formal review

This is a review that is carried out by following the correct procedures and documentation. An inspection is a formal review type.

Functional requirements

These are requirements that the component is supposed to perform. Such as writing to a file, or reading from a file.

Functional testing

This is the testing of a component based on the functional requirements. The tester bases the tests off the specification that is created during the development of the component





An incident is a discovered event that requires investigation, not necessarily negative.

Incremental development model

This is a type of Software Development Life Cycle (SDLC) that allows the project to be developed incrementally. The project is broken up into different incremental stages, each stage containing each SDLC phase (project planning, analysis, construction and deployment). At the deployment phase a newer prototype is created to test and to ensure it is what should be developed.

Informal Review

This is the opposite of the formal review, it is a review process that does not follow the convention of using correct procedures and documentation. A good example could be a dynamic test a programmer would carry out to find coding bugs within the system.


An inspection is a formal review that examines documentation from the module tests and development to discover if they have been created and tested correctly, and that they conform to the development standards specified before the module was created.


This is the process of combining many different components, systems or modules to form one big component, system or module.

Integration testing

Tests that are performed to find and remove any conflicts between components, systems or modules that have been integrated together.

Interoperability testing

The testing of the components to see how they interact with other components, systems or modules within the system itself.




Load testing

This is a performance or stress test that tests the amount of load that the component can handle before becoming weakened. E.g. the amount of users accessing the component at one time.


Maintainability testing

This is a test to see how easy or difficult it will be to perform updates and maintenance on a component.


The term mistake can be used interchangeably with error; it is caused by a human and results in incorrect coding syntax and incorrect functionality of the program or module. The process of software testing was created to try and remove as many mistakes from the software development process as possible.


The moderator is the leader of a review process. They are responsible for reviewing the modules or components correctly.


Non functional testing

This is a test that highlights the non functional attributes of a component, such as usability, reliability, maintainability and so forth. It tests each of these non functional requirements to ensure they are of the top most quality.



Performance testing

This test is used to test how effectively a component completes its intended actions. As performance is a crucial part of modern software development this test is vital. This test observes code execution, speed and efficiency.

Portability testing

This test tests whether the component is able to execute correctly on multiple platforms such as: Linux, Windows, iOS etc.



The amount to which a customer is satisfied with a product or package that has been developed. Great quality can be assured by following stakeholders’ requirements and providing a degree that surpasses expectations.


Regression Testing

The testing of a system that has been previously implemented but recently changed; regression testing tests the system to see if any new bugs have been created as a result of the change.

Reliability testing

This tests whether the component is reliable, that is, if it is able to perform its intended actions for an acceptable amount of time.


A specification made by the user or stakeholder that the system must be able to perform upon completion of the development.


A reviewer is a person involved with reviewing a module or system, they are tasked with identifying bugs or anomalies within the system. There are normally a few reviewers per review; each reviewer representing a different aspect of the system.


The evaluation of a system or module to ensure the system or module is working correctly and to the stakeholder’s requirements. If the review reveals the system or module is working incorrectly the developers have to return to the development stage and redesign it correctly.


This is the evaluation of a module within the system, a review is carried out to ascertain whether the module has been created correctly, that it conforms to its development specification and that the bugs and anomalies have been mitigated to a significant level.


If a bug is discovered within a system it needs to be corrected, once it is corrected a test must be conducted to see if the fix is adequate and has not broken the system. This test is a rework test, it is similar to regression testing.


The potential possibility that something could have a negative impact on the SDLC (software development life cycle). Risk analysis is used to identify and mitigate as many risks as possible, but not all risks are able to be identified early on during development.

Robustness testing

This test determines how effectively a component is able to execute while being put under stress or fed incorrect input. It is essential to have error tolerance as humans make errors and software is no different as it is a human creation.



The scribe is the note taker for the review process. They note down any defects that are discovered during the review and any suggestions on how they could be mitigated.

Security testing

A security test is used to ensure the software is as secure as possible, through means of allowing correct access, authority and preventing modifications to the system itself.

Specification based testing

This technique is synonymous with black box testing. The tester only has the specification to go with during testing, and as a result, cannot be biased with the testing inputs. The tester does not know how the component was developed.

Static analysis

This is the analysis of the requirements or code without compiling and executing the code. It is used to check if the code and requirements are full, complete and are of a high quality.

Static testing

This is the testing of the module without executing the code, it focuses on the specification and implementation levels, it is used to mitigate as many bugs as possible to provide a better quality module.

Stress testing

This test observes how the component being tested is able to cope under pressure. This is achieved by reducing the resources it needs to operate correctly and by pushing it beyond anticipated functionality levels.

Structural Testing

This test is synonymous with white box testing, a white box test is the opposite of a black box test. The tester has the ability to view the structure of the component and is able to feed in input based on the structure of the component.


A stub is a temporary additional component to a system; they are used when a tested component calls another component that is out of the scope of the test. It could be known as a placeholder for other components.

System Testing

This is the testing of the entirety of all integrated components (formed into a system) to ensure the system performs its intended and required actions.


Technical review

This is the review that focuses on the technical aspects of the system. It allows the reviews to agree on approaches that should be taken, such as programming languages and suites that will be used.

Test Basis

This is the basis on which the test are to be made, the test basis allows for the remainder of the documentation to be created, using it as a reference. A frozen test basis is when a change or amendment must be made to the test basis, and as such, cannot be altered until it has become unfrozen.

Test Case

A specific case that is developed for each individual module of system that is being tested. : Each test case contains: inputs, pre conditions that must be met, expected outputs and the post conditions that must be able to be attained from the output.

Test Condition

Is the environment appropriate to use for the testing? Can the system or module be correctly verified by the environment? This definition defines the things that must be observed and accepted for the test to pass.

Test Coverage

What percentage of the system has been tested? The test coverage is the total amount of code, systems or modules that have been tested.

Test Data

Data that was created prior to the testing of a system, this data is manipulated and affected by the system or module during the test. It is used to ensure the correct execution of the system or module.

Test-driven development

This is a development technique that enables a more thorough testing through means of developing the tests based on the component specification before developing the components themselves. This allows for the best testing as the tests are not based around the components construction, but rather, the specification design.

Test environment

This is the environment that houses all of the testing packages documentation, test simulators and relevant tools needed to conduct various different tests.

Test Execution

The actual running of the test for a system or module. Once finalised, the test produces real results.

Test level

A test level is the grouping of the activities needed to complete a test. Tests are compromised of a heading (component test, security test etc). Each heading has test levels which are the activities needed to complete the heading

Test Log

A chronological log that records all details about the execution of a test during the test execution.

Test Objective

The reasoning behind the planning and execution of a test. What are the required outcomes?

Test Plan

A document that contains the approach and reasoning for creating a test. It describes the scope, resources that will be used and the schedule. It observes and discusses the features within the system or module that will be tested, who will be testing each of the parts, the techniques that will be employed, and the test environment that will be used. It can be considered as a record of all the activities during the test planning phase.

Test Strategy

A high level description of how the tester will test the system or module and what activities will take place during this time.

Test Summary Report

This is a document containing all activities that occurred during testing as well as their results. It also serves as an evaluation for the exit criteria and if they have been made.


The act of analysing the development of a system or module to ensure there are little to no errors or mistakes, therefore mitigating bugs within the system. The act of testing must be adhered to at all times during the SDLC so that most mistakes and errors can be removed in their early days.


Traceability is the ability to find related documents and software and/or tests that are used in conjunction with one another. E.g. for a module within the system, it will have development documentation, testing documentation and links to any other modules or systems that require the module.


Usability testing

This tests to see how easy or difficult it is for users to use, how instinctual it is and how easy or difficult it is to learn the functionality of the system.

User acceptance test

This test is conducted by the users of the system to ensure that the system and its components have been developed correctly and complete their intended requirements


V model

A V model is a framework that is used to describe how the testing process and the SDLC can be intertwined during each phase to provide a more rigorous testing system


This is the confirmation that a requirement the component is supposed to perform has been performed successfully and has provided intended results.


This is similar to validation, but instead of the component being tested, the specification is observed to check to see if the specification meets its intended actions.



The author of a document provides a step by step review of said document to allow the other team members to gain a common understanding of its design and intended outcome.

White box testing

This is the opposite of black box testing and is the same as specification based testing. The tester has access to the components construction and therefore, can feed in more meaningful inputs.




QR Code
QR Code software_testing_glossary (generated for current page)