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 statement which - when compiled - is translated into object code - and which will be executed procedurally when the program is running and may perform an action on data.






2. A test management task that deals with developing and applying a set of corrective actions to get a test project on track when monitoring shows a deviation from what was planned. See also test management. The planning - estimating - monitoring and co






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






4. The person involved in the review that identifies and describes anomalies in the product or project under review. Reviewers can be chosen to represent different viewpoints and roles in the review process.






5. A systematic way of testing all-pair combinations of variables using orthogonal arrays. It significantly reduces the number of all combinations of variables to test all pair combinations. See also pairwise testing. A black box test design technique i






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






7. The degree - expressed as a percentage - to which a specified coverage item has been exercised by a test suite.






8. A tool that supports the recording of requirements - requirements attributes (e.g. priority - knowledge responsible) and annotation - and facilitates traceability through layers of requirements and requirements change management. Some requirements ma






9. A white box test design technique in which test cases are designed to execute combinations of single condition outcomes (within one statement).






10. A skeletal or special-purpose implementation of a software component - used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component. [After IEEE 610]






11. The ability to identify related items in documentation and software - such as requirements with associated tests. See also horizontal traceability - vertical traceability. The tracing of requirements for a test level through the layers of test docume






12. A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [After IEEE 829]






13. Systematic application of procedures and practices to the tasks of identifying - analyzing - prioritizing - and controlling risk.






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






15. A computational model consisting of a finite number of states and transitions between those states - possibly with accompanying actions. [IEEE 610]






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






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






18. A test plan that typically addresses one test level. 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






19. The process of finding - analyzing and removing the causes of failures in software.






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






21. A defect in a program's dynamic store allocation logic that causes it to fail to reclaim memory after it has finished using it - eventually causing the program to fail due to lack of memory.






22. A set of interrelated activities - which transform inputs into outputs. [ISO 12207]






23. The capability of the software product to adhere to standards - conventions or regulations in laws and similar prescriptions. [ISO 9126]






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






25. A program point at which the control flow has two or more alternative routes. A node with two or more links to separate branches.






26. A technique used to characterize the elements of risk. The result of a hazard analysis will drive the methods used for development and testing of a system. See also risk analysis. The process of assessing identified risks to estimate their impact and






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






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






29. The ease with which a software product can be modified to correct defects - modified to meet new requirements - modified to make future maintenance easier - or adapted to a changed environment. [ISO 9126]






30. The representation of selected behavioral characteristics of one physical or abstract system by another system. [ISO 2382/1]






31. Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software - as a result of the changes made. It is performed when the software or its environment is c






32. [Beizer] A black box test design technique in which test cases are designed to execute representatives from equivalence partitions. In principle test cases are designed to cover each partition at least once.






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






34. The association of the definition of a variable with the use of that variable. Variable uses include computational (e.g. multiplication) or to direct the execution of a path ("predicate" use).






35. An informal test design technique where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests. [After Bach]






36. A development life cycle where a project is broken into a series of increments - each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the approp






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






38. A white box test design technique in which test cases are designed to execute definition and use pairs of variables.






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






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






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






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






43. An uninterrupted period of time spent in executing tests. In exploratory testing - each test session is focused on a charter - but testers can also explore new opportunities or issues during a session. The tester creates and executes test cases on th






44. A reason or purpose for designing and executing a test.






45. A tool that supports the test design activity by generating test inputs from a specification that may be held in a CASE tool repository - e.g. requirements management tool - from specified test conditions held in the tool itself - or from code.






46. A portion of an input or output domain for which the behavior of a component or system is assumed to be the same - based on the specification.






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






48. A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system.






49. An incremental approach to integration testing where the lowest level components are tested first - and then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the hierarchy is tested






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