J

• Iteration
  A development cycle consisting of a number of phases, from formulation of requirements to delivery of part of an IT system. Common phases are analysis, design, development, and testing. The practice of working in iterations is called iterative development.

• ISTQB
  International Software Testing Qualifications Board. ISTQB is responsible for international programs for testing certification.

• Internal supplier
  Developer that belongs to the same organization as the client. The IT department is usually the internal supplier. See also external supplier.

• Integration testing
  A test level meant to show that the system’s components work with one another. The goal is to find problems in interfaces and communication between components.

• Instrumentation code
  Code that makes it possible to monitor information about the system’s behaviour during execution. Used when measuring code coverage, for example.

Installation test
A type of test meant to assess whether the system meets the requirements for installation and uninstallation. This could include verifying that the correct files are copied to the machine and that a shortcut is created in the application menu.

Inspection
An example of a formal review technique.

Informal review
A review that isn’t based on a formal procedure.

Independent testing
A type of testing in which testers’ responsibilities are divided up in order to maintain their objectivity. One way to do this is by giving different roles the responsibility for various tests. You can use different sets of test cases to test the system from different points of view.

Incident report
See defect report.

Incident
A condition that is different from what is expected, such a deviation from requirements or test cases.

Impact analysis
Techniques that help assess the impact of a change. Used to determine the choice and extent of regression tests needed.

IEEE 829
An international standard for test documentation published by the IEEE organization. The full name of the standard is IEEE Standard for Software Test Documentation. It includes templates for the test plan, various test reports, and handover documents.

I

Gray-box testing
Testing which uses a combination of white box and black box testing techniques to carry out software debugging on a system whose code the tester has limited knowledge of.

G

Functional testing
Testing of the system’s functionality and behaviour; the opposite of non-functional testing.

Functional integration
An integration testing strategy in which the system is integrated one function at a time. For example, all the components needed for the “search customer” function are put together and tested one by one.

Formal review
A review that proceeds according to a documented review process that may include, for example, review meetings, formal roles, required preparation steps, and goals. Inspection is an example of a formal review.

Fault Injection
A technique used to improve test coverage by deliberately inserting faults to test different code paths, especially those that handle errors and which would otherwise be impossible to observe.

FAT
See Factory Acceptance Test.

Failure
Deviation of the component or system under test from its expected result.

Factory acceptance test
Acceptance testing carried out at the supplier’s facility, as opposed to a site acceptance test, which is conducted at the client’s site.

F

Extreme programming
An agile development methodology that emphasizes the importance of pair programming, where two developers write program code together. The methodology also implies frequent deliveries and automated testing.

External supplier
A supplier/vendor that doesn’t belong to the same organization as the client/buyer. See also internal supplier.

Exploratory testing
A test design technique based on the tester’s experience; the tester creates the tests while he/she gets to know the system and executes the tests.

Expected result
A description of the test object’s expected status or behaviour after the test steps are completed. Part of the test case.

Exit criteria
Criteria that must be fulfilled for testing to be considered complete, such as that all high-priority test cases are executed, and that no open high-priority defect remains. Also known as completion criteria.

Exhaustive testing
A test approach in which you test all possible inputs and outputs.

Execute
Run, conduct. When a program is executing, it means that the program is running. When you execute or conduct a test case, you can also say that you are running the test case.

Error guessing
Experience-based test design technique where the tester develops test cases based on his/her skill and intuition, and experience with similar systems and technologies.

Error description
The section of a defect report where the tester describes the test steps he/she performed, what the outcome was, what result he/she expected, and any additional information that will assist in troubleshooting.

Error
A human action that produces an incorrect result.

Equivalence partitioning
A test design technique based on the fact that data in a system is managed in classes, such as intervals. Because of this, you only need to test a single value in every equivalence class. For example, you can assume that a calculator performs all addition operations in the same way; so if you test one addition operation, you have tested the entire equivalence class.

Entry criteria
Criteria that must be met before you can initiate testing, such as that the test cases and test plans are complete.

End-to-end testing
Testing used to test whether the performance of an application from start to finish conforms with the behaviour that is expected from it. This technique can be used to identify system dependencies and confirm the integrity of data transfer across different system components remains.

E

Dynamic testing
Testing performed while the system is running. Execution of test cases is one example.

DSDM
Dynamic Systems Development Method. An iterative development approach.

Driver
See test driver.

Document review
See review.

Desk checking
A static testing technique in which the tester reads code or a specification and “executes” it in his mind.

Deliverable
Any product that must be delivered to someone other than the author of the product. Examples of deliverables are documentation, code and the system.

Defect report
A document used to report a defect in a component, system, or document. Also known as an incident report.

Defect
A flaw in a component or system that can cause the component or system to fail to perform its required function. A defect, if encountered during execution, may cause a failure of the component or system.

Decision table
A test design and requirements specification technique. A decision table describes the logical conditions and rules for a system. Testers use the table as the basis for creating test cases.

Debugging
The process in which developers identify, diagnose, and fix errors found. See also bug and defect.

Daily build
A process in which the test object is compiled every day in order to allow daily testing. While it ensures that defect reports are reported early and regularly, it requires automated testing support.

D

COTS
Commercial Off the Shelf. Software that can be bought on the open market. Also called “packaged” software.

Context-driven testing
Testing which makes use of debugging techniques inspired by real-world usage conditions. It is a method of testing which encourages testers to develop testing opportunities based on the specific details of any given situation.

Configuration testing
A test to confirm that the system works under different configurations of hardware and software, such as testing a website using different browsers.

Configuration management
Routines for version control of documents and software/program code, as well as managing multiple system release versions.

Component testing
Test level that evaluates the smallest elements of the system. See also component. Also known as unit test, program test and module test.

Component integration testing
Another term for integration test.

Component
The smallest element of the system, such as class or a DLL.

Compilation
The activity of translating lines of code written in a human-readable programming language into machine code that can be executed by the computer.

Code standard
Description of how a programming language should be used within an organization. See also naming standard.

Code review
See Review.

Code coverage
A generic term for analysis methods that measure the proportion of code in a system that is executed by testing. Expressed as a percentage, for example, 90 % code coverage.

CMMI
Capability Maturity Model Integration. A framework for improving process efficiency in systems development and maintenance.

Client
The part of an organization that orders an IT system from the internal IT department or from an external supplier/vendor. See also supplier.

Checklist
A simpler form of test case, often merely a document with short test instructions (“one-liners”). An advantage of checklists is that they are easy to develop. A disadvantage is that they are less structured than test cases. Checklists can complement test cases well. In exploratory testing, checklists are often used instead of test cases.

Change request
A type of document describing a needed or desired change to the system.

Change control board
A group responsible for evaluating, prioritizing, and approving/rejecting requested changes to an IT system.

CCB
See change control board.

CAST
A general term for automated testing tools. Acronym for computer-aided software testing.

Capture/playback tool
See record and playback tool.

C

Bug
A slang term for fault, defect, or error. Originally used to describe actual insects causing malfunctions in mechanical devices that predate computers. The International Software Testing Qualifications Board (ISTQB) glossary explains that “a human being can make an error (mistake), which produces a defect (fault, bug) in the program code, or in a document. If a defect in code is executed, the system may fail to do what it should do (or do something it shouldn’t), causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so.” See also debugging.

BS 7925-2
A testing standards document that describes the testing process, primarily focusing on component testing. BS stands for ‘British Standard’.

BS 7925-1
A testing standards document containing a glossary of testing terms. BS stands for ‘British Standard’.

Boundary value analysis
A black box test design technique that tests input or output values that are on the edge of what is allowed or at the smallest incremental distance on either side of an edge. For example, an input field that accepts text between 1 and 10 characters has six boundary values: 0, 1, 2, 9, 10 and 11 characters.

Bottom-up integration
An integration testing strategy in which you start integrating components from the lowest level of the system architecture. Compare to big-bang integration and top-down integration.

Black box testing
Testing in which the test object is seen as a “black box” and the tester has no knowledge of its internal structure. The opposite of white box testing.

Big-bang integration
An integration testing strategy in which every component of a system is assembled and tested together; contrast with other integration testing strategies in which system components are integrated one at a time.

Beta testing
Test that comes after alpha tests, and is performed by people outside of the organization that built the system. Beta testing is especially valuable for finding usability flaws and configuration problems.

B

Anomaly
Any condition that deviates from expectations based on requirements specifications, design documents, standards etc. A good way to find anomalies is by testing the software.

Alpha testing
Operational testing conducted by potential users, customers, or an independent test team at the vendor’s site. Alpha testers should not be from the group involved in the development of the system, in order to maintain their objectivity. Alpha testing is sometimes used as acceptance testing by the vendor.

Agile development
A development method that emphasizes working in short iterations. Automated testing is often used. Requirements and solutions evolve through close collaboration between team members that represent both the client and supplier. (Also read: Agile Software Development- 5 Trends to Watch Out For In 2019)

Ad hoc testing
Testing carried out informally without test cases or other written test instructions.

Actual result
The system status or behaviour after you conduct a test. An anomaly or deviation is when your actual results differ from the expected results.

Here is the list of software testing terms:

Acceptance testing
The final test level. Conducted by users with the purpose to accept or reject the system before release.

JUnit
A framework for testing Java applications, specifically designed for automated testing of Java component