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






2. A document that specifies - ideally in a complete - precise and verifiable manner - the requirements - design - behavior - or other characteristics of a component or system - and - often - the procedures for determining whether these provisions have






3. A factor that could result in future negative consequences; usually expressed as impact and likelihood.






4. An element of configuration management - consisting of the evaluation - co-ordination - approval or disapproval - and implementation of changes to configuration items after formal establishment of their configuration identification. [IEEE 610]






5. The capability of the software product to be used in place of another specified software product for the same purpose in the same environment. [ISO 9126] See also portability. The ease with which the software product can be transferred from one hardw






6. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified to make future maintenance easier - or adapted to a changed environment. [ISO 9126]






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






8. A portion of an input or output domain for which the behavior of a component or system is assumed to be the same - based on the specification.






9. A framework that describes the key elements of an effective product development and maintenance process. The Capability Maturity Model Integration covers best-practices for planning - engineering and managing product development and maintenance. CMMI






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






11. An uninterrupted period of time spent in executing tests. In exploratory testing - each test session is focused on a charter - but testers can also explore new opportunities or issues during a session. The tester creates and executes test cases on th






12. A path for which a set of input values and preconditions exists which causes it to be executed.






13. The period of time in the software life cycle during which the requirements for a software product are defined and documented. [IEEE 610]






14. The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate. [After IEEE 610] See also efficiency. The capability of the software product to provide appropriat






15. A reason or purpose for designing and executing a test.






16. A variable (whether stored within a component or outside) that is written by a component.






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






18. The percentage of combinations of all single condition outcomes within one statement that have been exercised by a test suite. 100% multiple condition coverage implies 100% condition determination coverage.






19. A high level metric of effectiveness and/or efficiency used to guide and control progressive development - e.g. lead-time slip for software development. [CMMI]






20. A tool for seeding (i.e. intentionally inserting) faults in a component or system.






21. A test tool to perform automated test comparison of actual results with expected results.






22. A software tool used to carry out instrumentation.






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






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






25. Testing to determine how the occurrence of two or more activities within the same interval of time - achieved either by interleaving the activities or by simultaneous execution - is handled by the component or system. [After IEEE 610]






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






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






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






29. The first executable statement within a component.






30. A tool that supports operational security.






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






32. An independent evaluation of software products or processes to ascertain compliance to standards - guidelines - specifications - and/or procedures based on objective criteria - including documents that specify: (1) the form or content of the products






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






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






35. An entity in a programming language - which is typically the smallest indivisible unit of execution.






36. Testing of a component or system at specification or implementation level without execution of that software - e.g. reviews or static code analysis.






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






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






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






40. A test whereby real-life users are involved to evaluate the usability of a component or system.






41. A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item - control changes to those characteristics - record and report change processi






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






43. An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge - for example the minimum or maximum value of a range.






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






45. A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available - e.g. case - jump - go to - if-then-else.






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






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






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






49. Definition of user profiles in performance - load and/or stress testing. Profiles should reflect anticipated or actual usage based on an operational profile of a component or system - and hence the expected workload. See also load profile - operation






50. The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms - e.g. lines-of-code - number of classes or function points).