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 process of identifying risks using techniques such as brainstorming - checklists and failure history.






2. The degree - expressed as a percentage - to which a specified coverage item has been exercised by a test suite.






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






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






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






6. An entity or property used as a basis for test coverage - e.g. equivalence partitions or code statements.






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






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






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






10. The representation of a distinct set of tasks performed by the component or system - possibly based on user behavior when interacting with the component or system - and their probabilities of occurance. A task is logical rather that physical and can






11. The planning - estimating - monitoring and control of test activities - typically carried out by a test manager.






12. Testing practice for a project using agile methodologies - such as extreme programming (XP) - treating development as the customer of testing and emphasizing the test first design paradigm. See also test driven development. A way of developing softwa






13. An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed - e.g. statement coverage - decision coverage or condition coverage.






14. The ability to identify related items in documentation and software - such as requirements with associated tests. See also horizontal traceability - vertical traceability. The tracing of requirements for a test level through the layers of test docume






15. A special instance of a smoke test to decide if the component or system is ready for detailed and further testing. An intake test is typically carried out at the start of the test execution phase. See also smoke test. A subset of all defined/planned






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






17. A subset of all defined/planned test cases that cover the main functionality of a component or system - to ascertaining that the most crucial functions of a program work - but not bothering with finer details. A daily build and smoke test is among in






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






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






20. Procedure to derive and/or select test cases based on an analysis of the specification of the functionality of a component or system without reference to its internal structure. See also black box test design technique. Procedure to derive and/or sel






21. The ability of a system or component to continue normal operation despite the presence of erroneous inputs. [After IEEE 610].






22. Testing to determine the scalability of the software product.






23. A type of performance testing conducted to evaluate the behavior of a component or system with increasing load - e.g. numbers of parallel users and/or numbers of transactions - to determine what load can be handled by the component or system. See als






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






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






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






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






28. Testing performed to expose defects in the interfaces and interaction between integrated components.






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






30. The capability of the software product to provide appropriate performance - relative to the amount of resources used under stated conditions. [ISO 9126]






31. An instance of an output. See also output.A variable (whether stored within a component or outside) that is written by a component.






32. Testing - either functional or non-functional - without reference to the internal structure of the component or system. Black-box test design technique Procedure to derive and/or select test cases based on an analysis of the specification - either fu






33. A version of component integration testing where the progressive integration of components follows the implementation of subsets of the requirements - as opposed to the integration of components by levels of a hierarchy.






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






35. The process of assigning a number or category to an entity to describe an attribute of that entity. [ISO 14598]






36. Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure.






37. Execution of a test on a specific version of the test object.






38. A feature or characteristic that affects an item's quality. [IEEE 610]






39. A black box test design technique in which test cases are designed to execute business procedures and processes. [TMap] See also procedure testing. Testing aimed at ensuring that the component or system can operate in conjunction with new or existing






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






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






42. Supplied software on any suitable media - which leads the installer through the installation process. It normally runs the installation process - provides feedback on installation results - and prompts for options.






43. A system of (hierarchical) categories designed to be a useful aid for reproducibly classifying defects.






44. The process of testing to determine the functionality of a software product.






45. An environment containing hardware - instrumentation - simulators - software tools - and other support elements needed to conduct a test. [After IEEE 610]






46. The process of testing to determine the recoverability of a software product.






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






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






49. An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review - informal review - technical review - inspection - and walkthrough. [After IEEE 1028]






50. A program of activities designed to improve the performance and maturity of the organization's processes - and the result of such a program. [CMMI]