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. Testing of software used to convert data from existing systems for use in replacement systems.






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






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






4. (1) The capability of an organization with respect to the effectiveness and efficiency of its processes and work practices. See also Capability Maturity Model - Test Maturity Model. (2) The capability of the software product to avoid failure as a res






5. A test whereby real-life users are involved to evaluate the usability of a component or system.






6. An item or event of a component or system that could be verified by one or more test cases - e.g. a function - transaction - feature - quality attribute - or structural element.






7. An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed - e.g. statement coverage - decision coverage or condition coverage.






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






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






10. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing - system integration testing. Testing performed to expose defects in the interfaces and int






11. The degree of uniformity - standardization - and freedom from contradiction among the documents or parts of a component or system. [IEEE 610]






12. Acronym for Computer Aided Software Engineering.






13. A five level staged framework for test process improvement - related to the Capability Maturity Model Integration (CMMI) - that describes the key elements of an effective test process.






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






15. The leader and main person responsible for an inspection or other review process.






16. A grid showing the resulting transitions for each state combined with each possible event - showing both valid and invalid transitions.






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






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






19. An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members.






20. An attribute of a test indicating whether the same results are produced each time the test is executed.






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






22. Comparison of actual and expected results - performed after the software has finished running.






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






24. A white box test design technique in which test cases are designed to execute paths.






25. A test is deemed to fail if its actual result does not match its expected result.






26. The capability of the software product to enable the user to understand whether the software is suitable - and how it can be used for particular tasks and conditions of use. [ISO 9126] See also usability. The capability of the software to be understo






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






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






29. A test case that cannot be executed because the preconditions for its execution are not fulfilled.






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






31. Statistical testing using a model of system operations (short duration tasks) and their probability of typical use. [Musa]






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






33. A skilled professional who is involved in the testing of a component or system.






34. A review characterized by documented procedures and requirements - e.g. inspection.






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






36. Formal testing with respect to user needs - requirements - and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user - customers or other authorized entity to determine whether or n






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






38. Procedure to derive and/or select test cases based on the tester's experience - knowledge and intuition.






39. A review not based on a formal (documented) procedure.






40. The percentage of boundary values that have been exercised by a test suite.






41. Software developed specifically for a set of users or customers. The opposite is off-the-shelf software.






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






43. Formal or informal testing conducted during the implementation of a component or system - usually in the development environment by developers. [After IEEE 610]






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






45. A group of test activities aimed at testing a component or system focused on a specific test objective - i.e. functional test - usability test - regression test etc. A test type may take place on one or more test levels or test phases. [After TMap]






46. A data item that specifies the location of another data item; for example - a data item that specifies the address of the next employee record to be processed. [IEEE 610]






47. A device - computer program - or system that accepts the same inputs and produces the same outputs as a given system. [IEEE 610] See also simulator. A device - computer program or system used during testing - which behaves or operates like a given sy






48. A variable (whether stored within a component or outside) that is read by a component.






49. The process of testing to determine the recoverability of a software product.






50. A diagram that depicts the states that a component or system can assume - and shows the events or circumstances that cause and/or result from a change from one state to another. [IEEE 610]