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






2. Two persons - e.g. two testers - a developer and a tester - or an end-user and a tester - working together to find defects. Typically - they share one computer and trade control of it while testing.






3. A document that specifies - ideally in a complete - precise and verifiable manner - the requirements - design - behavior - or other characteristics of a component or system - and - often - the procedures for determining whether these provisions have






4. The representation of selected behavioral characteristics of one physical or abstract system by another system. [ISO 2382/1]






5. The tracing of requirements through the layers of development documentation to components.






6. The first executable statement within a component.






7. The process of combining components or systems into larger assemblies.






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






9. A device or storage area used to store data temporarily for differences in rates of data flow - time or occurrence of events - or amounts of data that can be handeld by the devices or processes involved in the transfer or use of the data. [IEEE 610]






10. A program of activities designed to improve the performance and maturity of the organization's processes - and the result of such a program. [CMMI]






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






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






13. A software tool that translates programs expressed in a high order language into their machine language equivalents. [IEEE 610]






14. A set of one or more test cases. [IEEE 829]






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






16. A meeting at the end of a project during which the project team members evaluate the project and learn lessons that can be applied to the next project.






17. The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The software life cycle typically includes a concept phase - requirements phase - design phase - implementation phase - tes






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






19. Two or more single conditions joined by means of a logical operator (AND - OR or XOR) - e.g. 'A>B AND C>1000'.






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






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






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






23. A test management task that deals with the activities related to periodically checking the status of a test project. Reports are prepared that compare the actuals to that which was planned. See also test management. The planning - estimating - monito






24. A tool used to check that no brtoken hyperlinks are present on a web site.






25. The use of software - e.g. capture/playback tools - to control the execution of tests - the comparison of actual results to expected results - the setting up of test preconditions - and other test control and reporting functions.






26. A systematic approach to risk identification and analysis of identifying possible modes of failure and attempting to prevent their occurrence. See also Failure Mode - Effect and Criticality Analysis (FMECA).






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






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






29. A test basis document that can only be amended by a formal change control process. See also baseline. A specification or software product that has been formally reviewed or agreed upon - that thereafter serves as the basis for further development - a






30. An input for which the specification predicts a result.






31. Method aiming to measure the size of the functionality of an information system. The measurement is independent of the technology. This measurement may be used as a basis for the measurement of productivity - the estimation of the needed resources -






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






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






34. The process of developing and prioritizing test procedures - creating test data and - optionally - preparing test harnesses and writing automated test scripts.






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






36. Acronym for Commercial Off-The-Shelf software. See off-the-shelf software. A software product that is developed for the general market - i.e. for a large number of customers - and that is delivered to many customers in identical format.






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






38. The process of testing an integrated system to verify that it meets specified requirements. [Hetzel]






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






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






41. A tool that carries out static code analysis. The tool checks source code - for certain properties such as conformance to coding standards - quality metrics or data flow anomalies.






42. A framework that describes the key elements of an effective product development and maintenance process. The Capability Maturity Model Integration covers best-practices for planning - engineering and managing product development and maintenance. CMMI






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






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






45. A tool used by programmers to reproduce failures - investigate the state of programs and find the corresponding defect. Debuggers enable programmers to execute programs step by step - to halt a program at any program statement and to set and examine






46. Separation of responsibilities - which encourages the accomplishment of objective testing. [After DO-178b]






47. A review not based on a formal (documented) procedure.






48. Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure.






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






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