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 version of component integration testing where the progressive integration of components follows the implementation of subsets of the requirements - as opposed to the integration of components by levels of a hierarchy.






2. A test case without concrete (implementation level) values for input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available. See also low level test case. A test case with concrete (






3. A measurement scale and the method used for measurement. [ISO 14598]






4. The capability of the software product to provide appropriate performance - relative to the amount of resources used under stated conditions. [ISO 9126]






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






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






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






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






9. A tool that provides support to the test management and control part of a test process. It often has several capabilities - such as testware management - scheduling of tests - the logging of results - progress tracking - incident management and test






10. An entity in a programming language - which is typically the smallest indivisible unit of execution.






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






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






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






14. During the test closure phase of a test process data is collected from completed activities to consolidate experience - testware - facts and numbers. The test closure phase consists of finalizing and archiving the testware and evaluating the test pro






15. A tool that carries out static analysis.






16. Testing based on an analysis of the specification of the functionality of a component or system. See also black box testing. Testing - either functional or non-functional - without reference to the internal structure of the component or system. Black






17. A skilled professional who is involved in the testing of a component or system.






18. A document identifying test items - their configuration - current status and other delivery information delivered by development to testing - and possibly other stakeholders - at the start of a test execution phase. [After IEEE 829]






19. Testing by means of a random selection from a large range of inputs and by randomly pushing buttons - ignorant on how the product is being used.






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






21. A risk related to management and control of the (test) project - e.g. lack of staffing - strict deadlines - changing requirements - etc. See also risk. A factor that could result in future negative consequences; usually expressed as impact and likeli






22. A factor that could result in future negative consequences; usually expressed as impact and likelihood.






23. The behavior produced/observed when a component or system is tested.






24. A variable (whether stored within a component or outside) that is written by a component.






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






26. Two persons - e.g. two testers - a developer and a tester - or an end-user and a tester - working together to find defects. Typically - they share one computer and trade control of it while testing.






27. The capability of the software product to enable the user to understand whether the software is suitable - and how it can be used for particular tasks and conditions of use. [ISO 9126] See also usability. The capability of the software to be understo






28. Coverage measures based on the internal structure of a component or system.






29. A data item that specifies the location of another data item; for example - a data item that specifies the address of the next employee record to be processed. [IEEE 610]






30. A memory access defect due to the attempt by a process to store data beyond the boundaries of a fixed length buffer - resulting in overwriting of adjacent memory areas or the raising of an overflow exception. See also buffer. A device or storage area






31. A diagram that depicts the states that a component or system can assume - and shows the events or circumstances that cause and/or result from a change from one state to another. [IEEE 610]






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






33. Testing to determine the robustness of the software product.






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






35. A path by which the original input to a process (e.g. data) can be traced back through the process - taking the process output as a starting point. This facilitates defect analysis and allows a process audit to be carried out. [After TMap]






36. A white box test design technique in which test cases are designed to execute paths.






37. An instance of an output. See also output.A variable (whether stored within a component or outside) that is written by a component.






38. The ability of the software product to perform its required functions under stated conditions for a specified period of time - or for a specified number of operations. [ISO 9126]






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






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






41. The process of testing the installability of a software product. See also portability testing. The process of testing to determine the portability of a software product.






42. The capability of the software product to re-establish a specified level of performance and recover the data directly affected in case of failure. [ISO 9126] See also reliability. The ability of the software product to perform its required functions






43. Procedure to derive and/or select test cases based on the tester's experience - knowledge and intuition.






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






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






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






47. A Linear Code Sequence And Jump - consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements - the end of the linear sequence - and the targe






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






49. The capability of the software product to provide the right or agreed results or effects with the needed degree of precision. [ISO 9126] See also functionality testing. Testing based on an analysis of the specification of the functionality of a compo






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