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 combinations of inputs using the concept of condition determination coverage. [TMap]






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






3. A type of test tool that is able to execute other software using an automated test script - e.g. capture/playback. [Fewster and Graham]






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






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






6. A systematic approach to risk identification and analysis of identifying possible modes of failure and attempting to prevent their occurrence. See also Failure Mode - Effect and Criticality Analysis (FMECA).






7. An instance of an input. See also input. A variable (whether stored within a component or outside) that is read by a component.






8. The process of testing to determine the compliance of the component or system.






9. The process of finding - analyzing and removing the causes of failures in software.






10. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [After IEEE 829]






11. The assessment of change to the layers of development documentation - test documentation and components - in order to implement a given change to specified requirements.






12. An element of configuration management - consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation. [IEEE 610]






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






14. A black box test design technique in which test cases are designed to execute user scenarios.






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






16. A test environment comprised of stubs and drivers needed to execute a test.






17. Acronym for Commercial Off-The-Shelf software. See off-the-shelf software. A software product that is developed for the general market - i.e. for a large number of customers - and that is delivered to many customers in identical format.






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






19. The evaluation of a condition to True or False.






20. The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).






21. The process of transforming general testing objectives into tangible test conditions and test cases.






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






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. Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure.






25. A systematic evaluation of software acquisition - supply - development - operation - or maintenance process - performed by or on behalf of management that monitors progress - determines the status of plans and schedules - confirms requirements and th






26. The capability of the software product to be attractive to the user. [ISO 9126] See also usability. The capability of the software to be understood - learned - used and attractive to the user when used under specified conditions. [ISO 9126]






27. Formal or informal testing conducted during the implementation of a component or system - usually in the development environment by developers. [After IEEE 610]






28. An approach to testing in which test cases are designed based on descriptions and/or knowledge of business processes.






29. A black box test design technique in which test cases are designed to execute all possbile discrete combinations of each pair of input parameters. See also orthogonal array testing. A systematic way of testing all-pair combinations of variables using






30. 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. See also incid






31. The capability of the software product to provide an appropriate set of functions for specified tasks and user objectives. [ISO 9126] See also functionality. The capability of the software product to provide functions which meet stated and implied ne






32. The set from which valid input and/or output values can be selected.






33. A white box test design technique in which test cases are designed to execute single condition outcomes that independently affect a decision outcome.






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






35. A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.






36. Any event occurring that requires investigation. [After IEEE 1008]






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






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






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






40. Testing the methods and processes used to access and manage the data(base) - to ensure access methods - processes and data rules function as expected and that during access to the database - data is not corrupted or unexpectedly deleted - updated or






41. The process of testing the installability of a software product. See also portability testing. The process of testing to determine the portability of a software product.






42. A black box test design technique where test cases are selected - possibly using a pseudo-random generation algorithm - to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performa






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






44. The number of independent paths through a program. Cyclomatic complexity is defined as: L - N + 2P - where - L = the number of edges/links in a graph - N = the number of nodes in a graph - P = the number of disconnected parts of the graph (e.g. a cal






45. Testing carried out informally; no formal test preparation takes place - no recognized test design technique is used - there are no expectations for results and arbitrariness guides the test execution activity.






46. The process of testing an integrated system to verify that it meets specified requirements. [Hetzel]






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






48. The capability of the software product to enable the user to operate and control it. [ISO 9126] See also usability. The capability of the software to be understood - learned - used and attractive to the user when used under specified conditions. [ISO






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






50. The process of recording information about tests executed into a test log.