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 requirement that specifies a function that a component or system must perform. [IEEE 610]






2. A set of exit criteria.






3. An instance of an input. See also input. A variable (whether stored within a component or outside) that is read by a component.






4. The process of identifying risks using techniques such as brainstorming - checklists and failure history.






5. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified to make future maintenance easier - or adapted to a changed environment. [ISO 9126]






6. Any event occurring that requires investigation. [After IEEE 1008]






7. An integration approach that combines the components or systems for the purpose of getting a basic functionality working early. See also integration testing. Testing performed to expose defects in the interfaces and in the interactions between integr






8. Two or more single conditions joined by means of a logical operator (AND - OR or XOR) - e.g. 'A>B AND C>1000'.






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






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






11. A test environment comprised of stubs and drivers needed to execute a test.






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






13. Testing where the system is subjected to large volumes of data. See also resource-utilization testing. The process of testing to determine the resource-utilization of a software product.






14. The capability of the software product to be adapted for different specified environments without applying actions or means other than those provided for this purpose for the software considered. [ISO 9126] See also portability. The ease with which t






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






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






17. An attribute of a component or system specified or implied by requirements documentation (for example reliability - usability or design constraints). [After IEEE 1008]






18. The consequence/outcome of the execution of a test. It includes outputs to screens - changes to data - reports - and communication messages sent out. See also actual result - expected result. The behavior produced/observed when a component or system






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






20. The percentage of boundary values that have been exercised by a test suite.






21. The association of the definition of a variable with the use of that variable. Variable uses include computational (e.g. multiplication) or to direct the execution of a path ("predicate" use).






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






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






24. An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements - e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.






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






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






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






28. A systematic evaluation of software acquisition - supply - development - operation - or maintenance process - performed by or on behalf of management that monitors progress - determines the status of plans and schedules - confirms requirements and th






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






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






31. Testing - either functional or non-functional - without reference to the internal structure of the component or system. Black-box test design technique Procedure to derive and/or select test cases based on an analysis of the specification - either fu






32. Procedure used to derive and/or select test cases.






33. [Beizer] A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.






34. The organizational artifacts needed to perform testing - consisting of test environments - test tools - office environment and procedures.






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






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






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






38. A memory access defect due to the attempt by a process to store data beyond the boundaries of a fixed length buffer - resulting in overwriting of adjacent memory areas or the raising of an overflow exception. See also buffer. A device or storage area






39. A review characterized by documented procedures and requirements - e.g. inspection.






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






41. (1) A standard against which measurements or comparisons can be made. (2) A test that is be used to compare components or systems to each other or to a standard as in (1). [After IEEE 610]






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






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






44. A skilled professional who is involved in the testing of a component or system.






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






46. A document summarizing testing activities and results. It also contains an evaluation of the corresponding test items against exit criteria. [After IEEE 829]






47. A scheme for the execution of test procedures. The test procedures are included in the test execution schedule in their context and in the order in which they are to be executed.






48. A document reporting on any flaw in a component or system that can cause the component or system to fail to perform its required function. [After IEEE 829]






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






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