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 set of input values - execution preconditions - expected results and execution postconditions - developed for a particular objective or test condition - such as to exercise a particular program path or to verify compliance with a specific requireme






2. Deviation of the component or system from its expected delivery - service or result. [After Fenton]






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






4. A black box test design technique in which test cases - described by means of a classification tree - are designed to execute combinations of representatives of input and/or output domains. [Grochtmann]






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






6. Supplied instructions on any suitable media - which guides the installer through the installation process. This may be a manual guide - step-by-step procedure - installation wizard - or any other similar process description.






7. The ability of the software product to perform its required functions under stated conditions for a specified period of time - or for a specified number of operations. [ISO 9126]






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






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






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






11. Acronym for Computer Aided Software Engineering.






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. Testing the changes to an operational system or the impact of a changed environment to an operational system.






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






15. Testing that involves the execution of the software of a component or system.






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






17. A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract - standard - specification - or other formally imposed document. [After IEEE 610






18. The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).






19. A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content. [Freedman and Weinberg - IEEE 1028] See also peer review. A review of a software work product by colleagues






20. The percentage of boundary values that have been exercised by a test suite.






21. An attribute of a test indicating whether the same results are produced each time the test is executed.






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






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






24. A tree showing equivalence parititions hierarchically ordered - which is used to design test cases in the classification tree method. See also classification tree method. A black box test design technique in which test cases - described by means of a






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






26. Procedure to derive and/or select test cases based on the tester's experience - knowledge and intuition.






27. Testing by means of a random selection from a large range of inputs and by randomly pushing buttons - ignorant on how the product is being used.






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






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






30. The capability of the software product to enable the user to understand whether the software is suitable - and how it can be used for particular tasks and conditions of use. [ISO 9126] See also usability. The capability of the software to be understo






31. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange - Internet).






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






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






34. The process of testing to determine the reliability of a software product.






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






36. The composition of a component or system as defined by the number - nature - and interconnections of its constituent parts.






37. The process consisting of all life cycle activities - both static and dynamic - concerned with planning - preparation and evaluation of software products and related work products to determine that they satisfy specified requirements - to demonstrate






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






39. A white box test design technique in which test cases are designed to execute LCSAJs.






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






41. A black box test design technique in which test cases are designed to execute the combinations of inputs and/or stimuli (causes) shown in a decision table. [Veenendaal] See also decision table. A table showing combinations of inputs and/or stimuli (c






42. A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases. See also operational profile testing. Statistical testing using a model of system operations (short duration tasks)






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






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






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






46. The process of identifying risks using techniques such as brainstorming - checklists and failure history.






47. A test plan that typically addresses one test level. 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






48. The process of running a test on the component or system under test - producing actual result(s).






49. (1) A standard against which measurements or comparisons can be made. (2) A test that is be used to compare components or systems to each other or to a standard as in (1). [After IEEE 610]






50. A programming language in which executable test scripts are written - used by a test execution tool (e.g. a capture/playback tool).