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. The capability of the software product to re-establish a specified level of performance and recover the data directly affected in case of failure. [ISO 9126] See also reliability. The ability of the software product to perform its required functions






2. A path for which a set of input values and preconditions exists which causes it to be executed.






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






4. The process of testing to determine the maintainability of a software product.






5. A tool to support performance testing and that usually has two main facilities: load generation and test transaction measurement. Load generation can simulate either multiple users or high volumes of input data. During execution - response time measu






6. A set of test cases derived from the internal structure of a component or specification to ensure that 100% of a specified coverage criterion will be achieved.






7. Directed and focused attempt to evaluate the quality - especially reliability - of a test object by attempting to force specific failures to occur.






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






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






10. A program element is said to be exercised by a test case when the input value causes the execution of that element - such as a statement - decision - or other structural element.






11. Computer instructions and data definitions expressed in a programming language or in a form output by an assembler - compiler or other translator. [IEEE 610]






12. Systematic application of procedures and practices to the tasks of identifying - analyzing - prioritizing - and controlling risk.






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






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






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






16. A path that cannot be exercised by any set of possible input values.






17. A tool that carries out static analysis.






18. Testing performed to expose defects in the interfaces and interaction between integrated components.






19. A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test - integration test - system test and acceptance test. [After TMap]






20. A development activity where a complete system is compiled and linked every day (usually overnight) - so that a consistent system is available at any time including all latest changes.






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






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






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






24. A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system.






25. The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface. [ISO 9126] See also reliability - robustness. The ability of the software product






26. The fundamental test process comprises test planning and control - test analysis and design - test implementation and execution - evaluating exit criteria and reporting - and test closure activities.






27. Separation of responsibilities - which encourages the accomplishment of objective testing. [After DO-178b]






28. A risk directly related to the test object. See also risk. A factor that could result in future negative consequences; usually expressed as impact and likelihood.






29. A tool that facilitates the recording and status tracking of incidents. They often have workflow-oriented facilities to track and control the allocation - correction and re-testing of incidents and provide reporting facilities. See also defect manage






30. The process of combining components or systems into larger assemblies.






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






32. The capability of the software product to use appropriate amounts and types of resources - for example the amounts of main and secondary memory used by the program and the sizes of required temporary or overflow files - when the software performs its






33. A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects) - which can be used to design test cases.






34. Data that exists (for example - in a database) before a test is executed - and that affects or is affected by the component or system under test.






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






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






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






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






39. An executable statement where a variable is assigned a value.






40. The exit criteria that a component or system must satisfy in order to be accepted by a user - customer - or other authorized entity. [IEEE 610]






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






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






43. An element of storage in a computer that is accessible by a software program by referring to it by a name.






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






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






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






47. The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions. [IEEE 610] See also error-tolerance - fault-tolerance. The ability of a system or component to continue normal o






48. Testing to determine the security of the software product. See also functionality testing. The process of testing to determine the functionality of a software product.






49. Operational testing in the acceptance test phase - typically performed in a simulated real-life operational environment by operator and/or administrator focusing on operational aspects - e.g. recoverability - resource-behavior - installability and te






50. The degree of impact that a defect has on the development or operation of a component or system. [After IEEE 610]