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 percentage of sequences of N+1 transitions that have been exercised by a test suite. [Chow]






2. The assessment of change to the layers of development documentation - test documentation and components - in order to implement a given change to specified requirements.






3. A formula based test estimation method based on function point analysis. [TMap]






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






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






6. The result of a decision (which therefore determines the branches to be taken).






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






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






9. The process of transforming general testing objectives into tangible test conditions and test cases.






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






11. Acceptance testing by users/customers at their site - to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes - normally including hardware as well as software.






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






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






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






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






16. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange - Internet).






17. A test tool to perform automated test comparison of actual results with expected results.






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






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. The process of developing and prioritizing test procedures - creating test data and - optionally - preparing test harnesses and writing automated test scripts.






21. A sequence of transactions in a dialogue between a user and the system with a tangible result.






22. A computational model consisting of a finite number of states and transitions between those states - possibly with accompanying actions. [IEEE 610]






23. The number of defects found by a test phase - divided by the number found by that test phase and any other means afterwards.






24. An entity in a programming language - which is typically the smallest indivisible unit of execution.






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






26. Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers - to determine whether or not a component or system satisfies the user/customer needs and fits within the business process






27. A document specifying a set of test cases (objective - inputs - test actions - expected results - and execution preconditions) for a test item. [After IEEE 829]






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






29. A tool that provides support to the test management and control part of a test process. It often has several capabilities - such as testware management - scheduling of tests - the logging of results - progress tracking - incident management and test






30. The percentage of combinations of all single condition outcomes within one statement that have been exercised by a test suite. 100% multiple condition coverage implies 100% condition determination coverage.






31. Testing the methods and processes used to access and manage the data(base) - to ensure access methods - processes and data rules function as expected and that during access to the database - data is not corrupted or unexpectedly deleted - updated or






32. Testing the quality of the documentation - e.g. user guide or installation guide.






33. The representation of selected behavioral characteristics of one physical or abstract system by another system. [ISO 2382/1]






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






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






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. A minimal software item that can be tested in isolation.






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






39. Testing where the system is subjected to large volumes of data. See also resource-utilization testing. The process of testing to determine the resource-utilization of a software product.






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






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






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






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






44. A distinct set of test activities collected into a manageable phase of a project - e.g. the execution activities of a test level. [After Gerrard]






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






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






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






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






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






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