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 document specifying the test conditions (coverage items) for a test item - the detailed test approach and identifying the associated high level test cases. [After IEEE 829]






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






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






4. Two or more single conditions joined by means of a logical operator (AND - OR or XOR) - e.g. 'A>B AND C>1000'.






5. The process of testing to determine the portability of a software product.






6. The process of recognizing - investigating - taking action and disposing of defects. It involves recording defects - classifying them and identifying the impact. [After IEEE 1044]






7. Data that exists (for example - in a database) before a test is executed - and that affects or is affected by the component or system under test.






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






9. An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests. [After Bach]






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






11. An approach to testing in which test cases are designed based on the architecture and/or detailed design of a component or system (e.g. tests of interfaces between components or systems).






12. A development life cycle where a project is broken into a series of increments - each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the approp






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






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






15. The response of a component or system to a set of input values and preconditions.






16. Environmental and state conditions that must be fulfilled after the execution of a test or test procedure.






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






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






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






20. Directed and focused attempt to evaluate the quality - especially reliability - of a test object by attempting to force specific failures to occur.






21. Acronym for Computer Aided Software Engineering.






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






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






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






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






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






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






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






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






30. A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified work loads - or with reduced availability of resources such as access to memory or servers. [After IEEE 610] See also pe






31. A white box test design technique in which test cases are designed to execute paths.






32. A chronological record of relevant details about the execution of tests. [IEEE 829]






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






34. (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]






35. A type of test tool that enables data to be selected from existing databases or created - generated - manipulated and edited for use in testing.






36. A requirement that specifies a function that a component or system must perform. [IEEE 610]






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






38. A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation - correction and re-testing of defects and provide reporting facilities.






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






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






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






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






43. The percentage of all condition outcomes and decision outcomes that have been exercised by a test suite. 100% decision condition coverage implies both 100% condition coverage and 100% decision coverage.






44. The percentage of paths that have been exercised by a test suite. 100% path coverage implies 100% LCSAJ coverage.






45. A sequence of executable statements within a component.






46. During the test closure phase of a test process data is collected from completed activities to consolidate experience - testware - facts and numbers. The test closure phase consists of finalizing and archiving the testware and evaluating the test pro






47. A development activity where a complete system is compiled and linked every day (usually overnight) - so that a consistent system is available at any time including all latest changes.






48. A computational model consisting of a finite number of states and transitions between those states - possibly with accompanying actions. [IEEE 610]






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






50. A list of activities - tasks or events of the test process - identifying their intended start and finish dates and/or times - and interdependencies.