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 risk related to management and control of the (test) project - e.g. lack of staffing - strict deadlines - changing requirements - etc. See also risk. A factor that could result in future negative consequences; usually expressed as impact and likeli






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






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






4. A device or storage area used to store data temporarily for differences in rates of data flow - time or occurrence of events - or amounts of data that can be handeld by the devices or processes involved in the transfer or use of the data. [IEEE 610]






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






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






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






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






9. A document specifying a set of test cases (objective - inputs - test actions - expected results - and execution preconditions) for a test item. [After IEEE 829]






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






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






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






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






14. A software tool or hardware device that runs concurrently with the component or system under test and supervises - records and/or analyses the behavior of the component or system. [After IEEE 610]






15. Testing of software used to convert data from existing systems for use in replacement systems.






16. A document that consists of a test design specification - test case specification and/or test procedure specification.






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






18. A description of a component's function in terms of its output values for specified input values under specified conditions - and required non-functional behavior (e.g. resource utilization).






19. An extension of FMEA - as in addition to the basic FMEA - it includes a criticality analysis - which is used to chart the probability of failure modes against the severity of their consequences. The result highlights failure modes with relatively hig






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






21. A document identifying test items - their configuration - current status and other delivery information delivered by development to testing - and possibly other stakeholders - at the start of a test execution phase. [After IEEE 829]






22. A specification of the activity which a component or system being tested may experience in production. A load profile consists of a designated number of virtual users who process a defined set of transactions in a specified time period and according






23. Testing to determine the security of the software product. See also functionality testing. The process of testing to determine the functionality of a software product.






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






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. A collection of components organized to accomplish a specific function or set of functions. [IEEE 610]






27. A five level staged framework that describes the key elements of an effective software process. The Capability Maturity Model covers best-practices for planning - engineering and managing software development and maintenance. [CMM] See also Capabilit






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






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






30. A sequence of transactions in a dialogue between a user and the system with a tangible result.






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






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






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






34. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 transitions. [Chow] See also state transition testing. A black box test design technique in which test cases are designed to execute valid and i






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






36. An incremental approach to integration testing where the component at the top of the component hierarchy is tested first - with lower level components being simulated by stubs. Tested components are then used to test lower level components. The proce






37. The set from which valid output values can be selected. See also domain. The set from which valid input and/or output values can be selected.






38. Testing the changes to an operational system or the impact of a changed environment to an operational system.






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






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






41. Testing based on an analysis of the specification of the functionality of a component or system. See also black box testing. Testing - either functional or non-functional - without reference to the internal structure of the component or system. Black






42. A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [After IEEE 829]






43. The period of time in a software development life cycle during which the components of a software product are executed - and the software product is evaluated to determine whether or not requirements have been satisfied. [IEEE 610]






44. A series which appears to be random but is in fact generated according to some prearranged sequence.






45. A skilled professional who is involved in the testing of a component or system.






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






47. Operational testing in the acceptance test phase - typically performed in a simulated real-life operational environment by operator and/or administrator focusing on operational aspects - e.g. recoverability - resource-behavior - installability and te






48. A device - computer program - or system that accepts the same inputs and produces the same outputs as a given system. [IEEE 610] See also simulator. A device - computer program or system used during testing - which behaves or operates like a given sy






49. Procedure to derive and/or select test cases based on an analysis of the specification - either functional or non-functional - of a component or system without reference to its internal structure.






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