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 defect in a program's dynamic store allocation logic that causes it to fail to reclaim memory after it has finished using it - eventually causing the program to fail due to lack of memory.






2. The process of testing to determine the functionality of a software product.






3. The physical or functional manifestation of a failure. For example - a system in failure mode may be characterized by slow operation - incorrect outputs - or complete termination of execution. [IEEE 610]






4. A statement which - when compiled - is translated into object code - and which will be executed procedurally when the program is running and may perform an action on data.






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






6. An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members.






7. A test whereby real-life users are involved to evaluate the usability of a component or system.






8. The individual element to be tested. There usually is one test object and many test items. See also test object. A reason or purpose for designing and executing a test.






9. A test basis document that can only be amended by a formal change control process. See also baseline. A specification or software product that has been formally reviewed or agreed upon - that thereafter serves as the basis for further development - a






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






11. A path that cannot be exercised by any set of possible input values.






12. A tool that provides objective measures of what structural elements - e.g. statements - branches have been exercised by a test suite.






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






14. Decision rules used to determine whether a test item (function) or feature has passed or failed a test. [IEEE 829]






15. Testing that involves the execution of the software of a component or system.






16. A programming language in which executable test scripts are written - used by a test execution tool (e.g. a capture/playback tool).






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






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






19. An input for which the specification predicts a result.






20. A white box test design technique in which test cases are designed to execute statements.






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






22. The component or system to be tested. See also test item. The individual element to be tested. There usually is one test object and many test items. See also test object. A reason or purpose for designing and executing a test.






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






24. A series which appears to be random but is in fact generated according to some prearranged sequence.






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






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






27. The assessment of change to the layers of development documentation - test documentation and components - in order to implement a given change to specified requirements.






28. A collection of components organized to accomplish a specific function or set of functions. [IEEE 610]






29. A program of activities designed to improve the performance and maturity of the organization's processes - and the result of such a program. [CMMI]






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






31. A pointer within a web page that leads to other web pages.






32. A specification or software product that has been formally reviewed or agreed upon - that thereafter serves as the basis for further development - and that can be changed only through a formal change control process. [After IEEE 610]






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






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






35. Testing the methods and processes used to access and manage the data(base) - to ensure access methods - processes and data rules function as expected and that during access to the database - data is not corrupted or unexpectedly deleted - updated or






36. A set of several test cases for a component or system under test - where the post condition of one test is often used as the precondition for the next one.






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






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






39. A subset of all defined/planned test cases that cover the main functionality of a component or system - to ascertaining that the most crucial functions of a program work - but not bothering with finer details. A daily build and smoke test is among in






40. A flaw in a component or system that can cause the component or system to fail to perform its required function - e.g. an incorrect statement or data definition. A defect - if encountered during execution - may cause a failure of the component or sys






41. The degree to which a component - system or process meets specified requirements and/or user/customer needs and expectations. [After IEEE 610]






42. The representation of a distinct set of tasks performed by the component or system - possibly based on user behavior when interacting with the component or system - and their probabilities of occurance. A task is logical rather that physical and can






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






44. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [After IEEE 829]






45. The capability of the software product to adhere to standards - conventions or regulations in laws and similar prescriptions. [ISO 9126]






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






47. 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 testing tasks - who will do each task - degree of tester independence - the tes






48. The capability of the software product to enable specified modifications to be implemented. [ISO 9126] See also maintainability. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified






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






50. A tree showing equivalence parititions hierarchically ordered - which is used to design test cases in the classification tree method. See also classification tree method. A black box test design technique in which test cases - described by means of a






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