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






2. The process of assessing identified risks to estimate their impact and probability of occurrence (likelihood).






3. Formal or informal testing conducted during the implementation of a component or system - usually in the development environment by developers. [After IEEE 610]






4. The process of testing to determine the interoperability of a software product. See also functionality testing. The process of testing to determine the functionality of a software product.






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






6. A five level staged framework that describes the key elements of an effective software process. The Capability Maturity Model covers best-practices for planning - engineering and managing software development and maintenance. [CMM] See also Capabilit






7. The calculated approximation of a result (e.g. effort spent - completion date - costs involved - number of test cases - etc.) which is usable even if input data may be incomplete - uncertain - or noisy.






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






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






10. Deviation of the component or system from its expected delivery - service or result. [After Fenton]






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






12. Testing the methods and processes used to access and manage the data(base) - to ensure access methods - processes and data rules function as expected and that during access to the database - data is not corrupted or unexpectedly deleted - updated or






13. Formal testing with respect to user needs - requirements - and business processes conducted to determine whether or not a system satisfies the acceptance criteria and to enable the user - customers or other authorized entity to determine whether or n






14. An approach to testing in which test cases are designed based on test objectives and test conditions derived from requirements - e.g. tests that exercise specific functions or probe non-functional attributes such as reliability or usability.






15. A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project. Examples of test levels are component test - integration test - system test and acceptance test. [After TMap]






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






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






18. The percentage of sequences of N+1 transitions that have been exercised by a test suite. [Chow]






19. A model that shows the growth in reliability over time during continuous testing of a component or system as a result of the removal of defects that result in reliability failures.






20. The testing of individual software components. [After IEEE 610]






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






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






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






24. A type of peer review that relies on visual examination of documents to detect defects - e.g. violations of development standards and non-conformance to higher level documentation. The most formal review technique and therefore always based on a docu






25. Procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.






26. An instance of an input. See also input. A variable (whether stored within a component or outside) that is read by a component.






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






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






29. A superior method or innovative practice that contributes to the improved performance of an organization under given context - usually recognized as 'best' by other peer organizations.






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






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






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






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






34. A technique used to analyze the causes of faults (defects). The technique visually models how logical relationships between failures - human errors - and external events can combine to cause specific faults to disclose.






35. A tool that provides run-time information on the state of the software code. These tools are most commonly used to identify unassigned pointers - check pointer arithmetic and to monitor the allocation - use and de-allocation of memory and to flag mem






36. The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions. [IEEE 610] See also error-tolerance - fault-tolerance. The ability of a system or component to continue normal o






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






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






39. A tool used to check that no brtoken hyperlinks are present on a web site.






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






41. A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item - control changes to those characteristics - record and report change processi






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






43. The process through which decisions are reached and protective measures are implemented for reducing risks to - or maintaining risks within - specified levels.






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






45. An element of configuration management - consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation. [IEEE 610]






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






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






48. A high level document describing the principles - approach and major objectives of the organization regarding testing.






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






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







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