CAST Full Deck Flashcards
(318 cards)
1
Q
Acceptance Criteria
A
A key prerequisite for test planning is a clear understanding of what must be accomplished for the test project to be deemed successful.
2
Q
Acceptance Testing
A
The objective of acceptance testing is to determine throughout the development cycle that all aspects of the development process meet the user’s needs.
3
Q
Act
A
If your checkup reveals that the work is not being performed according to plan or that results are not as anticipated, devise measures for appropriate action. (Plan-Do-Check-Act)
4
Q
Access Modeling
A
Used to verify that data requirements (represented in the form of an entity-relationship diagram) support the data demands of process requirements (represented in data flow diagrams and process specifications.)
5
Q
Active Risk
A
Risk that is deliberately taken on. For example, the choice to develop a new product that may not be successful in the marketplace.
6
Q
Actors
A
Interfaces in a system boundary diagram. (Use Cases)
7
Q
Alternate Path
A
Additional testable conditions are derived from the exceptions and alternative course of the Use Case.
8
Q
Affinity Diagram
A
A group process that takes large amounts of language data, such as a list developed by brainstorming, and divides it into categories.
9
Q
Analogous
A
The analogy model is a nonalgorithmic costing model that estimates the size, effort, or cost of a project by relating it to another similar completed project. Analogous estimating takes the actual time and/or cost of a historical project as a basis for the current project.
10
Q
Analogous Percentage Method
A
A common method for estimating test effort is to calculate the test estimate as a percentage of previous test efforts using a predicted size factor (SF) (e.g., SLOC or FPA).
11
Q
Application
A
A single software product that may or may not fully support a business function.
12
Q
Appraisal Costs
A
Resources spent to ensure a high level of quality in all
development life cycle stages which includes conformance to quality standards and delivery of products that meet the user’s requirements/needs. Appraisal costs include the cost of in-process reviews, dynamic testing, and final inspections.
13
Q
Appreciative or Enjoyment Listening
A
One automatically switches to this type of listening when it is perceived as a funny situation or an explanatory example will be given of a situation. This listening type helps understand real-world situations.
14
Q
Assumptions
A
A thing that is accepted as true.
15
Q
Audit
A
This is an inspection/assessment activity that verifies compliance with plans, policies, and procedures, and ensures that resources are conserved. Audit is a staff function; it serves as the “eyes and ears” of management.
16
Q
Backlog
A
Work waiting to be done; for IT this includes new systems to be developed and enhancements to existing systems. To be included in the development backlog, the work must have been cost-justified and approved for development. A product backlog in Scrum is a prioritized featured list containing short descriptions of all functionality desired in the product.
17
Q
Baseline
A
A quantitative measure of the current level of performance.
18
Q
Benchmarking
A
Comparing your company’s products, services, or processes against best practices, or competitive practices, to help define superior performance of a product, service, or support process.
19
Q
Benefits Realization Test
A
A test or analysis conducted after an application is moved into production to determine whether it is likely to meet the originating business case.
20
Q
Black-Box Testing
A
A test technique that focuses on testing the functionality of the program, component, or application against its specifications without knowledge of how the system is constructed; usually data or business process driven.
21
Q
Bottom-Up
A
Begin testing from the bottom of the hierarchy and work up to the top. Modules are added in ascending hierarchical order. Bottom-up testing requires the development of driver modules, which provide the test input, that call the module or program being tested, and display test output.
22
Q
Bottom-Up Estimation
A
In this technique, the cost of each single activity is determined with the greatest level of detail at the bottom level and then rolls up to calculate the total project cost.
23
Q
Boundary Value Analysis
A
A data selection technique in which test data is chosen from the “boundaries” of the input or output domain classes, data structures, and procedure parameters. Choices often include the actual minimum and maximum boundary values, the maximum value plus or minus one, and the minimum value plus or minus one.
24
Q
Brainstorming
A
A group process for generating creative and diverse ideas.
25
Branch Combination Coverage
Branch Condition Combination Coverage is a very thorough structural testing technique, requiring 2n test cases to achieve 100% coverage of a condition containing n Boolean operands.
26
Branch/Decision Testing
A test method that requires that each possible branch on each decision point be executed at least once.
27
Bug
A general term for all software defects or errors.
28
Calibration
This indicates the movement of a measure so it becomes more valid, for example, changing a customer survey so it better reflects the true opinions of the customer.
29
Candidate
An individual who has met eligibility requirements for a credential awarded through a certification program, but who has not yet earned that certification through participation in the required skill and knowledge assessment instruments.
30
Causal Analysis
The purpose of causal analysis is to prevent problems by
determining the problem’s root cause. This shows the relation between an effect and its possible causes to eventually find the root cause of the issue.
31
Cause and Effect Diagrams
A cause and effect diagram visualizes results of brainstorming and affinity grouping through major causes of a significant process problem.
32
Cause-Effect Graphing
Cause-effect graphing is a technique which focuses on modeling the dependency relationships between a program’s input conditions (causes) and output conditions (effects). CEG is considered a Requirements-Based test technique and is often referred to as Dependency modeling.
33
Certificant
An individual who has earned a credential awarded through a certification program.
34
Certification
A voluntary process instituted by a nongovernmental agency by which individual applicants are recognized for having achieved a measurable level of skill or knowledge. Measurement of the skill or knowledge makes certification more restrictive than simple registration, but much less restrictive than formal licensure.
35
Change Management
Managing software change is a process. The process is the primary responsibility of the software development staff. They must assure that the change requests are documented, that they are tracked through approval or rejection, and then incorporated into the development process.
36
Check
Check to determine whether work is progressing according to the plan and whether the expected results are obtained. Check for performance of the set procedures, changes in conditions, or abnormalities that may appear. As often as possible, compare the results of the work with the objectives.
37
Check Sheets
A check sheet is a technique or tool to record the number of occurrences over a specified interval of time; a data sample to determine the frequency of an event.
38
Checklists
A series of probing questions about the completeness and attributes of an application system. Well-constructed checklists cause evaluation of areas, which are prone to problems. It both limits the scope of the test and directs the tester to the areas in which there is a high probability of a problem.
39
Checkpoint Review
Held at predefined points in the development process to evaluate whether certain quality factors (critical success factors) are being adequately addressed in the system being built. Independent experts for the purpose of identifying problems conduct the reviews as early as possible.
40
Client
The customer that pays for the product received and receives the benefit from the use of the product.
41
CMMI-Dev
A process improvement model for software development.
Specifically, CMMI for Development is designed to compare an organization’s existing development processes to proven best practices developed by members of industry, government, and academia.
42
Coaching
Providing advice and encouragement to an individual or individuals to promote a desired behavior.
43
COCOMO II
The best recognized software development cost model is the Constructive Cost Model II.COCOMO®II is an enhancement over the original COCOMO® model. COCOMO®II extends the capability of the model to include a wider collection of techniques and technologies. It provides support for object-oriented software, business software, software created via spiral or evolutionary development models and software using COTS application utilities.
44
Code Comparison
One version of source or object code is compared to a second version. The objective is to identify those portions of computer programs that have been changed. The technique is used to identify those segments of an application program that have been altered as a result of a program change.
45
Common Causes of Variation
Common causes of variation are typically due to a large number of small random sources of variation. The sum of these sources of variation determines the magnitude of the process’s inherent variation due to common causes; the process’s control limits and current process capability can then be determined.
46
Compiler-Based Analysis
Most compilers for programming languages include diagnostics that identify potential program structure flaws. Many of these diagnostics are warning messages requiring the programmer to conduct additional investigation to determine whether or not the problem is real. Problems may include syntax problems, command
violations, or variable/data reference problems. These diagnostic messages are a useful means of detecting program problems, and should be used by the programmer.
47
Complete Test Set
A test set containing data that causes each element of prespecified set of Boolean conditions to be true. In addition, each element of the test set causes at least one condition to be true.
48
Completeness
The property that all necessary parts of an entity are included. Often, a product is said to be complete if it has met all requirements.
49
Complexity-Based Analysis
Based upon applying mathematical graph theory to programs and preliminary design language specification (PDLs) to determine a unit's complexity. This analysis can be used to measure and control complexity when maintainability is a desired attribute. It can also be used to estimate test effort required and identify paths that
must be tested.
50
Compliance Checkers
A parse program looking for violations of company standards. Statements that contain violations are flagged. Company standards are rules that can be added, changed, and deleted as needed.
51
Comprehensive Listening
Designed to get a complete message with minimal distortion. This type of listening requires a lot of feedback and summarization to fully understand what the speaker is communicating.
52
Compromise
An intermediate approach – Partial satisfaction is sought for both parties through a “middle ground” position that reflects mutual sacrifice. Compromise evokes thoughts of giving up something, therefore earning the name “lose-lose.”
53
Condition Coverage
A white-box testing technique that measures the number of, or percentage of, decision outcomes covered by the test cases designed. 100% condition coverage would indicate that every possible outcome of each decision had been executed at least once during testing.
54
Condition Testing
A structural test technique where each clause in every condition is forced to take on each of its possible values in combination with those of other clauses.
55
Configuration Management
Software Configuration Management (CM) is a process for tracking and controlling changes in the software. The ability to maintain control over changes made to all project artifacts is critical to the success of a project. The more complex an application is, the more important it is to control change to both the application and its supporting artifacts.
56
Configuration Management Tools
Tools that are used to keep track of changes made to systems and all related artifacts. These are also known as version control tools.
57
Configuration Testing
Testing of an application on all supported hardware and software platforms. This may include various combinations of hardware types, configuration settings, and software versions.
58
Consistency
The property of logical coherence among constituent parts. Consistency can also be expressed as adherence to a given set of rules.
59
Consistent Condition Set
A set of Boolean conditions such that complete test sets for the conditions uncover the same errors.
60
Constraints
A limitation or restriction. Constraints are those items that will likely force a dose of “reality” on a test project. The obvious constraints are test staff size, test schedule, and budget.
61
Constructive Criticism
A process of offering valid and well-reasoned opinions about the work of others, usually involving both positive and negative comments, in a friendly manner rather than an oppositional one.
62
Control
Control is anything that tends to cause the reduction of risk. Control can accomplish this by reducing harmful effects or by reducing the frequency of occurrence.
63
Control Charts
A statistical technique to assess, monitor and maintain the stability of a process. The objective is to monitor a continuous repeatable process and the process variation from specifications. The intent of a control chart is to monitor the variation of a statistically stable process where activities are repetitive.
64
Control Flow Analysis
Based upon graphical representation of the program process. In control flow analysis, the program graph has nodes, which represent a statement or segment possibly ending in an unresolved branch. The graph illustrates the flow of program control from one segment to another as illustrated through branches. The objective of control flow analysis is to determine potential problems in logic branches that might result in a loop condition or improper processing.
65
Conversion Testing
Validates the effectiveness of data conversion processes, including field-to-field mapping, and data translation.
66
Corrective Controls
Corrective controls assist individuals in the investigation and correction of causes of risk exposures that have been detected.
67
Correctness
The extent to which software is free from design and coding defects (i.e., fault-free). It is also the extent to which software meets its specified requirements and user objectives.
68
Cost of Quality (COQ)
Money spent beyond expected production costs (labor, materials, equipment) to ensure that the product the customer receives is a quality (defect free) product. The Cost of Quality includes prevention, appraisal, and failure costs.
69
COTS
Commercial Off the Shelf (COTS) software products that are ready-made and available for sale in the marketplace.
70
Coverage
A measure used to describe the degree to which the application under test (AUT) is tested by a particular test suite.
71
Coverage-Based Analysis
A metric used to show the logic covered during a test session, providing insight to the extent of testing. The simplest metric for coverage would be the number of computer statements executed during the test compared to the total number of statements in the program. To completely test the program structure, the test data chosen should cause the execution of all paths. Since this is not generally possible outside of unit test, general metrics have been developed which give a measure of the quality of test data based on the proximity to this ideal coverage. The metrics should take into consideration the existence of infeasible paths, which are those paths in the program that have been designed so that no data will cause the execution of those paths.
72
Critical Listening
The listener is performing an analysis of what the speaker said. This is most important when it is felt that the speaker is not in complete control of the situation, or does not know the complete facts of a situation.
73
Critical Success Factors
Critical Success Factors (CSFs) are those criteria or factors that must be present in a software application for it to be successful.
74
Customer
The individual or organization, internal or external to the producing organization that receives the product.
75
Customer’s/User’s of Software View of Quality
Fit for use.
76
Cyclomatic Complexity
The number of decision statements, plus one.
77
Damaging Event
Damaging Event is the materialization of a risk to an organization’s assets.
78
Data Dictionary
Provides the capability to create test data to test validation for the defined data elements. The test data generated is based upon the attributes defined for each data element. The test data will check both the normal variables for each data element as well as abnormal or error conditions for each data element.
79
Data Flow Analysis
In data flow analysis, we are interested in tracing the behavior of program variables as they are initialized and modified while the program executes.
80
DD(Decision-to- Decision) Path
A path of logical code sequence that begins at a decision statement or an entry and ends at a decision statement or an exit.
81
Debugging
The process of analyzing and correcting syntactic, logic, and other errors identified during testing.
82
Decision Analysis
This technique is used to structure decisions and to represent real- world problems by models that can be analyzed to gain insight and understanding. The elements of a decision model are the decisions, uncertain events, and values of outcomes.
83
Decision Coverage
A white-box testing technique that measures the number of, or percentage of, decision directions executed by the test case designed. 100% decision coverage would indicate that all decision directions had been executed at least once during testing. Alternatively, each logical path through the program can be tested. Often, paths through the program are grouped into a finite set of classes, and one path from each class is tested.
84
Decision Table
A tool for documenting the unique combinations of conditions and associated results in order to derive unique test cases for validation testing.
85
Decision Trees
This provides a graphical representation of the elements of a decision model.
86
Defect
Operationally, it is useful to work with two definitions of a defect:
• From the producer's viewpoint a defect is a product requirement that has not been met or a product attribute possessed by a product or a function performed by a product that is not in the statement of requirements that define the
product;
• From the customer's viewpoint a defect is anything that causes
customer dissatisfaction, whether in the statement of requirements or not.
A defect is an undesirable state. There are two types of defects: process and product.
87
Defect Management
Process to identify and record defect information whose primary goal is to prevent future defects.
88
Defect Tracking Tools
Tools for documenting defects as they are found during testing and for tracking their status through to resolution.
89
Deliverables
Any product or service produced by a process. Deliverables can be interim or external. Interim deliverables are produced within the process but never passed on to another process. External deliverables may be used by one or more processes. Deliverables serve as both inputs to and outputs from a process.
90
Design Level
The design decomposition of the software item (e.g., system, subsystem, program, or module).
91
Desk Checking
The most traditional means for analyzing a system or a program. Desk checking is conducted by the developer of a system or program. The process involves reviewing the complete product to ensure that it is structurally sound and that the standards and requirements have been met. This tool can also be used on artifacts created during analysis and design.
92
Detective Controls
Detective controls alert individuals involved in a process so that they are aware of a problem.
93
Discriminative Listening
Directed at selecting specific pieces of information and not the entire communication.
94
Do
Create the conditions and perform the necessary teaching and training to ensure everyone understands the objectives and the plan. (Plan-Do-Check-Act)
The procedures to be executed in a process. (Process Engineering)
95
Driver
Code that sets up an environment and calls a module for test. A driver causes the component under test to exercise the interfaces. As you move up the drivers are replaced with the actual components.
96
Dynamic Analysis
Analysis performed by executing the program code. Dynamic analysis executes or simulates a development phase product, and it detects errors by analyzing the response of a product to sets of input data.
97
Dynamic Assertion
A dynamic analysis technique that inserts into the program code assertions about the relationship between program variables. The truth of the assertions is determined as the program executes.
98
Ease of Use and Simplicity
These are functions of how easy it is to capture and use the measurement data.
99
Effectiveness
Effectiveness means that the testers completed their assigned responsibilities.
100
Efficiency
Efficiency is the amount of resources and time required to complete test responsibilities.
101
Empowerment
Giving people the knowledge, skills, and authority to act within their area of expertise to do the work and improve the process.
102
Entrance Criteria
Required conditions and standards for work product quality that must be present or met for entry into the next stage of the software development process.
103
Environmental Controls
Environmental controls are the means which management uses to manage the organization.
104
Equivalence Partitioning
The input domain of a system is partitioned into classes of representative values so that the number of test cases can be limited to one-per-class, which represents the minimum number of test cases that must be executed.
105
Error or Defect
A discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.
106
Error Guessing
Test data selection technique for picking values that seem likely to cause defects. This technique is based upon the theory that test cases and test data can be developed based on the intuition and experience of the tester.
107
Exhaustive Testing
Executing the program through all possible combinations of values for program variables.
108
Exit Criteria
Standards for work product quality, which block the promotion of incomplete or defective work products to subsequent stages of the software development process.
109
Exploratory Testing
The term “Exploratory Testing” was coined in 1983 by Dr. Cem Kaner. Dr. Kaner defines exploratory testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.”
110
Failure Costs
All costs associated with defective products that have been delivered to the user and/or moved into production. Failure costs can be classified as either “internal” failure costs or “external” failure costs.
111
File Comparison
Useful in identifying regression errors. A snapshot of the correct expected results must be saved so it can be used for later comparison.
112
Fitness for Use
Meets the needs of the customer/user.
113
Flowchart
Pictorial representations of data flow and computer logic. It is frequently easier to understand and assess the structure and logic of an application system by developing a flow chart than to attempt to understand narrative descriptions or verbal explanations. The flowcharts for systems are normally developed manually, while flowcharts of programs can be produced.
114
Force Field Analysis
A group technique used to identify both driving and restraining forces that influence a current situation.
115
Formal Analysis
Technique that uses rigorous mathematical techniques to analyze the algorithms of a solution for numerical properties, efficiency, and correctness.
116
FPA
Function Point Analysis a sizing method in which the program’s functionality is measured by the number of ways it must interact with the users.
117
Functional System Testing
Functional system testing ensures that the system requirements and specifications are achieved. The process involves creating test conditions for use in evaluating the correctness of the application.
118
Functional Testing
Application of test data derived from the specified functional requirements without regard to the final program structure.
119
Gap Analysis
This technique determines the difference between two variables. A gap analysis may show the difference between perceptions of importance and performance of risk management practices. The gap analysis may show discrepancies between what is and what needs to be done. Gap analysis shows how large the gap is and how far the leap is to cross it. It identifies the resources available to deal with the gap.
120
Happy Path
Generally used within the discussion of Use Cases, the happy path follows a single flow uninterrupted by errors or exceptions from beginning to end.
121
Heuristics
Experience-based techniques for problem solving, learning, and discovery.
122
Histogram
A graphical description of individually measured values in a data set that is organized according to the frequency or relative frequency of occurrence. A histogram illustrates the shape of the distribution of individual values in a data set along with information regarding the average and variation.
123
Incremental Model
The incremental model approach subdivides the requirements specifications into smaller buildable projects (or modules). Within each of those smaller requirements subsets, a development life cycle exists which includes the phases described in the Waterfall approach.
124
Incremental Testing
Incremental testing is a disciplined method of testing the interfaces between unit-tested programs as well as between system components. It involves adding unit-tested programs to a given module or component one by one, and testing each resultant combination.
125
Infeasible Path
A sequence of program statements that can never be executed.
126
Influence Diagrams
Provides a graphical representation of the elements of a decision model.
127
Inherent Risk
Inherent Risk is the risk to an organization in the absence of any actions management might take to alter either the risk’s likelihood or impact.
128
Inputs
Materials, services, or information needed from suppliers to make a process work, or build a product.
129
Inspection
A formal assessment of a work product conducted by one or more qualified independent reviewers to detect defects, violations of development standards, and other problems. Inspections involve authors only when specific questions concerning deliverables exist. An inspection identifies defects, but does not attempt to correct them. Authors take corrective actions and arrange follow-up reviews as needed.
130
Instrumentation
The insertion of additional code into a program to collect information about program behavior during program execution.
131
IntegrationTesting
This test begins after two or more programs or application components have been successfully unit tested. It is conducted by the development team to validate the technical quality or design of the application. It is the first level of testing which formally integrates a set of programs that communicate among themselves via messages or files (a client and its server(s), a string of batch programs, or a set of online modules within a dialogue or conversation.)
132
Invalid Input
Test data that lays outside the domain of the function the program represents.
133
ISO 29119
ISO 29119 is a set of standards for software testing that can be used within any software development life cycle or organization.
134
Iterative Model
The project is divided into small parts allowing the development team to demonstrate results earlier on in the process and obtain valuable feedback from system users.
135
Judgment
A decision made by individuals that is based on three criteria which are: fact, standards, and experience.
136
Keyword-Driven Testing
Keyword-driven testing, also known as table-driven testing or action word based testing, is a testing methodology whereby tests are driven wholly by data. Keyword-driven testing uses a table format, usually a spreadsheet, to define keywords or action words for each function that will be executed.
137
Leadership
The ability to lead, including inspiring others in a shared vision of what can be, taking risks, serving as a role model, reinforcing and rewarding the accomplishments of others, and helping others to act.
138
Life Cycle Testing
The process of verifying the consistency, completeness, and correctness of software at each stage of the development life cycle.
139
Management
A team or individuals who manage(s) resources at any level of the organization.
140
Mapping
Provides a picture of the use of instructions during the execution of a program. Specifically, it provides a frequency listing of source code statements showing both the number of times an instruction was executed and which instructions were not executed. Mapping can be used to optimize source code by identifying the frequently used instructions. It can also be used to determine unused code, which can demonstrate code, which has not been tested, code that is infrequently used, or code that is non-entrant.
141
Mean
A value derived by adding several quantities and dividing the sum by the number of these quantities..
142
Measures
A unit to determine the dimensions, quantity, or capacity (e.g., lines of code are a measure of software size).
143
Mentoring
Mentoring is helping or supporting an individual in a non- supervisory capacity. Mentors can be peers, subordinates, or superiors. What is important is that the mentor does not have a managerial relationship to the mentored individual when performing the task of mentoring.
144
Metric
A software metric is a mathematical number that shows a relationship between two measures.
145
Metric-Based Test Data Generation
The process of generating test sets for structural testing based on use of complexity or coverage metrics.
146
Mission
A customer-oriented statement of purpose for a unit or a team.
147
Model Animation
Model animation verifies that early models can handle the various types of events found in production data. This is verified by “running” actual production transactions through the models as if they were operational systems.
148
Model Balancing
Model balancing relies on the complementary relationships between the various models used in structured analysis (event, process, data) to ensure that modeling rules/standards have been followed; this ensures that these complementary views are consistent and complete.
149
Model-Based Testing
Test cases are based on a simple model of the application. Generally, models are used to represent the desired behavior of the application being tested. The behavioral model of the application is derived from the application requirements and specification.
150
Moderator
Manages the inspection process, is accountable for the effectiveness of the inspection, and must be impartial.
151
Modified Condition Decision Coverage
A compromise which requires fewer test cases than Branch Condition Combination Coverage.
152
Motivation
Getting individuals to do work tasks they do not want to do or to perform those work tasks in a more efficient or effective manner.
153
Mutation Analysis
A method to determine test set thoroughness by measuring the extent to which a test set can discriminate the program from slight variants (i.e., mutants) of it.
154
Network Analyzers
A tool used to assist in detecting and diagnosing network problems.
155
Non-functional Testing
Non-functional testing validates that the system quality attributes and characteristics have been considered during the development process. Non-functional testing is the testing of a software application for its non-functional requirements.
156
Objective Measures
An objective measure is a measure that can be obtained by counting.
157
Open Source
Open Source: “pertaining to or denoting software whose source code is available free of charge to the public to use, copy, modify, sublicense, or distribute.”
158
Optimum Point of Testing
The point where the value received from testing no longer exceeds the cost of testing.
159
Oracle
A (typically automated) mechanism or principle by which a problem in the software can be recognized. For example, automated test oracles have value in load testing software (by signing on to an application with hundreds or thousands of instances simultaneously), or in checking for intermittent errors in software.
160
Outputs
Products, services, or information supplied to meet customer needs.
161
Pair-Wise
Pair-wise testing (also known as all-pairs testing) is a combinatorial method used to generate the least number of test cases necessary to test each pair of input parameters to a system.
162
Parametric Modeling
A mathematical model based on known parameters to predict cost/ schedule of a test project. The parameters in the model can vary based on the type of project.
163
Pareto Analysis
The Pareto Principle states that only a “vital few” factors are responsible for producing most of the problems. This principle can be applied to risk analysis to the extent that a great majority of problems (80%) are produced by a few causes (20%). If we correct these few key causes, we will have a greater probability of success.
164
Pareto Charts
A special type of bar chart to view the causes of a problem in order of severity: largest to smallest based on the 80/20 premise.
165
Pass/Fail Criteria
Decision rules used to determine whether a software item or feature passes or fails a test.
166
Passive Risk
Passive Risk is that which is inherent in inaction. For example, the choice not to update an existing product to compete with others in the marketplace.
167
Path Expressions
A sequence of edges from the program graph that represents a path through the program.
168
Path Testing
A test method satisfying the coverage criteria that each logical path through the program be tested. Often, paths through the program are grouped into a finite set of classes and one path from each class is tested.
169
Performance Test
Validates that both the online response time and batch run times meet the defined performance requirements.
170
Performance/ Timing Analyzer
A tool to measure system performance.
171
Phase(orStage) Containment
A method of control put in place within each stage of the development process to promote error identification and resolution so that defects are not propagated downstream to subsequent stages of the development process.
172
Plan
Define your objective and determine the conditions and methods required to achieve your objective. Clearly describe the goals and policies needed to achieve the objective at this stage. (Plan-Do- Check-Act)
173
Plan-Do-Check- Act model
One of the best known process improvement models is the Plan- Do-Check-Act model for continuous process improvement.
174
Planning Poker
In Agile Development, Planning Poker is a consensus-based technique designed to remove the cognitive bias of anchoring.
175
Policy
Managerial desires and intents concerning either process (intended objectives) or products (desired attributes).
176
Population Analysis
Analyzes production data to identify, independent from the specifications, the types and frequency of data that the system will have to process/produce. This verifies that the specs can handle types and frequency of actual data and can be used to create validation tests.
177
Post Conditions
A list of conditions, if any, which will be true after the Use Case finished successfully.
178
Pre-Conditions
A list of conditions, if any, which must be met before the Use Case can be properly executed.
179
Prevention Costs
Resources required to prevent defects and to do the job right the first time. These normally require up-front expenditures for benefits that will be derived later. This category includes money spent on establishing methods and procedures, training workers, acquiring tools, and planning for quality. Prevention resources are spent before the product is actually built.
180
Preventive Controls
Preventive controls will stop incorrect processing from occurring.
181
Problem-Solving
Cooperative mode – Attempts to satisfy the interests of both parties. In terms of process, this is generally accomplished through identification of “interests” and freeing the process from initial positions. Once interests are identified, the process moves into a phase of generating creative alternatives designed to satisfy identified interests (criteria).
182
Procedure
Describe how work must be done and how methods, tools, techniques, and people are applied to perform a process. There are Do procedures and Check procedures. Procedures indicate the “best way” to meet standards.
183
Process
The process or set of processes used by an organization or project to plan, manage, execute, monitor, control, and improve its software related activities. A set of activities and tasks. A statement of purpose and an essential set of practices (activities) that address that purpose.
184
Process Improvement
To change a process to make the process produce a given product faster, more economically, or of higher quality.
185
Process Risk
Process risk is the activities such as planning, resourcing, tracking, quality assurance, and configuration management.
186
Producer/Author
Gathers and distributes materials, provides product overview, is available for clarification, should contribute as an inspector, and must not be defensive.
187
Producer’s View of Quality
Meeting requirements.
188
Product
The output of a process: the work product. There are three useful classes of products: Manufactured Products (standard and custom), Administrative/Information Products (invoices, letters, etc.), and Service Products (physical, intellectual, physiological, and psychological). A statement of requirements defines products; one or more people working in a process produce them.
189
Production Costs
The cost of producing a product. Production costs, as currently reported, consist of (at least) two parts; actual production or right- the-first time costs (RFT) plus the Cost of Quality (COQ). RFT costs include labor, materials, and equipment needed to provide the product correctly the first time.
190
Productivity
The ratio of the output of a process to the input, usually measured in the same units. It is frequently useful to compare the value added to a product by a process, to the value of the input resources required (using fair market values for both input and output).
191
Proofof Correctness
The use of mathematical logic techniques to show that a relationship between program variables assumed true at program entry implies that another relationship between program variables holds at program exit.
192
Quality
A product is a quality product if it is defect free. To the producer, a product is a quality product if it meets or conforms to the statement of requirements that defines the product. This statement is usually shortened to: quality means meets requirements. From a customer’s perspective, quality means “fit for use.”
193
QualityAssurance (QA)
The set of support activities (including facilitation, training, measurement, and analysis) needed to provide adequate confidence that processes are established and continuously improved to produce products that meet specifications and are fit for use.
194
Quality Control (QC)
The process by which product quality is compared with applicable standards, and the action taken when nonconformance is detected. Its focus is defect detection and removal. This is a line function; that is, the performance of these tasks is the responsibility of the people working within the process.
195
Quality Improvement
To change a production process so that the rate at which defective products (defects) are produced is reduced.
196
RAD Model
A variant of prototyping, is another form of iterative development. The RAD model is designed to build and deliver application prototypes to the client while in the iterative process.
197
Reader (Inspections)
Must understand the material, paraphrases the material during the inspection, and sets the inspection pace.
198
Recorder (Inspections)
Must understand error classification, is not the meeting stenographer (captures enough detail for the project team to go forward to resolve errors), classifies errors as detected, and reviews the error list at the end of the meeting.
199
Recovery Test
Evaluates the contingency features built into the application for handling interruptions and for returning to specific points in the application processing cycle, including checkpoints, backups, restores, and restarts. This test also assures that disaster recovery is possible.
200
Regression Analysis
A means of showing the relationship between two variables. Regression analysis will provide two pieces of information. The first is a graphic showing the relationship between two variables. Second, it will show the correlation, or how closely related the two variables are.
201
Regression Testing
Testing of a previously verified program or application following program modification for extension or correction to ensure no new defects have been introduced.
202
Reliability
This refers to the consistency of measurement. Two different individuals take the same measurement and get the same result. The measure is reliable.
203
Requirement
A formal statement of:
1. An attribute to be possessed by the product or a function to be performed by the product
2. The performance standard for the attribute or function; and/or
3. The measuring process to be used in verifying that the standard has been met.
204
Requirements- Based Testing
RBT focuses on the quality of the Requirements Specification and requires testing throughout the development life cycle. Specifically, RBT performs static tests with the purpose of verifying that the requirements meet acceptable standards defined as: complete, correct, precise, unambiguous, and clear, consistent, relevant, testable, and traceable.
205
Residual Risk
Residual Risk is the risk that remains after management responds to the identified risks.
206
Reuse Model
The premise behind the Reuse Model is that systems should be built using existing components, as opposed to custom-building new components. The Reuse Model is clearly suited to Object-Oriented computing environments, which have become one of the premiere technologies in today’s system development industry.
207
Risk
Risk can be measured by performing risk analysis.
208
Risk Acceptance
Risk Acceptance is the amount of risk exposure that is acceptable to the project and the company and can be either active or passive.
209
Risk Analysis
Risk Analysis is an analysis of an organization’s information resources, its existing controls, and its organization and computer system or application system vulnerabilities. It combines the loss potential for each resource or combination of resources with an estimated rate of occurrence to establish a potential level of damage in dollars or other assets.
210
Risk Appetite
Risk Appetite defines the amount of loss management is willing to accept for a given risk.
211
Risk Assessment
Risk Assessment is an examination of a project to identify areas of potential risk. The assessment can be broken down into analysis, identification, and prioritization.
212
Risk Avoidance
Risk avoidance is a strategy for risk resolution to eliminate the risk altogether. Avoidance is a strategy to use when a lose-lose situation is likely.
213
Risk Event
Risk Event is a future occurrence that may affect the project for better or worse. The positive aspect is that these events will help you identify opportunities for improvement while the negative aspect will be the realization of threats and losses.
214
Risk Exposure
Risk Exposure is the measure that determines the probability of likelihood of the event times the loss that could occur.
215
Risk Identification
Risk Identification is a method used to find risks before they become problems. The risk identification process transforms issues and concerns about a project into tangible risks, which can be described and measured.
216
RiskLeverage
Risk leverage is a measure of the relative cost-benefit of performing various candidate risk resolution activities.
217
Risk Management
Risk Management is the process required to identify, quantify, respond to, and control project, process, and product risk.
218
Risk Mitigation
Risk Mitigation is the action taken to reduce threats and/or vulnerabilities.
219
Risk Protection
Risk protection is a strategy to employ redundancy to mitigate (reduce the probability and/or consequence of) a risk.
220
Risk Reduction
Risk reduction is a strategy to decrease risk through mitigation, prevention, or anticipation. Decreasing either the probability of the risk occurrence or the consequence when the risk is realized reduces risk. Reduction is a strategy to use when risk leverage exists.
221
Risk Reserves
A risk reserve is a strategy to use contingency funds and built-in schedule slack when uncertainty exists in cost or time.
222
Risk Transfer
Risk transfer is a strategy to shift the risk to another person, group, or organization and is used when another group has control.
223
Risk-Based Testing
Risk-based testing prioritizes the features and functions to be tested based on the likelihood of failure and the impact of a failure should it occur.
224
Run Chart
A run chart is a graph of data (observation) in chronological order displaying shifts or trends in the central tendency (average). The data represents measures, counts or percentages of outputs from a process (products or services).
225
Sad Path
A path through the application which does not arrive at the desired result.
226
Scatter Plot Diagram
A graph designed to show whether there is a relationship between two changing variables.
227
Scenario Testing
Testing based on a real-world scenario of how the system is supposed to act.
228
Scope of Testing
The scope of testing is the extensiveness of the test process. A narrow scope may be limited to determining whether or not the software specifications were correctly implemented. The scope broadens as more responsibilities are assigned to software testers.
229
Selective Regression Testing
The process of testing only those sections of a program where the tester’s analysis indicates programming changes have taken place and the related components.
230
Self-Validating Code
Code that makes an explicit attempt to determine its own correctness and to proceed accordingly.
231
SLOC
Source Lines of Code
232
Smoothing
An unassertive approach – Both parties neglect the concerns involved by sidestepping the issue, postponing the conflict, or choosing not to deal with it.
233
Soft Skills
Soft skills are defined as the personal attributes which enable an individual to interact effectively and harmoniously with other people.
234
Software Feature
A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).
235
Software Item
Source code, object code, job control code, control data, or a collection of these.
236
Software Quality Criteria
An attribute of a quality factor that is related to software development.
237
Software Quality Factors
Software quality factors are attributes of the software that, if they are wanted and not present, pose a risk to the success of the software and thus constitute a business risk.
238
Software Quality Gaps
The first gap is the producer gap. It is the gap between what was specified to be delivered, meaning the documented requirements and internal IT standards, and what was actually delivered. The second gap is between what the producer actually delivered compared to what the customer expected.
239
Special Causes of Variation
Variation not typically present in the process. They occur because of special or unique circumstances.
240
Special Test Data
Test data based on input values that are likely to require special handling by the program.
241
Spiral Model
Model designed to include the best features from the Waterfall and Prototyping, and introduces a new component risk-assessment.
242
Standardize
Procedures that are implemented to ensure that the output of a process is maintained at a desired level.
243
Standardizer
Must know IT standards & procedures, ensures standards are met and procedures are followed, meets with project leader/manager, and ensures entrance criteria are met (product is ready for review).
244
Standards
The measure used to evaluate products and identify nonconformance. The basis upon which adherence to policies is measured.
245
Statement of Requirements
The exhaustive list of requirements that define a product. Note that the statement of requirements should document requirements proposed and rejected (including the reason for the rejection) during the requirement determination process.
246
Statement Testing
A test method that executes each statement in a program at least once during program testing.
247
Static Analysis
Analysis of a program that is performed without executing the program. It may be applied to the requirements, design, or code.
248
Statistical Process Control
The use of statistical techniques and tools to measure an ongoing process for change or stability.
249
Story Points
Measurement of a feature’s size relative to other features. Story Points are an analogous method in that the objective is to compare the sizes of features to other stories and reference stories.
250
Stress Testing
This test subjects a system, or components of a system, to varying environmental conditions that defy normal expectations. For example, high transaction volume, large database size or restart/ recovery circumstances. The intention of stress testing is to identify constraints and to ensure that there are no performance problems.
251
Structural Analysis
Structural analysis is a technique used by developers to define unit test cases. Structural analysis usually involves path and condition coverage.
252
Structural System Testing
Structural System Testing is designed to verify that the developed system and programs work. The objective is to ensure that the product designed is structurally sound and will function correctly.
253
Structural Testing
A testing method in which the test data is derived solely from the program structure.
254
Stub
Special code segments that when invoked by a code segment under testing, simulate the behavior of designed and specified modules not yet constructed.
255
Subjective Measures
A person’s perception of a product or activity.
256
Supplier
An individual or organization that supplies inputs needed to generate a product, service, or information to a customer.
257
System Boundary Diagram
A system boundary diagram depicts the interfaces between the software under test and the individuals, systems, and other interfaces. These interfaces or external agents are referred to as “actors.” The purpose of the system boundary diagram is to establish the scope of the system and to identify the actors (i.e., the interfaces) that need to be developed. (Use Cases)
258
System Test
The entire system is tested to verify that all functional, information, structural and quality requirements have been met. A predetermined combination of tests is designed that, when executed successfully, satisfy management that the system meets specifications. System testing verifies the functional quality of the system in addition to all external interfaces, manual procedures, restart and recovery, and human-computer interfaces. It also verifies that interfaces between the application and the open environment work correctly, that JCL functions correctly, and that the application functions appropriately with the Database Management System, Operations environment, and any communications systems.
259
Test
1. A set of one or more test cases.
| 2. A set of one or more test cases and procedures.
260
TestCase Generator
A software tool that creates test cases from requirements specifications. Cases generated this way ensure that 100% of the functionality specified is tested.
261
Test Case Specification
An individual test condition, executed as part of a larger test that contributes to the test’s objectives. Test cases document the input, expected results, and execution conditions of a given test item. Test cases are broken down into one or more detailed test scripts and test data conditions for execution.
262
Test Cycle
Test cases are grouped into manageable (and schedulable) units called test cycles. Grouping is according to the relation of objectives to one another, timing requirements, and on the best way to expedite defect detection during the testing event. Often test cycles are linked with execution of a batch process.
263
Test Data
Data points required to test most applications; one set of test data to confirm the expected results (data along the happy path), a second set to verify the software behaves correctly for invalid input data (alternate paths or sad path), and finally data intended to force incorrect processing (e.g., crash the application).
264
Test Data Management
A defined strategy for the development, use, maintenance, and ultimately destruction of test data.
265
Test Data Set
Set of input elements used in the testing process.
266
Test Design Specification
A document that specifies the details of the test approach for a software feature or a combination of features and identifies the associated tests.
267
Test Driver
A program that directs the execution of another program against a collection of test data sets. Usually, the test driver also records and organizes the output generated as the tests are run.
268
Test Environment
The Test Environment can be defined as a collection of hardware and software components configured in such a way as to closely mirror the production environment. The Test Environment must replicate or simulate the actual production environment as closely as possible.
269
Test Harness
A collection of test drivers and test stubs
270
Test Incident Report
A document describing any event during the testing process that requires investigation.
271
Test Item
A software item that is an object of testing.
272
Test Item Transmittal Report
A document that identifies test items and includes status and location information.
273
Test Labs
Test labs are another manifestation of the test environment which is more typically viewed as a brick and mortar environment (designated, separated, physical location).
274
Test Log
A chronological record of relevant details about the execution of tests.
275
Test Plan
A document describing the intended scope, approach, resources, and schedule of testing activities. It identifies test items, the features to be tested, the testing tasks, the personnel performing each task, and any risks requiring contingency planning.
276
Test Point Analysis (TPA)
Calculates test effort based on size (derived from FPA), strategy (as defined by system components and quality characteristics to be tested and the coverage of testing), and productivity (the amount of time needed to perform a given volume of testing work).
277
Test Procedure Specification
A document specifying a sequence of actions for the execution of a test.
278
Test Scripts
A specific order of actions that should be performed during a test session. The script also contains expected results. Test scripts may be manually prepared using paper forms, or may be automated using capture/playback tools or other kinds of automated scripting tools.
279
Test Stubs
Simulates a called routine so that the calling routine’s functions can be tested. A test harness (or driver) simulates a calling component or external environment, providing input to the called routine, initiating the routine, and evaluating or displaying output returned.
280
Test Suite Manager
A tool that allows testers to organize test scripts by function or other grouping.
281
TestSummary Report
A document that describes testing activities and results and evaluates the corresponding test items.
282
Testing
1. The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.
2. The process of analyzing a software item to detect the differences between existing and required conditions, i.e. bugs, and to evaluate the features of the software items. See: dynamic analysis, static analysis, software engineering.
283
Testing Process Assessment
Thoughtful analysis of testing process results, and then taking corrective action on the identified weaknesses.
284
Testing Schools of Thought
A school of thought simply defined as “a belief (or system of beliefs) shared by a group.” Generally accepted test schools of that are: the Analytical School, the Factory School, the Quality (control) School, Context-driven School, and the Agile School.
285
Therapeutic Listening
The listener is sympathetic to the speaker's point of view. During this type of listening, the listener will show a lot of empathy for the speaker's situation.
286
Thread Testing
This test technique, which is often used during early integration testing, demonstrates key functional capabilities by testing a string of units that accomplish a specific function in the application.
287
Threat
Threat is something capable of exploiting a vulnerability in the security of a computer system or application. Threats include both hazards (any source of potential damage or harm) and events that can trigger vulnerabilities.
288
Threshold Values
Threshold values define the inception of risk occurrence. Predefined thresholds act as a warning level to indicate the need to execute the risk action plan.
289
Timeliness
This refers to whether the data was reported in sufficient time to impact the decisions needed to manage effectively
290
TMMi
A process improvement model for software testing. The Test Maturity Model integration (TMMi) is a detailed model for test process improvement and is positioned as being complementary to the CMMI.
291
Tools
Any resources that are not consumed in converting the input into the deliverable.
292
Top-Down
Begin testing from the top of the module hierarchy and work down to the bottom using interim stubs to simulate lower interfacing modules or programs. Modules are added in descending hierarchical order.
293
Top-Down Estimation
Generate an overall estimate based on initial knowledge. It is used at the initial stages of the project and is based on similar projects. Past data plays an important role in this form of estimation.
294
Tracing
A process that follows the flow of computer logic at execution time. Tracing demonstrates the sequence of instructions or a path followed in accomplishing a given task. The two main types of trace are tracing instructions in computer programs as they are executed, or tracing the path through a database to locate predetermined pieces of information.
295
Triangulation
Story Triangulation is a form of estimation by analogy. After the first few estimates have been made, they are verified by relating them to each other. (Agile methods)
296
Triggers
A device used to activate, deactivate, or suspend a risk action plan. Triggers can be set by the project tracking system.
297
Use Case Points (UCP)
A derivative of the Use Cases method is the estimation technique known as Use Case Points. Use Case Points are similar to Function Points and are used to estimate the size of a project.
298
Unit Test
Testing individual programs, modules, or components to demonstrate that the work package executes per specification, and validate the design and technical quality of the application. The focus is on ensuring that the detailed logic within the component is accurate and reliable according to pre-determined specifications. Testing stubs or drivers may be used to simulate behavior of interfacing modules.
299
Usability Test
The purpose of this event is to review the application user interface and other human factors of the application with the people who will be using the application. This is to ensure that the design (layout and sequence, etc.) enables the business functions to be executed as easily and intuitively as possible. This review includes assuring that the user interface adheres to documented User Interface standards, and should be conducted early in the design stage of development. Ideally, an application prototype is used to walk the client group through various business scenarios, although paper copies of screens, windows, menus, and reports can be used
300
Use Case
A Use Case is a technique for capturing the functional requirements of systems through the interaction between an Actor and the System.
301
User
The customer that actually uses the product received.
302
User Acceptance Testing
User Acceptance Testing (UAT) is conducted to ensure that the system meets the needs of the organization and the end user/ customer. It validates that the system will work as intended by the user in the real world, and is based on real world business scenarios, not system requirements. Essentially, this test validates that the right system was built.
303
User Story
A short description of something that a customer will do when they use an application (software system). The User Story is focused on the value or result a customer would receive from doing whatever it is the application does.
304
Validation
Validation physically ensures that the system operates according to the desired specifications by executing the system functions through a series of tests that can be observed and evaluated
305
Validity
This indicates the degree to which a measure actually measures what it was intended to measure.
306
Values (Sociology)
The ideals, customs, instructions, etc., of a society toward which the people have an affective regard. These values may be positive, as cleanliness, freedom, or education, or negative, as cruelty, crime, or blasphemy. Any object or quality desired as a means or as an end in itself.
307
Verification
The process of determining whether the products of a given phase of the software development cycle fulfill the requirements established during the previous phase.
The act of reviewing, inspecting, testing, checking, auditing, or otherwise establishing and documenting whether items, processes, services, or documents conform to specified requirements.
308
Virtualization
The concept of virtualization (within the IT space) usually refers to running multiple operating systems on a single machine.
309
Vision
A vision is a statement that describes the desired future state of a unit.
310
V-Model
The V-Model is considered an extension of the Waterfall Model. The purpose of the “V” shape is to demonstrate the relationships between each phase of specification development and its associated dynamic testing phase.
311
Vulnerability
Vulnerability is a design, implementation, or operations flaw that may be exploited by a threat. The flaw causes the computer system or application to operate in a fashion different from its published specifications and results in destruction or misuse of equipment or data.
312
Walkthroughs
An informal review (static) testing process in which the author “walks through” the deliverable with the review team looking for defects.
313
Waterfall
A development model in which progress is seen as flowing steadily downwards through the phases of conception, initiation, requirements, design, construction, dynamic testing, production/ implementation, and maintenance.
314
WBS
A Work Breakdown Structure (WBS) groups project components into deliverable and accountable pieces.
315
White-Box Testing
A testing technique that assumes that the path of the logic in a program unit or component is known. White-box testing usually consists of testing paths, branch by branch, to produce predictable results. This technique is usually used during tests executed by the development team, such as Unit or Component testing,
316
Wideband Delphi
A method for the controlled exchange of information within a group. It provides a formal, structured procedure for the exchange of opinion, which means that it can be used for estimating.
317
Withdrawal
Conflict is resolved when one party attempts to satisfy the concerns of others by neglecting its own interests or goals. This is a lose-win approach.
318
Workbench
The objective of the workbench is to produce the defined output products (deliverables) in a defect-free manner. The procedures and standards established for each workbench are designed to assist in this objective.
