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






2. Definition of user profiles in performance - load and/or stress testing. Profiles should reflect anticipated or actual usage based on an operational profile of a component or system - and hence the expected workload. See also load profile - operation






3. A five level staged framework that describes the key elements of an effective software process. The Capability Maturity Model covers best-practices for planning - engineering and managing software development and maintenance. [CMM] See also Capabilit






4. A computational model consisting of a finite number of states and transitions between those states - possibly with accompanying actions. [IEEE 610]






5. The process of recognizing - investigating - taking action and disposing of defects. It involves recording defects - classifying them and identifying the impact. [After IEEE 1044]






6. An uninterrupted period of time spent in executing tests. In exploratory testing - each test session is focused on a charter - but testers can also explore new opportunities or issues during a session. The tester creates and executes test cases on th






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






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






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






10. The process of testing to determine the maintainability of a software product.






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






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






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






14. Testing the methods and processes used to access and manage the data(base) - to ensure access methods - processes and data rules function as expected and that during access to the database - data is not corrupted or unexpectedly deleted - updated or






15. A method to determine test suite thoroughness by measuring the extent to which a test suite can discriminate the program from slight variants (mutants) of the program.






16. A variable (whether stored within a component or outside) that is written by a component.






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






18. A document that consists of a test design specification - test case specification and/or test procedure specification.






19. The process of testing to determine the efficiency of a software product.






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






21. A black box test design technique in which test cases - described by means of a classification tree - are designed to execute combinations of representatives of input and/or output domains. [Grochtmann]






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






23. A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support automated regression testing.






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






25. A questionnaire based usability test technique to evaluate the usability - e.g. user-satisfaction - of a component or system. [Veenendaal]






26. A tool that carries out static analysis.






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






28. The capability of the software product to adhere to standards - conventions or regulations in laws and similar prescriptions. [ISO 9126]






29. The percentage of combinations of all single condition outcomes within one statement that have been exercised by a test suite. 100% multiple condition coverage implies 100% condition determination coverage.






30. The first executable statement within a component.






31. The percentage of paths that have been exercised by a test suite. 100% path coverage implies 100% LCSAJ coverage.






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






33. (1) The capability of an organization with respect to the effectiveness and efficiency of its processes and work practices. See also Capability Maturity Model - Test Maturity Model. (2) The capability of the software product to avoid failure as a res






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






35. The person responsible for project management of testing activities and resources - and evaluation of a test object. The individual who directs - controls - administers - plans and regulates the evaluation of a test object.






36. A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [After IEEE 829]






37. An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members.






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






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






40. An integration test type that is concerned with testing the interfaces between components or systems.






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






42. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange - Internet).






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






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






45. A distinct set of test activities collected into a manageable phase of a project - e.g. the execution activities of a test level. [After Gerrard]






46. A high level metric of effectiveness and/or efficiency used to guide and control progressive test development - e.g. Defect Detection Percentage (DDP).






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






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






49. A black box test design technique in which test cases are designed from cause-effect graphs. [BS 7925/2]






50. The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate. [After IEEE 610] See also efficiency. The capability of the software product to provide appropriat