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. The process of identifying risks using techniques such as brainstorming - checklists and failure history.






2. The behavior produced/observed when a component or system is tested.






3. The process of testing an integrated system to verify that it meets specified requirements. [Hetzel]






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






5. An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge - for example the minimum or maximum value of a range.






6. The capability of the software product to be attractive to the user. [ISO 9126] See also usability. The capability of the software to be understood - learned - used and attractive to the user when used under specified conditions. [ISO 9126]






7. A grid showing the resulting transitions for each state combined with each possible event - showing both valid and invalid transitions.






8. Testing of software or specification by manual simulation of its execution. See also static analysis. Analysis of software artifacts - e.g. requirements or code - carried out without execution of these software artifacts.






9. Testing of a component or system at specification or implementation level without execution of that software - e.g. reviews or static code analysis.






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






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






12. An item or event of a component or system that could be verified by one or more test cases - e.g. a function - transaction - feature - quality attribute - or structural element.






13. The capability of the software to be understood - learned - used and attractive to the user when used under specified conditions. [ISO 9126]






14. Testing using input values that should be rejected by the component or system. See also error tolerance. The ability of a system or component to continue normal operation despite the presence of erroneous inputs. [After IEEE 610].






15. Attributes of software products that bear on its ability to prevent unauthorized access - whether accidental or deliberate - to programs and data. [ISO 9126] See also functionality. The capability of the software product to provide functions which me






16. A project is a unique set of coordinated and controlled activities with start and finish dates undertaken to achieve an objective conforming to specific requirements - including the constraints of time - cost and resources. [ISO 9000]






17. A scripting technique that uses data files to contain not only test data and expected results - but also keywords related to the application being tested. The keywords are interpreted by special supporting scripts that are called by the control scrip






18. Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard]






19. A set of exit criteria.






20. The capability of the software product to enable modified software to be tested. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified to make fut






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






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






23. Supplied instructions on any suitable media - which guides the installer through the installation process. This may be a manual guide - step-by-step procedure - installation wizard - or any other similar process description.






24. Artifacts produced during the test process required to plan - design - and execute tests - such as documentation - scripts - inputs - expected results - set-up and clear-up procedures - files - databases - environment - and any additional software or






25. A test tool to perform automated test comparison of actual results with expected results.






26. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 transitions. [Chow] See also state transition testing. A black box test design technique in which test cases are designed to execute valid and i






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






28. A type of peer review that relies on visual examination of documents to detect defects - e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a docu






29. A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item - control changes to those characteristics - record and report change processi






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






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






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






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






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






35. Supplied software on any suitable media - which leads the installer through the installation process. It normally runs the installation process - provides feedback on installation results - and prompts for options.






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






37. A type of test tool that enables data to be selected from existing databases or created - generated - manipulated and edited for use in testing.






38. Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure.






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






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






41. A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects) - which can be used to design test cases.






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






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






44. A factor that could result in future negative consequences; usually expressed as impact and likelihood.






45. Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled. [ISO 9000]






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






47. A review of a software work product by colleagues of the producer of the product for the purpose of identifying defects and improvements. Examples are inspection - technical review and walkthrough.






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






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






50. A tool that provides support for the identification and control of configuration items - their status over changes and versions - and the release of baselines consisting of configuration items.