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. Behavior of a component or system in response to erroneous input - from either a human user or from another component or system - or to an internal failure.






2. A minimal software item that can be tested in isolation.






3. A test case that cannot be executed because the preconditions for its execution are not fulfilled.






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






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






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






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






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






9. The consequence/outcome of the execution of a test. It includes outputs to screens - changes to data - reports - and communication messages sent out.






10. The capability of the software to be understood - learned - used and attractive to the user when used under specified conditions. [ISO 9126]






11. A test plan that typically addresses one test phase. See also test plan. 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 testin






12. A static usability test technique to determine the compliance of a user interface with recognized usability principles (the so-called "heuristics").






13. A tool that provides support to the review process. Typical features include review planning and tracking support - communication support - collaborative reviews and a repository for collecting and reporting of metrics.






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






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






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






17. A sequence of executable statements within a component.






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






19. A five level staged framework for test process improvement - related to the Capability Maturity Model (CMM) - that describes the key elements of an effective test process.






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






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






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






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






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






25. Directed and focused attempt to evaluate the quality - especially reliability - of a test object by attempting to force specific failures to occur.






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






27. Testing to determine the extent to which the software product is understood - easy to learn - easy to operate and attractive to the users under specified conditions. [After ISO 9126]






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






29. A graphical representation of inputs and/or stimuli (causes) with their associated outputs (effects) - which can be used to design test cases.






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






31. Tests aimed at showing that a component or system does not work. Negative testing is related to the testers' attitude rather than a specific test approach or test design technique - e.g. testing with invalid input values or exceptions. [After Beizer]






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






33. The capability of the software product to use appropriate amounts and types of resources - for example the amounts of main and secondary memory used by the program and the sizes of required temporary or overflow files - when the software performs its






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






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






36. A document that consists of a test design specification - test case specification and/or test procedure specification.






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






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






39. Statistical testing using a model of system operations (short duration tasks) and their probability of typical use. [Musa]






40. Procedure to derive and/or select test cases based on an analysis of the specification of the functionality of a component or system without reference to its internal structure. See also black box test design technique. Procedure to derive and/or sel






41. The tracing of requirements for a test level through the layers of test documentation (e.g. test plan - test design specification - test case specification and test procedure specification or test script).






42. An input value or output value which is on the edge of an equivalence partition or at the smallest incremental distance on either side of an edge - for example the minimum or maximum value of a range.






43. The total costs incurred on quality activities and issues and often split into prevention costs - appraisal costs - internal failure costs and external failure costs.






44. Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems. See also component integration testing - system integration testing. Testing performed to expose defects in the interfaces and int






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






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






47. A grid showing the resulting transitions for each state combined with each possible event - showing both valid and invalid transitions.






48. A 2-dimensional array constructed with special mathematical properties - such that choosing any two columns in the array provides every pair combination of each number in the array.






49. A form of static analysis based on the definition and usage of variables.






50. The data received from an external source by the test object during test execution. The external source can be hardware - software or human.