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 basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available - e.g. case - jump - go to - if-then-else.






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






3. A white box test design technique in which test cases are designed to execute single condition outcomes that independently affect a decision outcome.






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






5. An attribute of a component or system specified or implied by requirements documentation (for example reliability - usability or design constraints). [After IEEE 1008]






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






7. The capability of the software product to be upgraded to accommodate increased loads. [After Gerrard]






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






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






10. The total costs incurred on quality activities and issues and often split into prevention costs - appraisal costs - internal failure costs and external failure costs.






11. An element of configuration management - consisting of the evaluation - co-ordination - approval or disapproval - and implementation of changes to configuration items after formal establishment of their configuration identification. [IEEE 610]






12. A test result which fails to identify the presence of a defect that is actually present in the test object.






13. A 2-dimensional array constructed with special mathematical properties - such that choosing any two columns in the array provides every pair combination of each number in the array.






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






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






16. Any event occurring that requires investigation. [After IEEE 1008]






17. A document specifying a set of test cases (objective - inputs - test actions - expected results - and execution preconditions) for a test item. [After IEEE 829]






18. The degree of impact that a defect has on the development or operation of a component or system. [After IEEE 610]






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






20. The behavior predicted by the specification - or another source - of the component or system under specified conditions.






21. A source to determine expected results to compare with the actual result of the software under test. An oracle may be the existing system (for a benchmark) - a user-manual - or an individual's specialized knowledge - but should not be the code. [Afte






22. The percentage of branches that have been exercised by a test suite. 100% branch coverage implies both 100% decision coverage and 100% statement coverage.






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






24. Statistical testing using a model of system operations (short duration tasks) and their probability of typical use. [Musa]






25. The function to check on the contents of libraries of configuration items - e.g. for standards compliance. [IEEE 610]






26. The process of testing the installability of a software product. See also portability testing. The process of testing to determine the portability of a software product.






27. Testing where the system is subjected to large volumes of data. See also resource-utilization testing. The process of testing to determine the resource-utilization of a software product.






28. The percentage of LCSAJs of a component that have been exercised by a test suite. 100% LCSAJ coverage implies 100% decision coverage.






29. A white box test design technique in which test cases are designed to execute paths.






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






31. Testing aimed at ensuring that the component or system can operate in conjunction with new or existing users' business procedures or operational procedures.






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






33. Operational testing in the acceptance test phase - typically performed in a simulated real-life operational environment by operator and/or administrator focusing on operational aspects - e.g. recoverability - resource-behavior - installability and te






34. A continuous framework for test process improvement that describes the key elements of an effective test process - especially targeted at system testing and acceptance testing.






35. The process of finding - analyzing and removing the causes of failures in software.






36. A sequence of executable statements within a component.






37. Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software - as a result of the changes made. It is performed when the software or its environment is c






38. A white box test design technique in which test cases are designed to execute condition outcomes.






39. A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system.






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






41. The capability of the software product to use appropriate amounts and types of resources - for example the amounts of main and secondary memory used by the program and the sizes of required temporary or overflow files - when the software performs its






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






43. Test execution carried out by following a previously documented sequence of tests.






44. An abstract representation of all possible sequences of events (paths) in the execution through a component or system.






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






46. The consequence/outcome of the execution of a test. It includes outputs to screens - changes to data - reports - and communication messages sent out. See also actual result - expected result. The behavior produced/observed when a component or system






47. The process of intentionally adding known defects to those already in the component or system for the purpose of monitoring the rate of detection and removal - and estimating the number of remaining defects. [IEEE 610]






48. A sequence of events (paths) in the execution through a component or system.






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






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







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