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 software tool that translates programs expressed in a high order language into their machine language equivalents. [IEEE 610]






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






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






4. A formula based test estimation method based on function point analysis. [TMap]






5. A white box test design technique in which test cases are designed to execute branches.






6. Two persons - e.g. two testers - a developer and a tester - or an end-user and a tester - working together to find defects. Typically - they share one computer and trade control of it while testing.






7. A scale that constrains the type of data analysis that can be performed on it. [ISO 14598]






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






9. Test execution carried out by following a previously documented sequence of tests.






10. A development life cycle where a project is broken into a series of increments - each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the approp






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






12. A meeting at the end of a project during which the project team members evaluate the project and learn lessons that can be applied to the next project.






13. The capability of the software product to be diagnosed for deficiencies or causes of failures in the software - or for the parts to be modified to be identified. [ISO 9126] See also maintainability. The ease with which a software product can be modif






14. A sequence of transactions in a dialogue between a user and the system with a tangible result.






15. During the test closure phase of a test process data is collected from completed activities to consolidate experience - testware - facts and numbers. The test closure phase consists of finalizing and archiving the testware and evaluating the test pro






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






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






18. A tool that facilitates the recording and status tracking of incidents. They often have workflow-oriented facilities to track and control the allocation - correction and re-testing of incidents and provide reporting facilities. See also defect manage






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






20. A set of test cases derived from the internal structure of a component or specification to ensure that 100% of a specified coverage criterion will be achieved.






21. The percentage of condition outcomes that have been exercised by a test suite. 100% condition coverage requires each single condition in every decision statement to be tested as True and False.






22. Any (work) product that must be delivered to someone other than the (work) product's author.






23. The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality testing. Testing based on an analysis of the specification of the functionality of a compo






24. A document identifying test items - their configuration - current status and other delivery information delivered by development to testing - and possibly other stakeholders - at the start of a test execution phase. [After IEEE 829]






25. The percentage of definition-use pairs that have been exercised by a test suite.






26. A model that shows the growth in reliability over time during continuous testing of a component or system as a result of the removal of defects that result in reliability failures.






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






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






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






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






31. The fundamental test process comprises test planning and control - test analysis and design - test implementation and execution - evaluating exit criteria and reporting - and test closure activities.






32. A superior method or innovative practice that contributes to the improved performance of an organization under given context - usually recognized as 'best' by other peer organizations.






33. Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers - to determine whether or not a component or system satisfies the user/customer needs and fits within the business process






34. The process of identifying differences between the actual results produced by the component or system under test and the expected results for a test. Test comparison can be performed during test execution (dynamic comparison) or after test execution.






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






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






37. The composition of a component or system as defined by the number - nature - and interconnections of its constituent parts.






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






39. A systematic approach to risk identification and analysis of identifying possible modes of failure and attempting to prevent their occurrence. See also Failure Mode - Effect and Criticality Analysis (FMECA).






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






41. A system of (hierarchical) categories designed to be a useful aid for reproducibly classifying defects.






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






43. A chronological record of relevant details about the execution of tests. [IEEE 829]






44. The representation of selected behavioral characteristics of one physical or abstract system by another system. [ISO 2382/1]






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






46. A system whose failure or malfunction may result in death or serious injury to people - or loss or severe damage to equipment - or environmental harm.






47. A test case with concrete (implementation level) values for input data and expected results. Logical operators from high level test cases are replaced by actual values that correspond to the objectives of the logical operators. See also high level te






48. A black box test design technique in which test cases are designed to execute all possbile discrete combinations of each pair of input parameters. See also orthogonal array testing. A systematic way of testing all-pair combinations of variables using






49. The method used to perform the actual test execution - either manual or automated.






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