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. Test execution carried out by following a previously documented sequence of tests.






2. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 transitions. [Chow] See also state transition testing. A black box test design technique in which test cases are designed to execute valid and i






3. A white box test design technique in which test cases are designed to execute LCSAJs.






4. The degree to which a requirement is stated in terms that permit establishment of test designs (and subsequently test cases) and execution of tests to determine whether the requirements have been met. [After IEEE 610]






5. The process of evaluating behavior - e.g. memory performance - CPU usage - of a system or component during execution. [After IEEE 610]






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






7. The insertion of additional code into the program in order to collect information about program behavior during execution - e.g. for measuring code coverage.






8. The process of testing to determine the compliance of the component or system.






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






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






11. A type of performance testing conducted to evaluate the behavior of a component or system with increasing load - e.g. numbers of parallel users and/or numbers of transactions - to determine what load can be handled by the component or system. See als






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






13. A sequence of executable statements within a component.






14. The percentage of equivalence partitions that have been exercised by a test suite.






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






16. An approach to testing in which test cases are designed based on descriptions and/or knowledge of business processes.






17. A scripting technique that stores test input and expected results in a table or spreadsheet - so that a single control script can execute all of the tests in the table. Data driven testing is often used to support the application of test execution to






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






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






20. A black box test design technique in which test cases are designed to execute valid and invalid state transitions. See also N-switch testing. A form of state transition testing in which test cases are designed to execute all valid sequences of N+1 tr






21. The method used to perform the actual test execution - either manual or automated.






22. A test is deemed to fail if its actual result does not match its expected result.






23. Testing to determine the ease by which users with disabilities can use a component or system. [Gerrard]






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






25. Execution of a test on a specific version of the test object.






26. The set from which valid input values can be selected. See also domain. The set from which valid input and/or output values can be selected.






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






28. A test tool to perform automated test comparison of actual results with expected results.






29. A group of test activities aimed at testing a component or system focused on a specific test objective - i.e. functional test - usability test - regression test etc. A test type may take place on one or more test levels or test phases. [After TMap]






30. A tool that facilitates the recording and status tracking of defects and changes. They often have workflow-oriented facilities to track and control the allocation - correction and re-testing of defects and provide reporting facilities. See also incid






31. A pointer within a web page that leads to other web pages.






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






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






34. Testing to determine the safety of a software product.






35. The behavior predicted by the specification - or another source - of the component or system under specified conditions.






36. A requirement that specifies a function that a component or system must perform. [IEEE 610]






37. A type of integration testing in which software elements - hardware elements - or both are combined all at once into a component or an overall system - rather than in stages. [After IEEE 610] See also integration testing. Testing performed to expose






38. The capability of the software product to be attractive to the user. [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 9126]






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






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






41. Testing conducted to evaluate a component or system in its operational environment. [IEEE 610]






42. The component or system to be tested. See also test item. The individual element to be tested. There usually is one test object and many test items. See also test object. A reason or purpose for designing and executing a test.






43. A white box test design technique in which test cases are designed to execute branches.






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






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






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






47. A peer group discussion activity that focuses on achieving consensus on the technical approach to be taken. [Gilb and Graham - IEEE 1028] See also peer review. A review of a software work product by colleagues of the producer of the product for the p






48. A group of people responsible for evaluating and approving or disapproving proposed changes to configuration items - and for ensuring implementation of approved changes. [IEEE 610]






49. The capability of the software product to be upgraded to accommodate increased loads. [After Gerrard]






50. A feature or characteristic that affects an item's quality. [IEEE 610]