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 integration test type that is concerned with testing the interfaces between components or systems.






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






3. Procedure to derive and/or select test cases based on an analysis of the specification of the functionality of a component or system without reference to its internal structure. See also black box test design technique. Procedure to derive and/or sel






4. (1) A standard against which measurements or comparisons can be made. (2) A test that is be used to compare components or systems to each other or to a standard as in (1). [After IEEE 610]






5. The first executable statement within a component.






6. A scheme for the execution of test procedures. The test procedures are included in the test execution schedule in their context and in the order in which they are to be executed.






7. A programming language in which executable test scripts are written - used by a test execution tool (e.g. a capture/playback tool).






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






9. A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases. See also operational profile testing. Statistical testing using a model of system operations (short duration tasks)






10. Testing of software used to convert data from existing systems for use in replacement systems.






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






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






13. A scripting technique that stores test input and expected results in a table or spreadsheet - so that a single control script can execute all of the tests in the table. Data driven testing is often used to support the application of test execution to






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






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






16. The process of recognizing - investigating - taking action and disposing of defects. It involves recording defects - classifying them and identifying the impact. [After IEEE 1044]






17. Non fulfillment of a specified requirement. [ISO 9000]






18. A procedure to derive and/or select test cases targeted at one or more defect categories - with tests being developed from what is known about the specific defect category. See also defect taxonomy. A system of (hierarchical) categories designed to b






19. The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs. [After ISO 9126]






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






21. All documents from which the requirements of a component or system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure - then the test basis is called a frozen t






22. An abstract representation of all possible sequences of events (paths) in the execution through a component or system.






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






24. The tracing of requirements through the layers of development documentation to components.






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






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






27. A static usability test technique to determine the compliance of a user interface with recognized usability principles (the so-called "heuristics").






28. A tree showing equivalence parititions hierarchically ordered - which is used to design test cases in the classification tree method. See also classification tree method. A black box test design technique in which test cases - described by means of a






29. Procedure used to derive and/or select test cases.






30. A set of exit criteria.






31. The effect on the component or system by the measurement instrument when the component or system is being measured - e.g. by a performance testing tool or monitor. For example performance may be slightly worse when performance testing tools are being






32. A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [After IEEE 829]






33. An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements - e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.






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






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






36. Recording the details of any incident that occurred - e.g. during testing.






37. A tool used to check that no brtoken hyperlinks are present on a web site.






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






39. A requirement that does not relate to functionality - but to attributes such as reliability - efficiency - usability - maintainability and portability.






40. Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled. [ISO 9000]






41. The process of evaluating behavior - e.g. memory performance - CPU usage - of a system or component during execution. [After IEEE 610]






42. Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled. [ISO 9000]






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






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






45. The capability of the software product to be installed in a specified environment [ISO 9126]. See also portability. The ease with which the software product can be transferred from one hardware or software environment to another. [ISO 9126]






46. The capability of the software product to adhere to standards - conventions or regulations in laws and similar prescriptions. [ISO 9126]






47. Testing based on an analysis of the specification of the functionality of a component or system. See also black box testing. Testing - either functional or non-functional - without reference to the internal structure of the component or system. Black






48. A tool that carries out static analysis.






49. The activity of establishing or updating a test plan.






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