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. An environment containing hardware - instrumentation - simulators - software tools - and other support elements needed to conduct a test. [After IEEE 610]






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






3. Commonly used to refer to a test procedure specification - especially an automated one.






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






5. A scale that constrains the type of data analysis that can be performed on it. [ISO 14598]






6. Acronym for Computer Aided Software Engineering.






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






8. An analysis technique aimed at identifying the root causes of defects. By directing corrective measures at root causes - it is hoped that the likelihood of defect recurrence will be minimized.






9. A black box test design technique in which test cases are designed based on boundary values. See also boundary value. An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either si






10. A development life cycle where a project is broken into a series of increments - each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the approp






11. A tool that supports the recording of requirements - requirements attributes (e.g. priority - knowledge responsible) and annotation - and facilitates traceability through layers of requirements and requirements change management. Some requirements ma






12. A device - computer program or system used during testing - which behaves or operates like a given system when provided with a set of controlled inputs. [After IEEE 610 - DO178b] See also emulator. A device - computer program - or system that accepts






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






14. A source of a defect such that if it is removed - the occurance of the defect type is decreased or removed. [CMMI]






15. The ability to identify related items in documentation and software - such as requirements with associated tests. See also horizontal traceability - vertical traceability. The tracing of requirements for a test level through the layers of test docume






16. A requirement that specifies a function that a component or system must perform. [IEEE 610]






17. A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases. See also operational profile testing. Statistical testing using a model of system operations (short duration tasks)






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






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






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






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






22. The process of testing to determine the performance of a software product. See also efficiency testing. The process of testing to determine the efficiency of a software product.






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






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






25. A set of test cases derived from the internal structure of a component or specification to ensure that 100% of a specified coverage criterion will be achieved.






26. A Linear Code Sequence And Jump - consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements - the end of the linear sequence - and the targe






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






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






29. A software development approach whereby lines of code (production and/or test) of a component are written by two programmers sitting at a single computer. This implicitly means ongoing real-tim code reviews are performed.






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






31. The planning - estimating - monitoring and control of test activities - typically carried out by a test manager.






32. A white box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement).






33. The fundamental test process comprises test planning and control - test analysis and design - test implementation and execution - evaluating exit criteria and reporting - and test closure activities.






34. A sequence of transactions in a dialogue between a user and the system with a tangible result.






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






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






37. A tool that supports stress testing.






38. A system of (hierarchical) categories designed to be a useful aid for reproducibly classifying defects.






39. The process of running a test on the component or system under test - producing actual result(s).






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






41. The result of a decision (which therefore determines the branches to be taken).






42. A development activity where a complete system is compiled and linked every day (usually overnight) - so that a consistent system is available at any time including all latest changes.






43. The capability of the software product to maintain a specified level of performance in cases of software faults (defects) or of infringement of its specified interface. [ISO 9126] See also reliability - robustness. The ability of the software product






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






45. Testing performed to expose defects in the interfaces and interaction between integrated components.






46. A document describing the scope - approach - resources and schedule of intended test activities. It identifies amongst others test items - the features to be tested - the testing tasks - who will do each task - degree of tester independence - the tes






47. A tool that supports operational security.






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






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






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