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. Commonly used to refer to a test procedure specification - especially an automated one.






2. Artifacts produced during the test process required to plan - design - and execute tests - such as documentation - scripts - inputs - expected results - set-up and clear-up procedures - files - databases - environment - and any additional software or






3. A device - computer program - or system that accepts the same inputs and produces the same outputs as a given system. [IEEE 610] See also simulator. A device - computer program or system used during testing - which behaves or operates like a given sy






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






5. A detailed check of the test basis to determine whether the test basis is at an adequate quality level to act as an input document for the test process. [After TMap]






6. Testing using input values that should be rejected by the component or system. See also error tolerance. The ability of a system or component to continue normal operation despite the presence of erroneous inputs. [After IEEE 610].






7. An uninterrupted period of time spent in executing tests. In exploratory testing - each test session is focused on a charter - but testers can also explore new opportunities or issues during a session. The tester creates and executes test cases on th






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






9. A tool that supports the test design activity by generating test inputs from a specification that may be held in a CASE tool repository - e.g. requirements management tool - from specified test conditions held in the tool itself - or from code.






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






11. Testing - either functional or non-functional - without reference to the internal structure of the component or system. Black-box test design technique Procedure to derive and/or select test cases based on an analysis of the specification - either fu






12. A feature or characteristic that affects an item's quality. [IEEE 610]






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






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






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






16. A version of component integration testing where the progressive integration of components follows the implementation of subsets of the requirements - as opposed to the integration of components by levels of a hierarchy.






17. Comparison of actual and expected results - performed while the software is being executed - for example by a test execution tool.






18. An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements - e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.






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






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






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






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






23. A framework to describe the software development life cycle activities from requirements specification to maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development life cycle.






24. A black box test design technique in which test cases are designed to execute valid and invalid state transitions. See also N-switch testing. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 tr






25. Measurement of achieved coverage to a specified coverage item during test execution referring to predetermined criteria to determine whether additional testing is required and if so - which test cases are needed.






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






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






28. An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review - informal review - technical review - inspection - and walkthrough. [After IEEE 1028]






29. The percentage of all single condition outcomes that independently affect a decision outcome that have been exercised by a test case suite. 100% condition determination coverage implies 100% decision condition coverage.






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






31. A black box test design technique in which test cases are designed based upon the definition of the input domain and/or output domain.






32. A skeletal or special-purpose implementation of a software component - used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component. [After IEEE 610]






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






34. An instance of an output. See also output.A variable (whether stored within a component or outside) that is written by a component.






35. Testing where components or systems are integrated and tested one or some at a time - until all the components or systems are integrated and tested.






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






37. The method used to perform the actual test execution - either manual or automated.






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






39. A series which appears to be random but is in fact generated according to some prearranged sequence.






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






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






42. A step-by-step presentation by the author of a document in order to gather information and to establish a common understanding of its content. [Freedman and Weinberg - IEEE 1028] See also peer review. A review of a software work product by colleagues






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






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






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






46. A risk directly related to the test object. See also risk. A factor that could result in future negative consequences; usually expressed as impact and likelihood.






47. A high level document describing the principles - approach and major objectives of the organization regarding testing.






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






49. The process of testing to determine the reliability of a software product.






50. A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function. [After IEEE 829]







Sorry!:) No result found.

Can you answer 50 questions in 15 minutes?


Let me suggest you:

Browse all subjects

Browse all tests

Most popular tests



Major Subjects

Tests & Exams


AP
CLEP
DSST
GRE
SAT
GMAT

Browse all subjects

Browse all tests

Most popular tests