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. Any (work) product that must be delivered to someone other than the (work) product's author.






2. A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified work loads - or with reduced availability of resources such as access to memory or servers. [After IEEE 610] See also pe






3. A statement which - when compiled - is translated into object code - and which will be executed procedurally when the program is running and may perform an action on data.






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






5. Testing using input values that should be rejected by the component or system. See also error tolerance. The ability of a system or component to continue normal operation despite the presence of erroneous inputs. [After IEEE 610].






6. A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items - and for ensuring implementation of approved changes. [IEEE 610]






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






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






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. A white box test design technique in which test cases are designed to execute definition and use pairs of variables.






11. A test plan that typically addresses multiple test levels. See also test plan. A document describing the scope - approach - resources and schedule of intended test activities. It identifies amongst others test items - the features to be tested - the






12. Two persons - e.g. two testers - a developer and a tester - or an end-user and a tester - working together to find defects. Typically - they share one computer and trade control of it while testing.






13. Deviation of the component or system from its expected delivery - service or result. [After Fenton]






14. A five level staged framework for test process improvement - related to the Capability Maturity Model (CMM) - that describes the key elements of an effective test process.






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






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






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






18. Simulated or actual operational testing by potential users/customers or an independent test team at the developers' site - but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal acce






19. An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests. [After Bach]






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






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






22. The number or category assigned to an attribute of an entity by making a measurement. [ISO 14598]






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






24. An integration approach that combines the components or systems for the purpose of getting a basic functionality working early. See also integration testing. Testing performed to expose defects in the interfaces and in the interactions between integr






25. A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system. [After TMap]






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






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






28. Coverage measures based on the internal structure of a component or system.






29. The process of recognizing - investigating - taking action and disposing of incidents. It involves logging incidents - classifying them and identifying the impact. [After IEEE 1044]






30. The insertion of additional code into the program in order to collect information about program behavior during execution - e.g. for measuring code coverage.






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






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






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






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






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






36. The percentage of all single condition outcomes that independently affect a decision outcome that have been exercised by a test case suite. 100% condition determination coverage implies 100% decision condition coverage.






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






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






39. A skeletal or special-purpose implementation of a software component - used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component. [After IEEE 610]






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






41. The composition of a component or system as defined by the number - nature - and interconnections of its constituent parts.






42. The process of identifying differences between the actual results produced by the component or system under test and the expected results for a test. Test comparison can be performed during test execution (dynamic comparison) or after test execution.






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






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






45. The method used to perform the actual test execution - either manual or automated.






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






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






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






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






50. Testing aimed at ensuring that the component or system can operate in conjunction with new or existing users' business procedures or operational procedures.







Sorry!:) No result found.

Can you answer 50 questions in 15 minutes?


Let me suggest you:

Browse all subjects

Browse all tests

Most popular tests



Major Subjects

Tests & Exams


AP
CLEP
DSST
GRE
SAT
GMAT

Browse all subjects

Browse all tests

Most popular tests