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 to determine the ease by which users with disabilities can use a component or system. [Gerrard]






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






3. The capability of the software product to avoid unexpected effects from modifications in the software. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements






4. The set of generic and specific conditions - agreed upon with the stakeholders - for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding p






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






6. The implementation of the test strategy for a specific project. It typically includes the decisions made that follow based on the (test) project's goal and the risk assessment carried out - starting points regarding the test process - the test design






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






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






9. The percentage of sequences of N+1 transitions that have been exercised by a test suite. [Chow]






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. A black box test design technique in which test cases are designed to execute business procedures and processes. [TMap] See also procedure testing. Testing aimed at ensuring that the component or system can operate in conjunction with new or existing






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






13. Deviation of the component or system from its expected delivery - service or result. [After Fenton]






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






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






16. The process of testing to determine the interoperability of a software product.






17. A type of test tool that is able to execute other software using an automated test script - e.g. capture/playback. [Fewster and Graham]






18. The testing activities that must be repeated when testing is re-started after a suspension. [After IEEE 829]






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






20. A form of static analysis based on the definition and usage of variables.






21. Testing of software or specification by manual simulation of its execution. See also static analysis. Analysis of software artifacts - e.g. requirements or code - carried out without execution of these software artifacts.






22. [Beizer] 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.






23. An attribute of a component or system specified or implied by requirements documentation (for example reliability - usability or design constraints). [After IEEE 1008]






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






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






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






27. Testing that involves the execution of the software of a component or system.






28. A test case with concrete (implementation level) values for input data and expected results. Logical operators from high level test cases are replaced by actual values that correspond to the objectives of the logical operators. See also high level te






29. A sequence of one or more consecutive executable statements containing no branches. Note: A node in a control flow graph represents a basic block.






30. The number of independent paths through a program. Cyclomatic complexity is defined as: L - N + 2P - where - L = the number of edges/links in a graph - N = the number of nodes in a graph - P = the number of disconnected parts of the graph (e.g. a cal






31. The person who records each defect mentioned and any suggestions for process improvement during a review meeting - on a logging form. The scribe has to ensure that the logging form is readable and understandable.






32. The process of demonstrating the ability to fulfill specified requirements. Note the term 'qualified' is used to designate the corresponding status. [ISO 9000]






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






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






35. A flaw in a component or system that can cause the component or system to fail to perform its required function - e.g. an incorrect statement or data definition. A defect - if encountered during execution - may cause a failure of the component or sys






36. Testing to determine the scalability of the software product.






37. A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test - integration test - system test and acceptance test. [After TMap]






38. A software tool or hardware device that runs concurrently with the component or system under test and supervises - records and/or analyses the behavior of the component or system. [After IEEE 610]






39. A test result which fails to identify the presence of a defect that is actually present in the test object.






40. The percentage of paths that have been exercised by a test suite. 100% path coverage implies 100% LCSAJ coverage.






41. The composition of a component or system as defined by the number - nature - and interconnections of its constituent parts.






42. Tests aimed at showing that a component or system does not work. Negative testing is related to the testers' attitude rather than a specific test approach or test design technique - e.g. testing with invalid input values or exceptions. [After Beizer]






43. An entity or property used as a basis for test coverage - e.g. equivalence partitions or code statements.






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






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






46. The process of testing to determine the interoperability of a software product. See also functionality testing. The process of testing to determine the functionality of a software product.






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






48. A tool that carries out static analysis.






49. A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system.






50. An approach to testing to reduce the level of product risks and inform stakeholders on their status - starting in the initial stages of a project. It involves the identification of product risks and their use in guiding the test process.