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. An item or event of a component or system that could be verified by one or more test cases - e.g. a function - transaction - feature - quality attribute - or structural element.






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






3. Testing aimed at ensuring that the component or system can operate in conjunction with new or existing users' business procedures or operational procedures.






4. Testing conducted to evaluate a component or system in its operational environment. [IEEE 610]






5. The set from which valid input and/or output values can be selected.






6. An analysis technique aimed at identifying the root causes of defects. By directing corrective measures at root causes - it is hoped that the likelihood of defect recurrence will be minimized.






7. An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements - e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.






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






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






10. A test is deemed to fail if its actual result does not match its expected result.






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






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






13. The capability of the software product to enable the user to operate and control it. [ISO 9126] See also usability. The capability of the software to be understood - learned - used and attractive to the user when used under specified conditions. [ISO






14. The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality testing. Testing based on an analysis of the specification of the functionality of a compo






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






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






17. The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs. [After ISO 9126]






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






19. Testing of individual components in isolation from surrounding components - with surrounding components being simulated by stubs and drivers - if needed.






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






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






22. A tool used to check that no brtoken hyperlinks are present on a web site.






23. A test result in which a defect is reported although no such defect actually exists in the test object.






24. Decision rules used to determine whether a test item (function) or feature has passed or failed a test. [IEEE 829]






25. A high level metric of effectiveness and/or efficiency used to guide and control progressive test development - e.g. Defect Detection Percentage (DDP).






26. The set of generic and specific conditions for permitting a process to go forward with a defined task - e.g. test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort n






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






28. A device - computer program or system used during testing - which behaves or operates like a given system when provided with a set of controlled inputs. [After IEEE 610 - DO178b] See also emulator. A device - computer program - or system that accepts






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






30. The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface. [ISO 9126] See also reliability - robustness. The ability of the software product






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






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






33. A black box test design technique in which test cases are designed based on boundary values. See also boundary value. An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either si






34. A high level metric of effectiveness and/or efficiency used to guide and control progressive development - e.g. lead-time slip for software development. [CMMI]






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






36. A defect in a program's dynamic store allocation logic that causes it to fail to reclaim memory after it has finished using it - eventually causing the program to fail due to lack of memory.






37. An instance of an input. See also input. A variable (whether stored within a component or outside) that is read by a component.






38. The use of software to perform or support test activities - e.g. test management - test design - test execution and results checking.






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






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






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






42. A tool that carries out static analysis.






43. Measurement of achieved coverage to a specified coverage item during test execution referring to predetermined criteria to determine whether additional testing is required and if so - which test cases are needed.






44. Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled. [ISO 9000]






45. A tool that carries out static code analysis. The tool checks source code - for certain properties such as conformance to coding standards - quality metrics or data flow anomalies.






46. A tool that supports the recording of requirements - requirements attributes (e.g. priority - knowledge responsible) and annotation - and facilitates traceability through layers of requirements and requirements change management. Some requirements ma






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






48. The process of evaluating behavior - e.g. memory performance - CPU usage - of a system or component during execution. [After IEEE 610]






49. Definition of user profiles in performance - load and/or stress testing. Profiles should reflect anticipated or actual usage based on an operational profile of a component or system - and hence the expected workload. See also load profile - operation






50. A black box test design technique in which test cases are designed to execute user scenarios.