Glossary of Software Testing Terms Provided by Testing Realms

Glossary of Software Testing Terms: P

This glossary of software testing terms and conditions is a compilation of knowledge, gathered over time, from many different sources. It is provided “as-is” in good faith, without any warranty as to the accuracy or currency of any definition or other information contained herein. If you have any questions or queries about the contents of this glossary, please contact Project Realms directly.

Pacing Peer Review Priority
Page Fault Performance Process
Pair Programming Performance Testing Process Cycle Test
Pair Testing Portability Production Environment
Pairwise Testing Portability Requirements Progressive Testing
Partial Test Automation Portability Testing Project
Pass Post Condition Project Test Plan
Pass/Fail Criteria Positive Testing Promotion Recommendation Report
Path Precondition Prototyping
Path Coverage Predicate Pseudo-Random
Path Sensitizing Predication  
Path Testing Predicated Outcome  

This refers to the number of seconds between finishing one script execution for a VU and starting the next iteration.


Page Fault
A program interruption that occurs when a page that is marked 'not in real memory' is referred to by an active page.

Pair Programming
A software development technique that requires two programmers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: for example, while one types in unit tests, the other thinks about the class that will satisfy the test.

The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made. It is also suggested to switch partners at least once a day.

Pair Testing
In much the same way as Pair Programming, two testers work together to find defects. Typically, they share one computer and trade control of it while testing.

Pairwise Testing
A combinatorial software testing method that, for each pair of input parameters to a system (typically, a software algorithm) tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by "parallelizing" the tests of parameter pairs. The number of tests is typically O(nm), where n and m are the number of possibilities for each of the two parameters with the most choices.

The reasoning behind all-pairs testing is this: the simplest bugs in a program are generally triggered by a single input parameter. The next simplest category of bugs consists of those dependent on interactions between pairs of parameters, which can be caught with all-pairs testing. Bugs involving interactions between three or more parameters are progressively less common, while at the same time being progressively more expensive to find by exhaustive testing, which has as its limit the exhaustive testing of all possible inputs.

Many testing methods regard all-pairs testing of a system or subsystem as a reasonable cost-benefit compromise between often computationally infeasible higher-order combinatorial testing methods, and less exhaustive methods which fail to exercise all possible pairs of parameters. Because no testing technique can find all bugs, all-pairs testing is typically used together with other quality assurance techniques such as unit testing.

Partial Test Automation
The process of automating parts but not all of the software testing process. If, for example, fully automated tests cannot reasonably be created or would be too difficult to maintain, then a software tools engineer can instead create testing tools to help human testers perform their jobs more efficiently. Testing tools can help automate tasks such as product installation, test data creation, GUI interaction, problem detection, defect logging, etc., without necessary automating tests in an end-to-end fashion.

Software has deemed to have passed a test if the actual results of the test matched the expected results.

Pass/Fail Criteria
Decision rules used to determine whether an item under test has passed or failed a test.

A sequence of executable statements of a component, from an entry point to an exit point.

Path Coverage
The percentage of paths in a component exercised by a test case suite.

Path Sensitizing
Choosing a set of input values to force the execution of a component to take a given path.

Path Testing
Used as either black box or white box testing, the procedure itself is similar to a walk-through. First, a certain path through the program is chosen. Possible inputs and the correct result are written down. Then the program is executed by hand, and its result is compared to the predefined. Possible faults have to be written down at once

Peer Review
A peer review is when others with similar jobs and/or functions review the work completed to determine if it meets expectations and requirements. The peers will exchange ideas, tips and techniques and suggest changes and improvements.

The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput.


Performance Testing
Performance testing is a general term used to describe testing activities where a simulated user load is directed at a system and measurements are gathered. It is designed to meet or exceed a set of system performance goals while maintaining a particular user load profile. It places variable load - from a minimum to a maximum - on the system. The variable load demonstrates what the system can sustain without running out of resource or having transactions perform in a less-than-optimal fashion.
Performance testing is a suite of testing that can consists of, but is not limited to, Benchmark Testing, Load Testing, Durability Testing, Volume Testing, Stress Testing, and Scalability Testing. In some cases a separate Performance Test Plan will be created to explain the details of the Performance Testing effort.

  • Benchmark Testing: Benchmark testing is a performance test which subjects the system to varying workloads to measure and evaluate the performance behaviors and ability of the system to continue to function properly under these different workloads.
  • Durability Testing: Durability testing is designed to determine the characteristics of a system under load conditions, over time. This is an excellent test to identify memory leaks in a system.
  • Load Testing: Load testing is a performance test which subjects the system to varying workloads to measure and evaluate the performance behaviors and ability of the system to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).
  • Scalability Testing: Scalability Testing determines the ability of a system to expand as the usage increases. It measures individual components of the system to determine their performance characteristics under increasing user loads. It also examines inter-component and multiple component behavior.
  • Stress Testing: Stress Testing determines the ability of the application to perform under low and/or excessive loads to ensure that critical information and services are available when and how the end-user expects it. In addition, it is also a way to identify and document conditions under which the system fails to continue functioning properly.
  • Volume Testing: Volume Testing subjects the target-of-test to large amounts of data to determine if limits are reached that cause the software to fail. Volume testing also identifies the continuous maximum load or volume the target-of-test can handle for a given period.
NOTE: Transactions above refer to "logical business transactions." These transactions are defined as specific functions that an end user of the system is expected to perform using the application, such as add or modify a given contract.

The ease with which the system/software can be transferred from one hardware or software environment to another.

Portability Requirements
A specification of the required portability for the system /software.

Portability Testing
The process of testing the ease with which a software component can be moved from one environment to another. This is typically measured in terms of the maximum amount of effort permitted. Results are expressed in terms of the time required to move the software and complete data conversion and documentation updates.

Environmental and state conditions that must be fulfilled after the execution of a test or test procedure.

Positive Testing
Testing aimed at showing whether the software works in the way intended.

Environmental and state conditions which must be fulfilled before the component can be executed with a particular input value.

A logical expression which evaluated to TRUE or FALSE, normally to direct the execution path in code.

The choice to execute or not to execute a given instruction.

Predicated Outcome
The behavior expected by the specification of an object under specified conditions.

The level of business importance assigned to an individual item or test.

A course of action that turns inputs into outputs or results.

Process Cycle Test
A black box test design technique in which test cases are designed to execute business procedures and processes.

Production Environment
The Production environment provides users access to stable and fully functional application and operating system.

Progressive Testing
Testing of new features after regression testing of previous features.

A planned undertaking for presentation of results at a specified time in the future.

Project Test Plan
The test plan is created for each project in order to expand on the test strategy and define the workflow. It will describe in greater detail how to test the business requirements, assess any specific risks, contain system configurations, establish entrance and exit criteria to testing phase, state data needs, and contain any other system specific information needed. It describes the objectives, scope, approach and focus of a software testing effort.

Promotion Recommendation Report
Promotion Recommendations are completed prior to the migration of code from one environment to the next. Recommendations are based on information compiled during Test Readiness Assessments and Test Execution. The Test Team's Promotion Recommendation is a contributing factor in the Project Team's decision of whether or not the system should promote to the next environment.

A strategy in system development in which a scaled down system or potion of a system is constructed in a short time, then tested and improved upon over several iterations.

A series which appears to be random but is in fact generated according to some prearranged sequence.

| Contact us for more info