testing Comparison Table

Object Oriented Software Engineering View all facts Glossary Help

subject > process > verification > testing

Next verification: usability evaluation Up: verification Previous verification: inspection

testing comparison table

Subject use allow detect be part of involve has definition perform after be find is a subtopic of is a synonym of occur when

black-box testing providing the system with inputs and observing the outputs, without seeing what is going on inside A form of testing in which you manipulate inputs and observe outputs, but cannot observe the internals of the entity being tested less time consuming than glass-box testing defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.2 - Effective and Efficient Testing

boundary testing thinking of what could go wrong without actually studying the software A testing strategy based on testing at the boundaries of equivalence classes - since this is where most errors occur complementary to inspecting defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.3 - Defects in Ordinary Algorithms

effective testing a strategy that uncovers as many defects as possible thinking of what could go wrong without actually studying the software complementary to inspecting defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.2 - Effective and Efficient Testing

efficient testing thinking of what could go wrong without actually studying the software complementary to inspecting the largest possible number of defects using the fewest possible tests 10.2 - Effective and Efficient Testing

equivalence class testing thinking of what could go wrong without actually studying the software A testing strategy based on determining the possible equivalence classes and creating a test case for each complementary to inspecting defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.3 - Defects in Ordinary Algorithms

final testing thinking of what could go wrong without actually studying the software inspecting complementary to inspecting defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.10 - Inspections

glass-box testing the tester to be more thorough than black-box testing deadlock and livelock a formal testing process only when testing critical or complex components examining the design documents and the code, as well as observing at run time the steps taken by algorithms and their internal data A form of testing in which the tester can examine the design documents and the code, as well as analyze and possibly manipulate the internal state of the entity being tested more time consuming than black-box testing defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.2 - Effective and Efficient Testing white-box testing

object-oriented testing thinking of what could go wrong without actually studying the software Testing that focuses on the specific properties of object oriented programs complementary to inspecting defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.9 - Strategies for Testing Large Systems

stress testing thinking of what could go wrong without actually studying the software Testing on minimal configurations and at peak loads or with missing resources complementary to inspecting defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.6 - Defects in Handling Stress and Unusual Situations

testing performed by software engineers thinking of what could go wrong without actually studying the software complementary to inspecting defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.9 - Strategies for Testing Large Systems

testing performed by users and clients thinking of what could go wrong without actually studying the software complementary to inspecting defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting 10.9 - Strategies for Testing Large Systems the developers believe that the software has reached a sufficient level of quality (e.g. it is approaching the quality targets)

Subject	use	allow	detect	be part of	involve	has definition	perform after	be	find	is a subtopic of	is a synonym of	occur when
black-box testing					providing the system with inputs and observing the outputs, without seeing what is going on inside	A form of testing in which you manipulate inputs and observe outputs, but cannot observe the internals of the entity being tested		less time consuming than glass-box testing	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.2 - Effective and Efficient Testing
boundary testing					thinking of what could go wrong without actually studying the software	A testing strategy based on testing at the boundaries of equivalence classes - since this is where most errors occur		complementary to inspecting	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.3 - Defects in Ordinary Algorithms
effective testing	a strategy that uncovers as many defects as possible				thinking of what could go wrong without actually studying the software			complementary to inspecting	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.2 - Effective and Efficient Testing
efficient testing					thinking of what could go wrong without actually studying the software			complementary to inspecting	the largest possible number of defects using the fewest possible tests	10.2 - Effective and Efficient Testing
equivalence class testing					thinking of what could go wrong without actually studying the software	A testing strategy based on determining the possible equivalence classes and creating a test case for each		complementary to inspecting	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.3 - Defects in Ordinary Algorithms
final testing					thinking of what could go wrong without actually studying the software		inspecting	complementary to inspecting	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.10 - Inspections
glass-box testing		the tester to be more thorough than black-box testing	deadlock and livelock	a formal testing process only when testing critical or complex components	examining the design documents and the code, as well as observing at run time the steps taken by algorithms and their internal data	A form of testing in which the tester can examine the design documents and the code, as well as analyze and possibly manipulate the internal state of the entity being tested		more time consuming than black-box testing	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.2 - Effective and Efficient Testing	white-box testing
object-oriented testing					thinking of what could go wrong without actually studying the software	Testing that focuses on the specific properties of object oriented programs		complementary to inspecting	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.9 - Strategies for Testing Large Systems
stress testing					thinking of what could go wrong without actually studying the software	Testing on minimal configurations and at peak loads or with missing resources		complementary to inspecting	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.6 - Defects in Handling Stress and Unusual Situations
testing performed by software engineers					thinking of what could go wrong without actually studying the software			complementary to inspecting	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.9 - Strategies for Testing Large Systems
testing performed by users and clients					thinking of what could go wrong without actually studying the software			complementary to inspecting	defects whose consequences are obvious but which are buried in complex code, and thus will be hard to detect when inspecting	10.9 - Strategies for Testing Large Systems		the developers believe that the software has reached a sufficient level of quality (e.g. it is approaching the quality targets)

Next verification: usability evaluation Up: verification Previous verification: inspection