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. The capability of the software product to be installed in a specified environment [ISO 9126]. See also portability. The ease with which the software product can be transferred from one hardware or software environment to another. [ISO 9126]






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






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






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






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






6. A human action that produces an incorrect result. [After IEEE 610]






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






8. The ability to identify related items in documentation and software - such as requirements with associated tests. See also horizontal traceability - vertical traceability. The tracing of requirements for a test level through the layers of test docume






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






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






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






12. A way of developing software where the test cases are developed - and often automated - before the software is developed to run those test cases.






13. Testing to determine the security of the software product. See also functionality testing. The process of testing to determine the functionality of a software product.






14. Computer programs - procedures - and possibly associated documentation and data pertaining to the operation of a computer system. [IEEE 610]






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






16. A capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within specified process areas. [CMMI]






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






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






19. The tracing of requirements for a test level through the layers of test documentation (e.g. test plan - test design specification - test case specification and test procedure specification or test script).






20. An integration test type that is concerned with testing the interfaces between components or systems.






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






22. Testing that runs test cases that failed the last time they were run - in order to verify the success of corrective actions.






23. A white box test design technique in which test cases are designed to execute single condition outcomes that independently affect a decision outcome.






24. An approach to testing in which test cases are designed based on descriptions and/or knowledge of business processes.






25. A five level staged framework for test process improvement - related to the Capability Maturity Model (CMM) - that describes the key elements of an effective test process.






26. A white box test design technique in which test cases are designed to execute condition outcomes.






27. A reason or purpose for designing and executing a test.






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






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






30. The capability of the software product to be upgraded to accommodate increased loads. [After Gerrard]






31. A software product that is developed for the general market - i.e. for a large number of customers - and that is delivered to many customers in identical format.






32. A tool for seeding (i.e. intentionally inserting) faults in a component or system.






33. The percentage of all single condition outcomes that independently affect a decision outcome that have been exercised by a test case suite. 100% condition determination coverage implies 100% decision condition coverage.






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






35. An aggregation of hardware - software or both - that is designated for configuration management and treated as a single entity in the configuration management process. [IEEE 610]






36. The tracing of requirements through the layers of development documentation to components.






37. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified to make future maintenance easier - or adapted to a changed environment. [ISO 9126]






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






39. A tool that supports the test design activity by generating test inputs from a specification that may be held in a CASE tool repository - e.g. requirements management tool - from specified test conditions held in the tool itself - or from code.






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






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






42. The behavior produced/observed when a component or system is tested.






43. A five level staged framework that describes the key elements of an effective software process. The Capability Maturity Model covers best-practices for planning - engineering and managing software development and maintenance. [CMM] See also Capabilit






44. A path by which the original input to a process (e.g. data) can be traced back through the process - taking the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out. [After TMap]






45. (1) The capability of an organization with respect to the effectiveness and efficiency of its processes and work practices. See also Capability Maturity Model - Test Maturity Model. (2) The capability of the software product to avoid failure as a res






46. A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [After IEEE 829]






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






48. A skeletal or special-purpose implementation of a software component - used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component. [After IEEE 610]






49. The process of transforming general testing objectives into tangible test conditions and test cases.






50. A document that consists of a test design specification - test case specification and/or test procedure specification.