Test your basic knowledge |

Instructions:
  • Answer 50 questions in 15 minutes.
  • If you are not ready to take this test, you can study here.
  • Match each statement with the correct term.
  • Don't refresh. All questions and answers are randomly picked and ordered every time you load a test.

This is a study tool. The 3 wrong answers for each question are randomly chosen from answers to other questions. So, you might find at times the answers obvious, but you will see it re-enforces your understanding as you take the test each time.
1. A systematic way of testing all-pair combinations of variables using orthogonal arrays. It significantly reduces the number of all combinations of variables to test all pair combinations. See also pairwise testing. A black box test design technique i






2. The level of (business) importance assigned to an item - e.g. defect.






3. The association of the definition of a variable with the use of that variable. Variable uses include computational (e.g. multiplication) or to direct the execution of a path ("predicate" use).






4. The process of testing to determine the resource-utilization of a software product. See also efficiency testing. The process of testing to determine the efficiency of a software product.






5. A white box test design technique in which test cases are designed to execute definition and use pairs of variables.






6. An approach to testing in which test cases are designed based on the architecture and/or detailed design of a component or system (e.g. tests of interfaces between components or systems).






7. A test tool to perform automated test comparison of actual results with expected results.






8. Testing to determine the scalability of the software product.






9. Method aiming to measure the size of the functionality of an information system. The measurement is independent of the technology. This measurement may be used as a basis for the measurement of productivity - the estimation of the needed resources -






10. A test plan that typically addresses one test phase. See also test plan. A document describing the scope - approach - resources and schedule of intended test activities. It identifies amongst others test items - the features to be tested - the testin






11. A tool that facilitates the recording and status tracking of incidents. They often have workflow-oriented facilities to track and control the allocation - correction and re-testing of incidents and provide reporting facilities. See also defect manage






12. An element of configuration management - consisting of the evaluation - co-ordination - approval or disapproval - and implementation of changes to configuration items after formal establishment of their configuration identification. [IEEE 610]






13. Testing the attributes of a component or system that do not relate to functionality - e.g. reliability - efficiency - usability - maintainability and portability.






14. The degree to which a component - system or process meets specified requirements and/or user/customer needs and expectations. [After IEEE 610]






15. An abstract representation of the sequence and possible changes of the state of data objects - where the state of an object is any of: creation - usage - or destruction. [Beizer]






16. A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available - e.g. case - jump - go to - if-then-else.






17. The percentage of condition outcomes that have been exercised by a test suite. 100% condition coverage requires each single condition in every decision statement to be tested as True and False.






18. Testing where components or systems are integrated and tested one or some at a time - until all the components or systems are integrated and tested.






19. The set from which valid input values can be selected. See also domain. The set from which valid input and/or output values can be selected.






20. The process of testing to determine the maintainability of a software product.






21. Code that cannot be reached and therefore is impossible to execute.






22. A software product that supports one or more test activities - such as planning and control - specification - building initial files and data - test execution and test analysis. [TMap] See also CAST. Acronym for Computer Aided Software Testing.






23. A description of a component's function in terms of its output values for specified input values under specified conditions - and required non-functional behavior (e.g. resource utilization).






24. A scale that constrains the type of data analysis that can be performed on it. [ISO 14598]






25. The total costs incurred on quality activities and issues and often split into prevention costs - appraisal costs - internal failure costs and external failure costs.






26. A test case with concrete (implementation level) values for input data and expected results. Logical operators from high level test cases are replaced by actual values that correspond to the objectives of the logical operators. See also high level te






27. The number or category assigned to an attribute of an entity by making a measurement. [ISO 14598]






28. The process of testing to determine the interoperability of a software product. See also functionality testing. The process of testing to determine the functionality of a software product.






29. A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.






30. Testing that involves the execution of the software of a component or system.






31. Directed and focused attempt to evaluate the quality - especially reliability - of a test object by attempting to force specific failures to occur.






32. The ability of a system or component to continue normal operation despite the presence of erroneous inputs. [After IEEE 610].






33. A framework to describe the software development life cycle activities from requirements specification to maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development life cycle.






34. An occurrence in which one defect prevents the detection of another. [After IEEE 610]






35. Procedure to derive and/or select test cases based on an analysis of the specification of the functionality of a component or system without reference to its internal structure. See also black box test design technique. Procedure to derive and/or sel






36. The individual element to be tested. There usually is one test object and many test items. See also test object. A reason or purpose for designing and executing a test.






37. A device or storage area used to store data temporarily for differences in rates of data flow - time or occurrence of events - or amounts of data that can be handeld by the devices or processes involved in the transfer or use of the data. [IEEE 610]






38. A technique used to characterize the elements of risk. The result of a hazard analysis will drive the methods used for development and testing of a system. See also risk analysis. The process of assessing identified risks to estimate their impact and






39. Deviation of the component or system from its expected delivery - service or result. [After Fenton]






40. A sequence of transactions in a dialogue between a user and the system with a tangible result.






41. A model that shows the growth in reliability over time during continuous testing of a component or system as a result of the removal of defects that result in reliability failures.






42. A tool that supports operational security.






43. The process of combining components or systems into larger assemblies.






44. The process of testing to determine the recoverability of a software product. See also reliability testing. The process of testing to determine the reliability of a software product.






45. An extension of FMEA - as in addition to the basic FMEA - it includes a criticality analysis - which is used to chart the probability of failure modes against the severity of their consequences. The result highlights failure modes with relatively hig






46. A group of test activities aimed at testing a component or system focused on a specific test objective - i.e. functional test - usability test - regression test etc. A test type may take place on one or more test levels or test phases. [After TMap]






47. An incremental approach to integration testing where the component at the top of the component hierarchy is tested first - with lower level components being simulated by stubs. Tested components are then used to test lower level components. The proce






48. A variable (whether stored within a component or outside) that is read by a component.






49. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 transitions. [Chow] See also state transition testing. A black box test design technique in which test cases are designed to execute valid and i






50. Software developed specifically for a set of users or customers. The opposite is off-the-shelf software.