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






2. A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows a deviation from what was planned. See also test management. The planning - estimating - monitoring and co






3. The percentage of executable statements that have been exercised by a test suite.






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






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






6. The capability of the software product to be diagnosed for deficiencies or causes of failures in the software - or for the parts to be modified to be identified. [ISO 9126] See also maintainability. The ease with which a software product can be modif






7. A form of static analysis based on the definition and usage of variables.






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






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






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






11. A logical expression that can be evaluated as True or False - e.g. A>B. See also test condition. 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






12. The process of testing to determine the recoverability of a software product. See also reliability testing. The process of testing to determine the reliability of a software product.






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






14. Behavior of a component or system in response to erroneous input - from either a human user or from another component or system - or to an internal failure.






15. Testing to determine the robustness of the software product.






16. A continuous framework for test process improvement that describes the key elements of an effective test process - especially targeted at system testing and acceptance testing.






17. Testing in which two or more variants of a component or system are executed with the same inputs - the outputs compared - and analyzed in cases of discrepancies. [IEEE 610]






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






19. The capability of the software product to avoid unexpected effects from modifications in the software. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements






20. A test approach in which the test suite comprises all combinations of input values and preconditions.






21. The process of combining components or systems into larger assemblies.






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






23. A tool that provides an environment for unit or component testing in which a component can be tested in isolation or with suitable stubs and drivers. It also provides other support for the developer - such as debugging capabilities. [Graham]






24. A document reporting on any event that occurred - e.g. during the testing - which requires investigation. [After IEEE 829]






25. A statement of test objectives - and possibly test ideas about how to test. Test charters are used in exploratory testing. See also exploratory testing. An informal test design technique where the tester actively controls the design of the tests as t






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






27. A formula based test estimation method based on function point analysis. [TMap]






28. A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects) - which can be used to design test cases.






29. The set of generic and specific conditions - agreed upon with the stakeholders - for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding p






30. A grid showing the resulting transitions for each state combined with each possible event - showing both valid and invalid transitions.






31. A review characterized by documented procedures and requirements - e.g. inspection.






32. Modification of a software product after delivery to correct defects - to improve performance or other attributes - or to adapt the product to a modified environment. [IEEE 1219]






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






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






35. A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches.






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






37. A tool to support performance testing and that usually has two main facilities: load generation and test transaction measurement. Load generation can simulate either multiple users or high volumes of input data. During execution - response time measu






38. The data received from an external source by the test object during test execution. The external source can be hardware - software or human.






39. A tool that provides support for the identification and control of configuration items - their status over changes and versions - and the release of baselines consisting of configuration items.






40. A tool that provides support for testing security characteristics and vulnerabilities.






41. The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage.






42. A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).






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






44. The process of developing and prioritizing test procedures - creating test data and - optionally - preparing test harnesses and writing automated test scripts.






45. Acronym for Computer Aided Software Testing. See also test automation.The use of software to perform or support test activities - e.g. test management - test design - test execution and results checking.






46. A technique used to analyze the causes of faults (defects). The technique visually models how logical relationships between failures - human errors - and external events can combine to cause specific faults to disclose.






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






48. A distinct set of test activities collected into a manageable phase of a project - e.g. the execution activities of a test level. [After Gerrard]






49. The physical or functional manifestation of a failure. For example - a system in failure mode may be characterized by slow operation - incorrect outputs - or complete termination of execution. [IEEE 610]






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