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 to determine the scalability of the software product.






2. A tool that supports stress testing.






3. Testing in which two or more variants of a component or system are executed with the same inputs - the outputs compared - and analyzed in cases of discrepancies. [IEEE 610]






4. Testing of individual components in isolation from surrounding components - with surrounding components being simulated by stubs and drivers - if needed.






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






6. A software tool used to carry out instrumentation.






7. The capability of the software product to interact with one or more specified components or systems. [After ISO 9126] See also functionality. The capability of the software product to provide functions which meet stated and implied needs when the sof






8. The percentage of executable statements that have been exercised by a test suite.






9. An independent evaluation of software products or processes to ascertain compliance to standards - guidelines - specifications - and/or procedures based on objective criteria - including documents that specify: (1) the form or content of the products






10. The number of defects found by a test phase - divided by the number found by that test phase and any other means afterwards.






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






12. The capability of the software product to enable the user to learn its application. [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






13. Testing to determine how the occurrence of two or more activities within the same interval of time - achieved either by interleaving the activities or by simultaneous execution - is handled by the component or system. [After IEEE 610]






14. The use of software to perform or support test activities - e.g. test management - test design - test execution and results checking.






15. A method to determine test suite thoroughness by measuring the extent to which a test suite can discriminate the program from slight variants (mutants) of the program.






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






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






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






19. An element of storage in a computer that is accessible by a software program by referring to it by a name.






20. A capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within specified process areas. [CMMI]






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






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






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






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






25. An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements. Examples include management review - informal review - technical review - inspection - and walkthrough. [After IEEE 1028]






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






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






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






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






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






31. A path for which a set of input values and preconditions exists which causes it to be executed.






32. The process of developing and prioritizing test procedures - creating test data and - optionally - preparing test harnesses and writing automated test scripts.






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






34. A condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract - standard - specification - or other formally imposed document. [After IEEE 610






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






36. The exit criteria that a component or system must satisfy in order to be accepted by a user - customer - or other authorized entity. [IEEE 610]






37. An abstract representation of all possible sequences of events (paths) in the execution through a component or system.






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






39. An environment containing hardware - instrumentation - simulators - software tools - and other support elements needed to conduct a test. [After IEEE 610]






40. The person who records each defect mentioned and any suggestions for process improvement during a review meeting - on a logging form. The scribe has to ensure that the logging form is readable and understandable.






41. An entity or property used as a basis for test coverage - e.g. equivalence partitions or code statements.






42. A source of a defect such that if it is removed - the occurance of the defect type is decreased or removed. [CMMI]






43. A tool that provides support for testing security characteristics and vulnerabilities.






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






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






46. A framework to describe the software development life cycle activities from requirements specification to maintenance. The V-model illustrates how testing activities can be integrated into each phase of the software development life cycle.






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






48. A special instance of a smoke test to decide if the component or system is ready for detailed and further testing. An intake test is typically carried out at the start of the test execution phase. See also smoke test. A subset of all defined/planned






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






50. The process of testing to determine the interoperability of a software product.







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