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 period of time in a software development life cycle during which the components of a software product are executed - and the software product is evaluated to determine whether or not requirements have been satisfied. [IEEE 610]






2. A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract - standard - specification - or other formally imposed document. [After IEEE 610






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






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






5. A sequence of events - e.g. executable statements - of a component or system from an entry point to an exit point.






6. A specific category of risk related to the type of testing that can mitigate (control) that category. For example the risk of user-interactions being misunderstood can be mitigated by usability testing.






7. A software product that supports one or more test activities - such as planning and control - specification - building initial files and data - test execution and test analysis. [TMap] See also CAST. Acronym for Computer Aided Software Testing.






8. The capability of the software product to enable specified modifications to be implemented. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified






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






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






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






12. A memory access defect due to the attempt by a process to store data beyond the boundaries of a fixed length buffer - resulting in overwriting of adjacent memory areas or the raising of an overflow exception. See also buffer. A device or storage area






13. Procedure to derive and/or select test cases based on an analysis of the specification - either functional or non-functional - of a component or system without reference to its internal structure.






14. The capability of the software to be understood - learned - used and attractive to the user when used under specified conditions. [ISO 9126]






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






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






17. A tool for seeding (i.e. intentionally inserting) faults in a component or system.






18. Testing to determine the robustness of the software product.






19. A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects) - which can be used to design test cases.






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






21. A tool that provides objective measures of what structural elements - e.g. statements - branches have been exercised by a test suite.






22. Testing conducted to evaluate a component or system in its operational environment. [IEEE 610]






23. Multiple heterogeneous - distributed systems that are embedded in networks at multiple levels and in multiple domains interconnected addressing large-scale inter-disciplinary common problems and purposes.






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






25. A set of interrelated activities - which transform inputs into outputs. [ISO 12207]






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






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






28. The process of evaluating behavior - e.g. memory performance - CPU usage - of a system or component during execution. [After IEEE 610]






29. Analysis of software artifacts - e.g. requirements or code - carried out without execution of these software artifacts.






30. A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item - control changes to those characteristics - record and report change processi






31. A tool that supports stress testing.






32. A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.






33. The consequence/outcome of the execution of a test. It includes outputs to screens - changes to data - reports - and communication messages sent out.






34. The process of recognizing - investigating - taking action and disposing of incidents. It involves logging incidents - classifying them and identifying the impact. [After IEEE 1044]






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






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






37. A black box test design technique in which test cases are designed from cause-effect graphs. [BS 7925/2]






38. A set of several test cases for a component or system under test - where the post condition of one test is often used as the precondition for the next one.






39. The ease with which the software product can be transferred from one hardware or software environment to another. [ISO 9126]






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






41. A tool that provides support for testing security characteristics and vulnerabilities.






42. Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled. [ISO 9000]






43. The behavior produced/observed when a component or system is tested.






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






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






46. The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).






47. The number or category assigned to an attribute of an entity by making a measurement. [ISO 14598]






48. The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage. [IEEE 610]






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






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