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






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






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






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






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






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






7. A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria. [After IEEE 829]






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






9. The degree - expressed as a percentage - to which a specified coverage item has been exercised by a test suite.






10. A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made - and to design tests specifically to expose them.






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






12. Computer instructions and data definitions expressed in a programming language or in a form output by an assembler - compiler or other translator. [IEEE 610]






13. A test plan that typically addresses one test phase. See also test plan. 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 testin






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






15. A white box test design technique in which test cases are designed to execute definition and use pairs of variables.






16. An incremental approach to integration testing where the component at the top of the component hierarchy is tested first - with lower level components being simulated by stubs. Tested components are then used to test lower level components. The proce






17. The degree to which a component - system or process meets specified requirements and/or user/customer needs and expectations. [After IEEE 610]






18. The percentage of executable statements that have been exercised by a test suite.






19. Testing based on an analysis of the internal structure of the component or system.






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






21. A tree showing equivalence parititions hierarchically ordered - which is used to design test cases in the classification tree method. See also classification tree method. A black box test design technique in which test cases - described by means of a






22. Procedure to derive and/or select test cases based on an analysis of the specification - either functional or non-functional - of a component or system without reference to its internal structure.






23. The percentage of all condition outcomes and decision outcomes that have been exercised by a test suite. 100% decision condition coverage implies both 100% condition coverage and 100% decision coverage.






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






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






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






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






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






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






30. A black box test design technique in which test cases are designed to execute combinations of inputs using the concept of condition determination coverage. [TMap]






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






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






33. A test plan that typically addresses multiple test levels. See also test plan. 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






34. The individual element to be tested. There usually is one test object and many test items. See also test object. A reason or purpose for designing and executing a test.






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






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






37. Acronym for Computer Aided Software Testing. See also test automation.The use of software to perform or support test activities - e.g. test management - test design - test execution and results checking.






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






39. The leader and main person responsible for an inspection or other review process.






40. Formal testing with respect to user needs - requirements - and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user - customers or other authorized entity to determine whether or n






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






42. A statement which - when compiled - is translated into object code - and which will be executed procedurally when the program is running and may perform an action on data.






43. An approach to testing in which test cases are designed based on descriptions and/or knowledge of business processes.






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






45. A requirement that does not relate to functionality - but to attributes such as reliability - efficiency - usability - maintainability and portability.






46. A defect in a program's dynamic store allocation logic that causes it to fail to reclaim memory after it has finished using it - eventually causing the program to fail due to lack of memory.






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






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






50. The tracing of requirements for a test level through the layers of test documentation (e.g. test plan - test design specification - test case specification and test procedure specification or test script).