Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
75 Cards in this Set
- Front
- Back
- 3rd side (hint)
|
Verification
|
Confirmation by examination and through the provision of objective evidence that specified requirements have been fulfilled.
|
|
|
|
Validation
|
Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.
|
|
|
|
V-model
|
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.
|
|
|
|
Test level
|
A group of test activities that are organized and managed together. A test level is linked to the responsibilities in a project.
|
|
|
|
Off-the-shelf software (commercial off-the-shelf software, COTS)
|
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.
|
|
|
|
Incremental development model
|
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 appropriate increment. In some (but not all) versions of this life cycle model, each subproject follows a 'mini V-model' with its own design, coding and testing phases.
|
|
|
|
Component testing
|
The testing of individual software components.
|
|
|
|
Stub
|
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.
|
|
|
|
Driver
|
A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system.
|
|
|
|
Robustness
|
The degree to which a component or system can function correctly in the presence of invalid inputs or stressful environmental conditions.
|
|
|
|
Robustness testing
|
Testing to determine the robustness of the software product.
|
|
|
|
Test-driven development
|
A way of developing software where the test cases are developed, and often automated, before the software is developed to run those test cases.
|
|
|
|
Integration
|
The process of combining components or systems into larger assemblies.
|
|
|
|
Integration testing
|
Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems.
|
|
|
|
System testing
|
The process of testing an integrated system to verify that it meets specified requirements.
|
|
|
|
Requirement
|
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.
|
|
|
|
Functional requirement
|
A requirement that specifies a function that a component or system must perform.
|
|
|
|
Non-functional requirement
|
A requirement that does not relate to functionality, but to attributes of such as reliability, efficiency, usability, maintainability and portability.
|
|
|
|
Test environment
|
An environment containing hardware,instrumentation, simulators, software tools and other support elements needed to conduct a test.
|
|
|
|
Acceptance testing
|
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 users, customers or other authorized entity to determine whether or not to accept the system.
|
|
|
|
Operational testing
|
testing conducted to evaluate a component or system in its operational environment.
|
|
|
|
Compliance
|
The capability of the software product to adhere to standards, conventions or regulations in laws and similar prescriptions.
|
|
|
|
Compliance testing
|
The process of testing to determine the compliance of component or system.
|
|
|
|
Alpha testing
|
Simulated or actual operational testing by potential users/customers or an independent test team at the developers' site, but outside the development organization. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing.
|
|
|
|
Beta testing
|
Operational testing by potential and/or existing users/customers at an external site not otherwise involved with the developers, to determine whether or not a component or system satisfies the user/customer needs and fits within the business processes. Beta testing is often employed as a form of external acceptance testing for off-the-shelf software in order to acquire feedback from the market.
|
|
|
|
Test type
|
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.
|
|
|
|
Functional testing
|
Testing based on an analysis of the specification of the functionality of a component or system.
|
|
|
|
Black-box testing
|
Testing, either functional or non-functional, without reference to the internal structure of the component or system.
|
|
|
|
Black-box (specification-based) test design technique
|
Procedure to derive and/or select test cases based on an analysis of the specification, either functional or nonfunctional, of a component or system without reference to its internal structure.
|
|
|
|
Functionality
|
The capability of the software product to provide functions that meet stated and implied needs when the software is used under specified conditions.
|
suitability, accuracy, security, interoperability and compliance
|
|
|
Functionality testing
|
The process of testing to determine the functionality of a software product.
|
|
|
|
Interoperability
|
The capability of the software product to interact with one or more specified components or systems.
|
|
|
|
Interoperability testing
|
The process of testing to determine the interoperability of a software product.
|
|
|
|
Security
|
Attributes of software products that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data.
|
|
|
|
Security testing
|
Testing to determine the security of the software product.
|
|
|
|
Load testing
|
A test type concerned with measuring the behavior of a component or system with increasing load, e.g. the number of parallel users and/or numbers of transactions, to determine what load can be handled by the component or system.
|
|
|
|
Performance
|
The degree to which a system or component accomplishes its designated functions within given constraints regarding processing time and throughput rate.
|
|
|
|
Performance testing
|
The process of testing to determine the performance of a software product.
|
|
|
|
Stress testing
|
Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements.
|
|
|
|
Reliability
|
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.
|
maturity (robustness), fault-tolerance, recoverability and compliance
|
|
|
Reliability testing
|
The process of testing to determine the reliability of a software product.
|
|
|
|
Usability
|
The capability of the software to be understood, learned, used and attractive to the user when used under specified conditions.
|
understandability, learnability, operability, attractiveness and compliance
|
|
|
Usability testing
|
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.
|
|
|
|
Efficiency
|
The capability of the software product to provide appropriate performance, relative to the amount of resources used under stated conditions.
|
time behavior (performance), resource utilization and compliance
|
|
|
Efficiency testing
|
The process of testing to determine the efficiency of a software product.
|
|
|
|
Portability
|
The ease with which the software product can be transferred from one hardware or software environment to another.
|
adaptability, installability, co-existence, replaceability and compliance
|
|
|
Portability testing
|
The process of testing to determine the portability of a software product.
|
|
|
|
White-box testing (structural testing)
|
Testing based on an analysis of the internal structure of the component or system.
|
|
|
|
Code coverage
|
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.
|
|
|
|
Test suite
|
A set of several test cases for a component or system under test, where the postcondition of one test is often used as the precondition for the next one.
|
|
|
|
White-box test design technique
|
A procedure to derive and/or select test cases based on an analysis of the internal structure of a component or system.
|
|
|
|
Re-testing (confirmation testing)
|
Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions.
|
|
|
|
Regression testing
|
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 changed.
|
|
|
|
Test automation
|
The use of software to perform or support test activities, e.g. test management, test design, test execution and results checking.
|
|
|
|
Maintenance
|
Modification of a software product after delivery to correct defects, to improve performance or other attributes, or to adapt the product to a modified environment.
|
|
|
|
Maintenance testing
|
Testing the changes to an operational system or the impact of a changed environment to an operational system.
|
|
|
|
Maintainability
|
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.
|
analyzability, changeability, stability, testability and compliance
|
|
|
Maintainability testing
|
The process of testing to determine the maintainability of a software product.
|
|
|
|
Test oracle
|
A source to determine expected results to compare with the actual result of the software under test. An oracle may be a requirements specification, the existing system (for a benchmark), a user manual, or an individual's specialized knowledge, but should not be the code.
|
|
|
|
Impact analysis
|
The assessment of change to the layers of development documentation, test documentation and components, in order to implement a given change to specified requirements.
|
|
|
|
Operational environment
|
Hardware and software products installed at users' or customers' sites where the component or system under test will be used. The software may include operating systems, database management systems, and other applications.
|
|
|
|
Operational testing
|
Testing conducted to evaluate a component or system in its operational environment.
|
|
|
|
Characteristics of Good Testing
|
- for every development activity there is a corresponding testing activity;
- each test level has test objectives specific to that level; - the analysis and design of tests for a given test level should begin during the corresponding development activity; - testers should be involved in reviewing documents as soon as drafts are available in the development cycle. |
|
|
|
Understand the relationship between development, test activities and work products in the development life cycle and give examples based on project and product characteristics and context. (K2)
|
sdaf
|
|
|
|
Recognize the fact that software development models must be adapted to the context of project and product characteristics. (K1)
|
sdaf
|
|
|
|
Recall reasons for different levels of testing and characteristics of good testing in any life cycle model. (K1)
|
sdaf
|
|
|
|
Compare the different levels of testing: major objectives, typical objects of testing, typical targets of testing (e.g. functional or structural) and related work products, people who test, types of defects and failures to be identified. (K2)
|
sdf
|
|
|
|
Compare four software test types (functional, non-functional, structural and change-related) by example. (K2)
|
sadf
|
|
|
|
Recognize that functional and structural tests occur at any test level. (K1)
|
asdf
|
|
|
|
Identify and describe non-functional test types based on non-functional requirements. (K2)
|
asdf
|
|
|
|
Identify and describe test types based on the analysis of a software system's structure or architecture. (K2)
|
asdf
|
|
|
|
Describe the purpose of confirmation testing and regression testing. (K2)
|
asdf
|
|
|
|
Compare maintenance testing (testing an operational system) to testing a new application with respect to test types, triggers for testing and amount of testing. (K2)
|
asdf
|
|
|
|
Identify reasons for maintenance testing (modifications, migration and retirement). (K2)
|
asdf
|
|
|
|
Describe the role of regression testing and impact analysis in maintenance. (K2)
|
asdf
|
|
