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 source to determine expected results to compare with the actual result of the software under test. An oracle may be the existing system (for a benchmark) - a user-manual - or an individual's specialized knowledge - but should not be the code. [Afte






2. A data item that specifies the location of another data item; for example - a data item that specifies the address of the next employee record to be processed. [IEEE 610]






3. The last executable statement within a component.






4. An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review - informal review - technical review - inspection - and walkthrough. [After IEEE 1028]






5. Comparison of actual and expected results - performed while the software is being executed - for example by a test execution tool.






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






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






8. A form of static analysis based on the definition and usage of variables.






9. Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled. [ISO 9000]






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






11. The result of a decision (which therefore determines the branches to be taken).






12. The process of identifying differences between the actual results produced by the component or system under test and the expected results for a test. Test comparison can be performed during test execution (dynamic comparison) or after test execution.






13. A document produced at the end of the test process summarizing all testing activities and results. It also contains an evaluation of the test process and lessons learned.






14. Formal testing with respect to user needs - requirements - and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user - customers or other authorized entity to determine whether or n






15. A detailed check of the test basis to determine whether the test basis is at an adequate quality level to act as an input document for the test process. [After TMap]






16. 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).






17. A test whereby real-life users are involved to evaluate the usability of a component or system.






18. A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support automated regression testing.






19. The capability of the software product to enable modified software to be tested. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified to make fut






20. The effect on the component or system by the measurement instrument when the component or system is being measured - e.g. by a performance testing tool or monitor. For example performance may be slightly worse when performance testing tools are being






21. Hardware and software products installed at users' or customers' sites where the component or system under test will be used. The software may include operating systems - database management systems - and other applications.






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






23. The testing activities that must be repeated when testing is re-started after a suspension. [After IEEE 829]






24. The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions. [IEEE 610] See also error-tolerance - fault-tolerance. The ability of a system or component to continue normal o






25. Separation of responsibilities - which encourages the accomplishment of objective testing. [After DO-178b]






26. An element of storage in a computer that is accessible by a software program by referring to it by a name.






27. The degree to which a requirement is stated in terms that permit establishment of test designs (and subsequently test cases) and execution of tests to determine whether the requirements have been met. [After IEEE 610]






28. A sequence of events (paths) in the execution through a component or system.






29. A project is a unique set of coordinated and controlled activities with start and finish dates undertaken to achieve an objective conforming to specific requirements - including the constraints of time - cost and resources. [ISO 9000]






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






31. A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection - technical review and walkthrough.






32. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing - system integration testing. Testing performed to expose defects in the interfaces and int






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






34. A type of peer review that relies on visual examination of documents to detect defects - e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a docu






35. The testing of individual software components. [After IEEE 610]






36. A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects) - which can be used to design test cases.






37. A procedure to derive and/or select test cases targeted at one or more defect categories - with tests being developed from what is known about the specific defect category. See also defect taxonomy. A system of (hierarchical) categories designed to b






38. Testing of a component or system at specification or implementation level without execution of that software - e.g. reviews or static code analysis.






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






40. The capability of the software product to adhere to standards - conventions or regulations in laws and similar prescriptions. [ISO 9126]






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






42. Execution of the test process against a single identifiable release of the test object.






43. A document that specifies - ideally in a complete - precise and verifiable manner - the requirements - design - behavior - or other characteristics of a component or system - and - often - the procedures for determining whether these provisions have






44. A white box test design technique in which test cases are designed to execute decision outcomes.






45. A tool that provides an environment for unit or component testing in which a component can be tested in isolation or with suitable stubs and drivers. It also provides other support for the developer - such as debugging capabilities. [Graham]






46. Testing using input values that should be rejected by the component or system. See also error tolerance. The ability of a system or component to continue normal operation despite the presence of erroneous inputs. [After IEEE 610].






47. A black box test design technique in which test cases are designed to execute all possbile discrete combinations of each pair of input parameters. See also orthogonal array testing. A systematic way of testing all-pair combinations of variables using






48. A point in time in a project at which defined (intermediate) deliverables and results should be ready.






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






50. The capability of the software product to use appropriate amounts and types of resources - for example the amounts of main and secondary memory used by the program and the sizes of required temporary or overflow files - when the software performs its