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. All documents from which the requirements of a component or system can be inferred. The documentation on which the test cases are based. If a document can be amended only by way of formal amendment procedure - then the test basis is called a frozen t






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






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






4. The insertion of additional code into the program in order to collect information about program behavior during execution - e.g. for measuring code coverage.






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






6. An incremental approach to integration testing where the lowest level components are tested first - and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested






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






8. The process of recognizing - investigating - taking action and disposing of incidents. It involves logging incidents - classifying them and identifying the impact. [After IEEE 1044]






9. The capability of the software product to be installed in a specified environment [ISO 9126]. See also portability. The ease with which the software product can be transferred from one hardware or software environment to another. [ISO 9126]






10. A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. [Gilb and Graham - IEEE 1028] See also peer review. A review of a software work product by colleagues of the producer of the product for the p






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






12. The period of time in a software development life cycle during which the components of a software product are executed - and the software product is evaluated to determine whether or not requirements have been satisfied. [IEEE 610]






13. A set of exit criteria.






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






15. A tool that provides objective measures of what structural elements - e.g. statements - branches have been exercised by a test suite.






16. The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions. [IEEE 610] See also error-tolerance - fault-tolerance. The ability of a system or component to continue normal o






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






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






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






20. A path by which the original input to a process (e.g. data) can be traced back through the process - taking the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out. [After TMap]






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






22. Testing practice for a project using agile methodologies - such as extreme programming (XP) - treating development as the customer of testing and emphasizing the test first design paradigm. See also test driven development. A way of developing softwa






23. A document summarizing testing activities and results - produced at regular intervals - to report progress of testing activities against a baseline (such as the original test plan) and to communicate risks and alternatives requiring a decision to man






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






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






26. A list of activities - tasks or events of the test process - identifying their intended start and finish dates and/or times - and interdependencies.






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






28. The exit criteria that a component or system must satisfy in order to be accepted by a user - customer - or other authorized entity. [IEEE 610]






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






30. A path for which a set of input values and preconditions exists which causes it to be executed.






31. The calculated approximation of a result (e.g. effort spent - completion date - costs involved - number of test cases - etc.) which is usable even if input data may be incomplete - uncertain - or noisy.






32. A test plan that typically addresses one test level. 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






33. A group of test activities aimed at testing a component or system focused on a specific test objective - i.e. functional test - usability test - regression test etc. A test type may take place on one or more test levels or test phases. [After TMap]






34. An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests. [After Bach]






35. A five level staged framework for test process improvement - related to the Capability Maturity Model (CMM) - that describes the key elements of an effective test process.






36. An aggregation of hardware - software or both - that is designated for configuration management and treated as a single entity in the configuration management process. [IEEE 610]






37. A specification or software product that has been formally reviewed or agreed upon - that thereafter serves as the basis for further development - and that can be changed only through a formal change control process. [After IEEE 610]






38. Behavior of a component or system in response to erroneous input - from either a human user or from another component or system - or to an internal failure.






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






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






41. A human action that produces an incorrect result. [After IEEE 610]






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






43. A sequence of one or more consecutive executable statements containing no branches. Note: A node in a control flow graph represents a basic block.






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






45. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [After IEEE 829]






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






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






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






49. The process through which decisions are reached and protective measures are implemented for reducing risks to - or maintaining risks within - specified levels.






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