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






2. A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows a deviation from what was planned. See also test management. The planning - estimating - monitoring and co






3. A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects) - which can be used to design test cases.






4. A tool that provides an environment for unit or component testing in which a component can be tested in isolation or with suitable stubs and drivers. It also provides other support for the developer - such as debugging capabilities. [Graham]






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






6. A variable (whether stored within a component or outside) that is written by a component.






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






8. A pointer within a web page that leads to other web pages.






9. 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. See also incid






10. Any (work) product that must be delivered to someone other than the (work) product's author.






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






12. The importance of a risk as defined by its characteristics impact and likelihood. The level of risk can be used to determine the intensity of testing to be performed. A risk level can be expressed either qualitatively (e.g. high - medium - low) or qu






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






14. A systematic way of testing all-pair combinations of variables using orthogonal arrays. It significantly reduces the number of all combinations of variables to test all pair combinations. See also pairwise testing. A black box test design technique i






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






16. Testware used in automated testing - such as tool scripts.






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






18. Supplied instructions on any suitable media - which guides the installer through the installation process. This may be a manual guide - step-by-step procedure - installation wizard - or any other similar process description.






19. An element of storage in a computer that is accessible by a software program by referring to it by a name.






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






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






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






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






24. The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs. [After ISO 9126]






25. Non fulfillment of a specified requirement. [ISO 9000]






26. A white box test design technique in which test cases are designed to execute LCSAJs.






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






28. Code that cannot be reached and therefore is impossible to execute.






29. A tool that provides run-time information on the state of the software code. These tools are most commonly used to identify unassigned pointers - check pointer arithmetic and to monitor the allocation - use and de-allocation of memory and to flag mem






30. The capability of the software product to co-exist with other independent software in a common environment sharing common resources. [ISO 9126] See also portability. The ease with which the software product can be transferred from one hardware or sof






31. An element of configuration management - consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification - the status of proposed






32. A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system. [After TMap]






33. Any condition that deviates from expectation based on requirements specifications - design documents - user documents - standards - etc. or from someone's perception or experience. Anomalies may be found during - but not limited to - reviewing - test






34. A path that cannot be exercised by any set of possible input values.






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






36. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 transitions. [Chow] See also state transition testing. A black box test design technique in which test cases are designed to execute valid and i






37. The capability of the software product to be installed in a specified environment [ISO 9126]. See also portability. The ease with which the software product can be transferred from one hardware or software environment to another. [ISO 9126]






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






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






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






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






42. A minimal software item that can be tested in isolation.






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






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






45. The process of testing to determine the recoverability of a software product. See also reliability testing. The process of testing to determine the reliability of a software product.






46. A scripting technique that uses data files to contain not only test data and expected results - but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called by the control scrip






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






48. Hardware and software products installed at users' or customers' sites where the component or system under test will be used. The software may include operating systems - database management systems - and other applications.






49. Execution of a test on a specific version of the test object.






50. A list of activities - tasks or events of the test process - identifying their intended start and finish dates and/or times - and interdependencies.