|
Automation
|
Automating a manual process already in place that uses a formalized testing process. It involves the management and performance of test activities needed to develop and execute test cases using an automated test tool (3rd party/programming languages).
|
|
Black Box Testing
|
The test focuses on the functionality and performance without knowing the structure within the object. Sometime, the results of the black box test may be correct accidentally. Therefore, scientific and random/ exploratory techniques should be both used to cross check the results.
|
|
Coverage
|
The relation between what is tested by the test set and what may be tested, e.g. the number of paths, conditions and interfaces covered by the test design.
|
|
Defect
|
A flaw in the software, hardware or environment with the potential to cause failure. Defects can be found in the requirements, design, code, environment, test and/or documentation.
|
|
Defect Severity
|
"Severity ratings can be used to allocate resources to fix the most severe problems. Very High severity indicates major functional problems. Low severity indicates cosmetics type defects.
Even though severity has several components, it is common to combine all aspects into a single rating in order to facilitate prioritizing and decision-making. "
|
|
Development Environment
|
|
|
Entry Criteria
|
|
|
Exit Criteria
|
|
|
Functional Testing
|
|
|
Integration Test
|
A level of test used to ensure the basic functionality intended is being delivered and to verify the stability of a build before delivered to the next level of test. This is the minimum requirement at the end of unit test prior to migration to system test.
|
|
IT Test Environment
|
|
|
Iteration Test Plan
|
|
|
Load Test
|
|
|
Master Test Plan
|
|
|
Non-Functional Testing
|
|
|
Performance Center
|
|
|
Performance Environment
|
|
|
Performance Test
|
To determine the effect of a certain workload on one or more of the following performance aspects: response time, utilization and throughput. This is achieved by driving a defined workload through one or more components of the infrastructure. The components are likely to be a mix of both hardware and software.
|
|
Production Environment
|
|
|
Quality Assurance Environment
|
|
|
Quality Center
|
|
|
Quality Characteristics
|
|
|
Regression Test
|
|
|
Risk Based Approach
|
Test priorities are based on the risks of the test items. Risk of a test item is derived from its business impact and development complexity.
|
|
Security Test
|
|
|
Smoke Test
|
Type of test used to validate the stability of a build before and/or upon delivery to the next level of test. This is an entry requirement into the System level of test.
|
|
System Test
|
This is the overall level of testing performed by the QM Team or Business Testers. This level is intended to test a ‘build’ that is a logical set of units to perform certain function(s). The black box integration test is to be executed by the QM Team against the functional requirement and design. System Testing can vary from a simple function to system integration. Each interface of data modules should be covered by an integration test case with all possible scenarios.
|
|
Test Basis
|
|
|
Test Case
|
A test case specifies the conditions which need to be validated to enable an assessment of some particular aspects of the system under test. A test case is more formal than a test idea and usually takes the form of a specification. In less formal environments, test cases can be created by identifying a unique ID, name, associated test data, and expected results. Test cases may be derived from many sources but will usually include a subset of both the requirements (such as use cases, performance characteristics, reliability concerns) and other types of quality attributes.
|
|
Test Components
|
Test components are the reusable building blocks that can be arranged to construct various test cases.
|
|
Test Environment
|
|
|
Test Evaluation Summary
|
|
|
Test Levels
|
Group of test activities organized and managed together. Standardized levels for AFISG are Unit, Integration, System and User Acceptance Testing
|
|
Test Script
|
|
|
Test Strategy
|
|
|
Test Technique
|
(aka Test Specification Technique) A set of actions aimed at creating a test deliverable using a universal method. Pairwise, Data Combination, Process Cycle, Boundary Value Analysis, Decision Table, etc. Testing techniques are used to assure adequate coverage while reducing the number of possible testing permutations and eliminating any redundant scenarios. These techniques could reduce test resource needs and time while achieving the right level of test coverage.
|
|
Test Type
|
|
|
TMAP
|
Test Management Approach is a generic approach to structured testing of information systems that has been widely used in the industry. This is the test methodology CG endorsed.
|
|
Traceability
|
|
|
Unit Test
|
Developers in their own development environment perform this level of testing. Each decision branch in the code specification should be covered by a unit test case. The developers should execute the white box test as part of the unit testing. When the modules are turned to the QM Team, all logics, data boundaries, and behaviors should have been unit tested and appear to be error free and fully match the functional and design requirements.
|
|
Useability Test
|
|
|
User Acceptance Test
|
This level of testing is completed to assure business acceptance prior to the go/no go decision for the production release. Business end users should participate in testing to validate their requirements have been met. There should be a final end to end UAT before the user community gives the final sign off. Each business requirement should be covered by a UAT test case that verifies the functions, UI, user friendliness, performance, and procedures are acceptable.
|
