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. Testing carried out informally; no formal test preparation takes place - no recognized test design technique is used - there are no expectations for results and arbitrariness guides the test execution activity.






2. The degree to which a component or system is operational and accessible when required for use. Often expressed as a percentage. [IEEE 610]






3. Recording the details of any incident that occurred - e.g. during testing.






4. A logical expression that can be evaluated as True or False - e.g. A>B. See also test condition. 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






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






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






7. An occurrence in which one defect prevents the detection of another. [After IEEE 610]






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






9. The number of defects identified in a component or system divided by the size of the component or system (expressed in standard measurement terms - e.g. lines-of-code - number of classes or function points).






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






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






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






13. Analysis of software artifacts - e.g. requirements or code - carried out without execution of these software artifacts.






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






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






16. The process of testing to determine the compliance of the component or system.






17. A statement of test objectives - and possibly test ideas about how to test. Test charters are used in exploratory testing. See also exploratory testing. An informal test design technique where the tester actively controls the design of the tests as t






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






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






20. The process of testing to determine the resource-utilization of a software product. See also efficiency testing. The process of testing to determine the efficiency of a software product.






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






22. A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation - correction and re-testing of defects and provide reporting facilities.






23. A black box test design technique where test cases are selected - possibly using a pseudo-random generation algorithm - to match an operational profile. This technique can be used for testing non-functional attributes such as reliability and performa






24. A black box test design technique in which test cases are designed to execute user scenarios.






25. An extension of FMEA - as in addition to the basic FMEA - it includes a criticality analysis - which is used to chart the probability of failure modes against the severity of their consequences. The result highlights failure modes with relatively hig






26. A test case without concrete (implementation level) values for input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available. See also low level test case. A test case with concrete (






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






28. Testware used in automated testing - such as tool scripts.






29. A set of input values - execution preconditions - expected results and execution postconditions - developed for a particular objective or test condition - such as to exercise a particular program path or to verify compliance with a specific requireme






30. Testing the attributes of a component or system that do not relate to functionality - e.g. reliability - efficiency - usability - maintainability and portability.






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






32. The process of testing to determine the recoverability of a software product. See also reliability testing. The process of testing to determine the reliability of a software product.






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






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






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






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






37. A document that specifies - ideally in a complete - precise and verifiable manner - the requirements - design - behavior - or other characteristics of a component or system - and - often - the procedures for determining whether these provisions have






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






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






40. Hardware and software products installed at users' or customers' sites where the component or system under test will be used. The software may include operating systems - database management systems - and other applications.






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






42. Testing of software used to convert data from existing systems for use in replacement systems.






43. The set from which valid input and/or output values can be selected.






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






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






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






47. A risk directly related to the test object. See also risk. A factor that could result in future negative consequences; usually expressed as impact and likelihood.






48. Measurement of achieved coverage to a specified coverage item during test execution referring to predetermined criteria to determine whether additional testing is required and if so - which test cases are needed.






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






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







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