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 tool that provides support to the review process. Typical features include review planning and tracking support - communication support - collaborative reviews and a repository for collecting and reporting of metrics.






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






3. The percentage of sequences of N+1 transitions that have been exercised by a test suite. [Chow]






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






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






6. The component or system to be tested. See also test item. 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.






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






8. A tool used by programmers to reproduce failures - investigate the state of programs and find the corresponding defect. Debuggers enable programmers to execute programs step by step - to halt a program at any program statement and to set and examine






9. The percentage of definition-use pairs that have been exercised by a test suite.






10. The representation of selected behavioral characteristics of one physical or abstract system by another system. [ISO 2382/1]






11. A specification of the activity which a component or system being tested may experience in production. A load profile consists of a designated number of virtual users who process a defined set of transactions in a specified time period and according






12. The leader and main person responsible for an inspection or other review process.






13. An approach to testing to reduce the level of product risks and inform stakeholders on their status - starting in the initial stages of a project. It involves the identification of product risks and their use in guiding the test process.






14. Any (work) product that must be delivered to someone other than the (work) product's author.






15. A tool that carries out static analysis.






16. A system whose failure or malfunction may result in death or serious injury to people - or loss or severe damage to equipment - or environmental harm.






17. The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate. [After IEEE 610] See also efficiency. The capability of the software product to provide appropriat






18. Attributes of software products that bear on its ability to prevent unauthorized access - whether accidental or deliberate - to programs and data. [ISO 9126] See also functionality. The capability of the software product to provide functions which me






19. A model structure wherein attaining the goals of a set of process areas establishes a maturity level; each level builds a foundation for subsequent levels. [CMMI]






20. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [After IEEE 829]






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






22. A device - computer program - or system that accepts the same inputs and produces the same outputs as a given system. [IEEE 610] See also simulator. A device - computer program or system used during testing - which behaves or operates like a given sy






23. A high level document describing the principles - approach and major objectives of the organization regarding testing.






24. A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria. [After IEEE 829]






25. Acronym for Commercial Off-The-Shelf software. See off-the-shelf software. 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.






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






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






28. The process of finding - analyzing and removing the causes of failures in software.






29. Procedure to derive and/or select test cases for nonfunctional testing based on an analysis of the specification of a component or system without reference to its internal structure. See also black box test design technique. Procedure to derive and/o






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






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






32. The capability of the software product to enable specified modifications to be implemented. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified






33. Procedure used to derive and/or select test cases.






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






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






36. The process of testing to determine the efficiency of a software product.






37. The function to check on the contents of libraries of configuration items - e.g. for standards compliance. [IEEE 610]






38. A set of several test cases for a component or system under test - where the post condition of one test is often used as the precondition for the next one.






39. A white box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement).






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






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






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






43. Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers - to determine whether or not a component or system satisfies the user/customer needs and fits within the business process






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






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






46. A minimal software item that can be tested in isolation.






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






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






49. The fundamental test process comprises test planning and control - test analysis and design - test implementation and execution - evaluating exit criteria and reporting - and test closure activities.






50. A pointer within a web page that leads to other web pages.