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






2. A tool that carries out static analysis.






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






4. Coordinated activities to direct and control an organization with regard to quality. Direction and control with regard to quality generally includes the establishment of the quality policy and quality objectives - quality planning - quality control -






5. An incremental approach to integration testing where the lowest level components are tested first - and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested






6. Testing based on an analysis of the internal structure of the component or system.






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






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






9. A set of one or more test cases. [IEEE 829]






10. A software tool used to carry out instrumentation.






11. The response of a component or system to a set of input values and preconditions.






12. The percentage of all condition outcomes and decision outcomes that have been exercised by a test suite. 100% decision condition coverage implies both 100% condition coverage and 100% decision coverage.






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






14. A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function. [After IEEE 829]






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






16. The process of developing and prioritizing test procedures - creating test data and - optionally - preparing test harnesses and writing automated test scripts.






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






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






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






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






21. A feature or characteristic that affects an item's quality. [IEEE 610]






22. A pointer within a web page that leads to other web pages.






23. A special instance of a smoke test to decide if the component or system is ready for detailed and further testing. An intake test is typically carried out at the start of the test execution phase. See also smoke test. A subset of all defined/planned






24. Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software - as a result of the changes made. It is performed when the software or its environment is c






25. A specification or software product that has been formally reviewed or agreed upon - that thereafter serves as the basis for further development - and that can be changed only through a formal change control process. [After IEEE 610]






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






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






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






29. A tool that supports the recording of requirements - requirements attributes (e.g. priority - knowledge responsible) and annotation - and facilitates traceability through layers of requirements and requirements change management. Some requirements ma






30. A scale that constrains the type of data analysis that can be performed on it. [ISO 14598]






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






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






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






34. A list of activities - tasks or events of the test process - identifying their intended start and finish dates and/or times - and interdependencies.






35. Testing by means of a random selection from a large range of inputs and by randomly pushing buttons - ignorant on how the product is being used.






36. A way of developing software where the test cases are developed - and often automated - before the software is developed to run those test cases.






37. An integration test type that is concerned with testing the interfaces between components or systems.






38. The use of software to perform or support test activities - e.g. test management - test design - test execution and results checking.






39. Execution of a test on a specific version of the test object.






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






41. A human action that produces an incorrect result. [After IEEE 610]






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






43. A project is a unique set of coordinated and controlled activities with start and finish dates undertaken to achieve an objective conforming to specific requirements - including the constraints of time - cost and resources. [ISO 9000]






44. A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actuals to that which was planned. See also test management. The planning - estimating - monito






45. Testing where components or systems are integrated and tested one or some at a time - until all the components or systems are integrated and tested.






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






47. The behavior predicted by the specification - or another source - of the component or system under specified conditions.






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






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






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