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. An approach to testing to reduce the level of product risks and inform stakeholders on their status - starting in the initial stages of a project. It involves the identification of product risks and their use in guiding the test process.






2. Testing the attributes of a component or system that do not relate to functionality - e.g. reliability - efficiency - usability - maintainability and portability.






3. An attribute of a test indicating whether the same results are produced each time the test is executed.






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






5. Testing the quality of the documentation - e.g. user guide or installation guide.






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






7. An integration test type that is concerned with testing the interfaces between components or systems.






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






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






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






11. A type of test execution tool where inputs are recorded during manual testing in order to generate automated test scripts that can be executed later (i.e. replayed). These tools are often used to support automated regression testing.






12. Recording the details of any incident that occurred - e.g. during testing.






13. A tool that carries out static code analysis. The tool checks source code - for certain properties such as conformance to coding standards - quality metrics or data flow anomalies.






14. Testing that runs test cases that failed the last time they were run - in order to verify the success of corrective actions.






15. The period of time in the software life cycle during which the requirements for a software product are defined and documented. [IEEE 610]






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






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






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






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






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






21. A basic block that can be selected for execution based on a program construct in which one of two or more alternative program paths is available - e.g. case - jump - go to - if-then-else.






22. Choosing a set of input values to force the execution of a given path.






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






24. Artifacts produced during the test process required to plan - design - and execute tests - such as documentation - scripts - inputs - expected results - set-up and clear-up procedures - files - databases - environment - and any additional software or






25. Environmental and state conditions that must be fulfilled before the component or system can be executed with a particular test or test procedure.






26. The percentage of decision outcomes that have been exercised by a test suite. 100% decision coverage implies both 100% branch coverage and 100% statement coverage.






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






28. The totality of functionality and features of a software product that bear on its ability to satisfy stated or implied needs. [After ISO 9126]






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






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






31. A test is deemed to pass if its actual result matches its expected result.






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






33. A way of developing software where the test cases are developed - and often automated - before the software is developed to run those test cases.






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






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






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






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






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






39. The capability of the software product to be installed in a specified environment [ISO 9126]. See also portability. The ease with which the software product can be transferred from one hardware or software environment to another. [ISO 9126]






40. A test result in which a defect is reported although no such defect actually exists in the test object.






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






42. A document produced at the end of the test process summarizing all testing activities and results. It also contains an evaluation of the test process and lessons learned.






43. A test design technique in which a model of the statistical distribution of the input is used to construct representative test cases. See also operational profile testing. Statistical testing using a model of system operations (short duration tasks)






44. A device - computer program - or system that accepts the same inputs and produces the same outputs as a given system. [IEEE 610] See also simulator. A device - computer program or system used during testing - which behaves or operates like a given sy






45. A test design technique where the experience of the tester is used to anticipate what defects might be present in the component or system under test as a result of errors made - and to design tests specifically to expose them.






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






47. The degree of uniformity - standardization - and freedom from contradiction among the documents or parts of a component or system. [IEEE 610]






48. The importance of a risk as defined by its characteristics impact and likelihood. The level of risk can be used to determine the intensity of testing to be performed. A risk level can be expressed either qualitatively (e.g. high - medium - low) or qu






49. A software development approach whereby lines of code (production and/or test) of a component are written by two programmers sitting at a single computer. This implicitly means ongoing real-tim code reviews are performed.






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