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






2. Testing the integration of systems and packages; testing interfaces to external organizations (e.g. Electronic Data Interchange - Internet).






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






4. A test approach in which the test suite comprises all combinations of input values and preconditions.






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






6. Testing practice for a project using agile methodologies - such as extreme programming (XP) - treating development as the customer of testing and emphasizing the test first design paradigm. See also test driven development. A way of developing softwa






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






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






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






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






11. The process through which decisions are reached and protective measures are implemented for reducing risks to - or maintaining risks within - specified levels.






12. A transition between two states of a component or system.






13. The set of generic and specific conditions - agreed upon with the stakeholders - for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding p






14. A requirement that does not relate to functionality - but to attributes such as reliability - efficiency - usability - maintainability and portability.






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






16. A software product that supports one or more test activities - such as planning and control - specification - building initial files and data - test execution and test analysis. [TMap] See also CAST. Acronym for Computer Aided Software Testing.






17. A computational model consisting of a finite number of states and transitions between those states - possibly with accompanying actions. [IEEE 610]






18. The leader and main person responsible for an inspection or other review process.






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






20. A continuous framework for test process improvement that describes the key elements of an effective test process - especially targeted at system testing and acceptance testing.






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






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






23. A review not based on a formal (documented) procedure.






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






25. Computer instructions and data definitions expressed in a programming language or in a form output by an assembler - compiler or other translator. [IEEE 610]






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






27. A table showing combinations of inputs and/or stimuli (causes) with their associated outputs and/or actions (effects) - which can be used to design test cases.






28. The period of time in a software development life cycle during which the components of a software product are executed - and the software product is evaluated to determine whether or not requirements have been satisfied. [IEEE 610]






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






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






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






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






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






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






35. A tool that supports the recording of requirements - requirements attributes (e.g. priority - knowledge responsible) and annotation - and facilitates traceability through layers of requirements and requirements change management. Some requirements ma






36. The use of software - e.g. capture/playback tools - to control the execution of tests - the comparison of actual results to expected results - the setting up of test preconditions - and other test control and reporting functions.






37. A type of test tool that enables data to be selected from existing databases or created - generated - manipulated and edited for use in testing.






38. The process of assigning a number or category to an entity to describe an attribute of that entity. [ISO 14598]






39. A document reporting on any event that occurred - e.g. during the testing - which requires investigation. [After IEEE 829]






40. The capability of the software product to co-exist with other independent software in a common environment sharing common resources. [ISO 9126] See also portability. The ease with which the software product can be transferred from one hardware or sof






41. A type of performance testing conducted to evaluate a system or component at or beyond the limits of its anticipated or specified work loads - or with reduced availability of resources such as access to memory or servers. [After IEEE 610] See also pe






42. A black box test design technique in which test cases are designed to execute business procedures and processes. [TMap] See also procedure testing. Testing aimed at ensuring that the component or system can operate in conjunction with new or existing






43. A sequence of events - e.g. executable statements - of a component or system from an entry point to an exit point.






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






45. The capability of the software product to be used in place of another specified software product for the same purpose in the same environment. [ISO 9126] See also portability. The ease with which the software product can be transferred from one hardw






46. A tool that supports the validation of models of the software or system [Graham].






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






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






49. A specific category of risk related to the type of testing that can mitigate (control) that category. For example the risk of user-interactions being misunderstood can be mitigated by usability testing.






50. Acronym for Computer Aided Software Engineering.






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