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 sequence of one or more consecutive executable statements containing no branches. Note: A node in a control flow graph represents a basic block.






2. Testing based on an analysis of the specification of the functionality of a component or system. See also black box testing. Testing - either functional or non-functional - without reference to the internal structure of the component or system. Black






3. The percentage of combinations of all single condition outcomes within one statement that have been exercised by a test suite. 100% multiple condition coverage implies 100% condition determination coverage.






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






5. A black box test design technique in which test cases are designed to execute valid and invalid state transitions. See also N-switch testing. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 tr






6. 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






7. Execution of a test on a specific version of the test object.






8. A test environment comprised of stubs and drivers needed to execute a test.






9. Analysis of source code carried out without execution of that software.






10. The insertion of additional code into the program in order to collect information about program behavior during execution - e.g. for measuring code coverage.






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






12. The organizational artifacts needed to perform testing - consisting of test environments - test tools - office environment and procedures.






13. The process of recognizing - investigating - taking action and disposing of incidents. It involves logging incidents - classifying them and identifying the impact. [After IEEE 1044]






14. The ratio of the number of failures of a given category to a given unit of measure - e.g. failures per unit of time - failures per number of transactions - failures per number of computer runs. [IEEE 610]






15. The ease with which the software product can be transferred from one hardware or software environment to another. [ISO 9126]






16. A source of a defect such that if it is removed - the occurance of the defect type is decreased or removed. [CMMI]






17. Testing of software used to convert data from existing systems for use in replacement systems.






18. A tool that provides run-time information on the state of the software code. These tools are most commonly used to identify unassigned pointers - check pointer arithmetic and to monitor the allocation - use and de-allocation of memory and to flag mem






19. An abstract representation of all possible sequences of events (paths) in the execution through a component or system.






20. A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actuals to that which was planned. See also test management. The planning - estimating - monito






21. A sequence of events - e.g. executable statements - of a component or system from an entry point to an exit point.






22. A scheme for the execution of test procedures. The test procedures are included in the test execution schedule in their context and in the order in which they are to be executed.






23. 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]






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






25. An element of configuration management - consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification - the status of proposed






26. The period of time in the software life cycle during which the requirements for a software product are defined and documented. [IEEE 610]






27. The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions. [ISO 9126]






28. The capability of the software product to co-exist with other independent software in a common environment sharing common resources. [ISO 9126] See also portability. The ease with which the software product can be transferred from one hardware or sof






29. A test case without concrete (implementation level) values for input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available. See also low level test case. A test case with concrete (






30. 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.






31. A flaw in a component or system that can cause the component or system to fail to perform its required function - e.g. an incorrect statement or data definition. A defect - if encountered during execution - may cause a failure of the component or sys






32. 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






33. Testing to determine the extent to which the software product is understood - easy to learn - easy to operate and attractive to the users under specified conditions. [After ISO 9126]






34. The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms - e.g. lines-of-code - number of classes or function points).






35. A tool that provides support to the test management and control part of a test process. It often has several capabilities - such as testware management - scheduling of tests - the logging of results - progress tracking - incident management and test






36. The capability of the software product to be used in place of another specified software product for the same purpose in the same environment. [ISO 9126] See also portability. The ease with which the software product can be transferred from one hardw






37. The capability of the software product to interact with one or more specified components or systems. [After ISO 9126] See also functionality. The capability of the software product to provide functions which meet stated and implied needs when the sof






38. An attribute of a component or system specified or implied by requirements documentation (for example reliability - usability or design constraints). [After IEEE 1008]






39. A distinct set of test activities collected into a manageable phase of a project - e.g. the execution activities of a test level. [After Gerrard]






40. [Beizer] 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.






41. The last executable statement within a component.






42. A set of test cases derived from the internal structure of a component or specification to ensure that 100% of a specified coverage criterion will be achieved.






43. An environment containing hardware - instrumentation - simulators - software tools - and other support elements needed to conduct a test. [After IEEE 610]






44. The percentage of LCSAJs of a component that have been exercised by a test suite. 100% LCSAJ coverage implies 100% decision coverage.






45. An integration approach that combines the components or systems for the purpose of getting a basic functionality working early. See also integration testing. Testing performed to expose defects in the interfaces and in the interactions between integr






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






47. A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system. [After TMap]






48. A portion of an input or output domain for which the behavior of a component or system is assumed to be the same - based on the specification.






49. A Linear Code Sequence And Jump - consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements - the end of the linear sequence - and the targe






50. A white box test design technique in which test cases are designed to execute paths.