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 tool that provides support to the review process. Typical features include review planning and tracking support - communication support - collaborative reviews and a repository for collecting and reporting of metrics.






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






3. A software tool used to carry out instrumentation.






4. The use of software to perform or support test activities - e.g. test management - test design - test execution and results checking.






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






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






7. The degree to which a component - system or process meets specified requirements and/or user/customer needs and expectations. [After IEEE 610]






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






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






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






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






12. A pointer that references a location that is out of scope for that pointer or that does not exist. See also pointer. A data item that specifies the location of another data item; for example - a data item that specifies the address of the next employ






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






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






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






16. Acronym for Computer Aided Software Engineering.






17. A document that consists of a test design specification - test case specification and/or test procedure specification.






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






19. A transition between two states of a component or system.






20. A human action that produces an incorrect result. [After IEEE 610]






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






22. The capability of the software product to provide functions which meet stated and implied needs when the software is used under specified conditions. [ISO 9126]






23. A type of peer review that relies on visual examination of documents to detect defects - e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a docu






24. Computer programs - procedures - and possibly associated documentation and data pertaining to the operation of a computer system. [IEEE 610]






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






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






27. The capability of the software product to achieve acceptable levels of risk of harm to people - business - software - property or the environment in a specified context of use. [ISO 9126]






28. A scale that constrains the type of data analysis that can be performed on it. [ISO 14598]






29. An approach to testing in which test cases are designed based on the architecture and/or detailed design of a component or system (e.g. tests of interfaces between components or systems).






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






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






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






33. Testing of a component or system at specification or implementation level without execution of that software - e.g. reviews or static code analysis.






34. The capability of the software product to be diagnosed for deficiencies or causes of failures in the software - or for the parts to be modified to be identified. [ISO 9126] See also maintainability. The ease with which a software product can be modif






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






36. Definition of user profiles in performance - load and/or stress testing. Profiles should reflect anticipated or actual usage based on an operational profile of a component or system - and hence the expected workload. See also load profile - operation






37. Testing based on an analysis of the internal structure of the component or system.






38. A continuous framework for test process improvement that describes the key elements of an effective test process - especially targeted at system testing and acceptance testing.






39. The evaluation of a condition to True or False.






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






41. The set from which valid input values can be selected. See also domain. The set from which valid input and/or output values can be selected.






42. Execution of the test process against a single identifiable release of the test object.






43. A questionnaire based usability test technique to evaluate the usability - e.g. user-satisfaction - of a component or system. [Veenendaal]






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






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






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






47. The capability of the software product to interact with one or more specified components or systems. [After ISO 9126] See also functionality. The capability of the software product to provide functions which meet stated and implied needs when the sof






48. A type of integration testing in which software elements - hardware elements - or both are combined all at once into a component or an overall system - rather than in stages. [After IEEE 610] See also integration testing. Testing performed to expose






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






50. The representation of a distinct set of tasks performed by the component or system - possibly based on user behavior when interacting with the component or system - and their probabilities of occurance. A task is logical rather that physical and can