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 diagram that depicts the states that a component or system can assume - and shows the events or circumstances that cause and/or result from a change from one state to another. [IEEE 610]






2. An abstract representation of the sequence and possible changes of the state of data objects - where the state of an object is any of: creation - usage - or destruction. [Beizer]






3. A point in time in a project at which defined (intermediate) deliverables and results should be ready.






4. An executable statement where a variable is assigned a value.






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






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






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






8. A tool that carries out static code analysis. The tool checks source code - for certain properties such as conformance to coding standards - quality metrics or data flow anomalies.






9. The process of transforming general testing objectives into tangible test conditions and test cases.






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






11. A tool that carries out static analysis.






12. The testing of individual software components. [After IEEE 610]






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






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






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






16. Procedure to derive and/or select test cases for nonfunctional testing based on an analysis of the specification of a component or system without reference to its internal structure. See also black box test design technique. Procedure to derive and/o






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






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






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






20. Acronym for Commercial Off-The-Shelf software. See off-the-shelf software. 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.






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






22. The percentage of equivalence partitions that have been exercised by a test suite.






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






24. Execution of the test process against a single identifiable release of the test object.






25. A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases. See also operational profile testing. Statistical testing using a model of system operations (short duration tasks)






26. An analysis method that determines which parts of the software have been executed (covered) by the test suite and which parts have not been executed - e.g. statement coverage - decision coverage or condition coverage.






27. Computer programs - procedures - and possibly associated documentation and data pertaining to the operation of a computer system. [IEEE 610]






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






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






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






31. An element of storage in a computer that is accessible by a software program by referring to it by a name.






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






33. The use of software to perform or support test activities - e.g. test management - test design - test execution and results checking.






34. The process of testing to determine the portability of a software product.






35. Acceptance testing by users/customers at their site - to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes - normally including hardware as well as software.






36. A capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within specified process areas. [CMMI]






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






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






39. Data that exists (for example - in a database) before a test is executed - and that affects or is affected by the component or system under test.






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






41. Testing the changes to an operational system or the impact of a changed environment to an operational system.






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






43. The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).






44. A test result in which a defect is reported although no such defect actually exists in the test object.






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






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






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






48. Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.






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






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







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