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






2. An attribute of a component or system specified or implied by requirements documentation (for example reliability - usability or design constraints). [After IEEE 1008]






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






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






5. A test approach in which the test suite comprises all combinations of input values and preconditions.






6. The tracing of requirements for a test level through the layers of test documentation (e.g. test plan - test design specification - test case specification and test procedure specification or test script).






7. The capability of the software product to enable specified modifications to be implemented. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified






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






9. A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support automated regression testing.






10. The calculated approximation of a result (e.g. effort spent - completion date - costs involved - number of test cases - etc.) which is usable even if input data may be incomplete - uncertain - or noisy.






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






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






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






14. The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The software life cycle typically includes a concept phase - requirements phase - design phase - implementation phase - tes






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






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






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






18. The process of intentionally adding known defects to those already in the component or system for the purpose of monitoring the rate of detection and removal - and estimating the number of remaining defects. [IEEE 610]






19. Testing the quality of the documentation - e.g. user guide or installation guide.






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






21. A technique used to analyze the causes of faults (defects). The technique visually models how logical relationships between failures - human errors - and external events can combine to cause specific faults to disclose.






22. The percentage of equivalence partitions that have been exercised by a test suite.






23. Behavior of a component or system in response to erroneous input - from either a human user or from another component or system - or to an internal failure.






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






25. A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content. [Freedman and Weinberg - IEEE 1028] See also peer review. A review of a software work product by colleagues






26. The process of confirming that a component - system or person complies with its specified requirements - e.g. by passing an exam.






27. The process through which decisions are reached and protective measures are implemented for reducing risks to - or maintaining risks within - specified levels.






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






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






30. Supplied instructions on any suitable media - which guides the installer through the installation process. This may be a manual guide - step-by-step procedure - installation wizard - or any other similar process description.






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






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






33. Testing conducted to evaluate a component or system in its operational environment. [IEEE 610]






34. A systematic way of testing all-pair combinations of variables using orthogonal arrays. It significantly reduces the number of all combinations of variables to test all pair combinations. See also pairwise testing. A black box test design technique i






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






36. Test execution carried out by following a previously documented sequence of tests.






37. The capability of the software product to avoid unexpected effects from modifications in the software. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements






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






39. Testing to determine the robustness of the software product.






40. An element of configuration management - consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification - the status of proposed






41. A set of interrelated activities - which transform inputs into outputs. [ISO 12207]






42. Commonly used to refer to a test procedure specification - especially an automated one.






43. The function to check on the contents of libraries of configuration items - e.g. for standards compliance. [IEEE 610]






44. A 2-dimensional array constructed with special mathematical properties - such that choosing any two columns in the array provides every pair combination of each number in the array.






45. Analysis of software artifacts - e.g. requirements or code - carried out without execution of these software artifacts.






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






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






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






49. The individual element to be tested. There usually is one test object and many test items. See also test object. A reason or purpose for designing and executing a test.






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