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 black box test design technique where test cases are selected - possibly using a pseudo-random generation algorithm - to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performa






2. A reason or purpose for designing and executing a test.






3. A high-level description of the test levels to be performed and the testing within those levels for an organization or programme (one or more projects).






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






5. A chronological record of relevant details about the execution of tests. [IEEE 829]






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






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






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. The testing of individual software components. [After IEEE 610]






10. The capability of the software product to co-exist with other independent software in a common environment sharing common resources. [ISO 9126] See also portability. The ease with which the software product can be transferred from one hardware or sof






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






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






13. A device or storage area used to store data temporarily for differences in rates of data flow - time or occurrence of events - or amounts of data that can be handeld by the devices or processes involved in the transfer or use of the data. [IEEE 610]






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






15. A black box test design technique in which test cases are designed to execute valid and invalid state transitions. See also N-switch testing. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 tr






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






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






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






19. The ability of the software product to perform its required functions under stated conditions for a specified period of time - or for a specified number of operations. [ISO 9126]






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






22. Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.






23. A source to determine expected results to compare with the actual result of the software under test. An oracle may be the existing system (for a benchmark) - a user-manual - or an individual's specialized knowledge - but should not be the code. [Afte






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






25. A test case without concrete (implementation level) values for input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available. See also low level test case. A test case with concrete (






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






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






28. A test is deemed to pass if its actual result matches its expected result.






29. Testing to determine how the occurrence of two or more activities within the same interval of time - achieved either by interleaving the activities or by simultaneous execution - is handled by the component or system. [After IEEE 610]






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






31. A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation - correction and re-testing of defects and provide reporting facilities.






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






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






34. A white box test design technique in which test cases are designed to execute condition outcomes and decision outcomes.






35. The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality testing. Testing based on an analysis of the specification of the functionality of a compo






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






37. A subset of all defined/planned test cases that cover the main functionality of a component or system - to ascertaining that the most crucial functions of a program work - but not bothering with finer details. A daily build and smoke test is among in






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






39. Modification of a software product after delivery to correct defects - to improve performance or other attributes - or to adapt the product to a modified environment. [IEEE 1219]






40. Testing carried out informally; no formal test preparation takes place - no recognized test design technique is used - there are no expectations for results and arbitrariness guides the test execution activity.






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






42. A technique used to characterize the elements of risk. The result of a hazard analysis will drive the methods used for development and testing of a system. See also risk analysis. The process of assessing identified risks to estimate their impact and






43. The process of assigning a number or category to an entity to describe an attribute of that entity. [ISO 14598]






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






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






46. Testing that runs test cases that failed the last time they were run - in order to verify the success of corrective actions.






47. A meeting at the end of a project during which the project team members evaluate the project and learn lessons that can be applied to the next project.






48. Testing to determine the extent to which the software product is understood - easy to learn - easy to operate and attractive to the users under specified conditions. [After ISO 9126]






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






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