WGU - C857 - Software Quality Assurance (definitions)

Symbol for OR function on Cause-Effect Graph

"V"

Usability Testing

A black-box testing technique that involves actual users or customers of the product and that seeks to verify an implementation's approach works for the user base. Test should be created by establishing practical, real-world, repeatable exercises for each user to conduct.

Test User Select

A complete usability testing protocol usually involves multiple tests from the same users as well as tests from multiple users

Equivalence Partitioning

Defines condition or error classes to help reduce the number of finite tests

Error Guessing (process)

Enumerate a list of possible errors or error-prone situations and then write test cases based on the list

Regression Testing

Performed after making a functional improvement or repair to a program, its purpose is to determine whether the change has regressed other aspects of the program.

Cause-effect graphing

Produces Boolean graphical representations of potential test case results to aid in selecting efficient and complete test cases

Error Guessing

Produces test cases based on intuitive and expert knowledge of test team members to define potential software errors to facilitate efficient test case design

Bug Record

Provide clear and complete information about a bug, including details about the environment and specific steps that the developer can use to reproduce the issue

main()

Provides the entry point into the application

Hallway Intercept

Testing that involves random users for a software with a general target market

White-Box Testing

Testing that is concerned with the degree to which test cases exercise or cover the logic (source code) of the program

walkthroughs

a less formal verification technique in which life-cycle work products are examined by a group of peers for the purpose of finding defects, omissions, and contradictions; normally led by the author or the producer of the material being reviewed.

statement coverage

a measure of whether each executable statement is encountered

block coverage

a measure of whether each executable statement is encountered, like statement coverage except that the unit of code measured is each sequence of non-branching statements

structured walkthroughs

a more formal verification technique than a walkthrough, using many of the concepts/objectives of an inspection

unit testing

a process of testing the individual components, subsystems, hardware components such as programmable logic arrays, and software components such as subprograms, subroutines, or procedures; focuses on white box or glass box testing and on test statements, branches, and paths through discrete pieces of code.

Capability Maturity Model Integration (CMMI)

a proven set of global best practices that drives business performance through building and benchmarking key capabilities - project management, quality management, and engineering all glued together by process management

testing

a quality control function in that it is used to verify the functionality and performance of life-cycle work products or product components as they move through the product life cycle

Code Inspections

a set of procedures and error-detection techniques for group code reading

Scrum

a short team meeting to discuss progress and work; common across all methodologies

Peer Ratings

a technique of evaluating anonymous programs in terms of their overall quality, maintainability, extensibility, usability, and clarity; the purpose of this techniques to provide programmer self-evaluation

Equivalence Partitioning (Equivalence Classes)

a testing technique in which a set of test conditions is divided into groups or sets that can be considered the same

Debugging

a two-step process that begins with determination of the nature and location of the suspected error and then fixing it

system validation

an end-to-end process that is needed to ensure that the completed and integrated system will operate as needed in the environment for which it was intended; a measure of customer satisfaction, given the customer's operational need and profile

review

an evaluation of a life-cycle work product or project status to determine if there are any deviations from planned results and to recommend improvement

Buddy Check

an informal verification technique in which the life-cycle work product is examined by the author and one other person

buddy check

an informal verification technique in which the life-cycle work product is examined by the author and one other person

anomaly, defect

any condition that deviates from expectations based on requirements, specification, design documents, standards, plans, and so on, or from someone's experiences

User Recall

how much of what a user learns about software operation is retained from session to session

peer reviews

human-based testing rather than computer-based testing

And function

if ( a and b = 1 ) { c = 1 } else { c = 0 }

Not function

if (a = 1) { b = 0 } else { b = 1 }

Identity function

if (a = 1) { b = 1 } else { b = 0 }

Or function

if (a or b or c = 1) { d = 1 } else { d = 0 }

Symbol for AND function on Cause-Effect Graph

inverted "V"

Project Manager Review

normally, a weekly project with the development staff called by the Project manager

Symbol for Identity function on Cause-Effect Graph

single path

circulation review

taking on the attributes of both buddy checks and walkthroughs, the are either formal or informal reviews in which the life-cycle work product is circulated to each reviewer who attaches comments, questions, and recommendations directly on the life-cycle work product or places them in a separate document.

Component Testing

tests the interactive software parts for reasonable selection and user feedback

bench testing

the insertion of a product component into a test loop where all of the variables can be independently controlled, measured, and recorded

condition coverage

the measure of the true or false outcome of each Boolean subexpression; similar to decision coverage, but has better sensitivity to the control flow

decision coverage

the measure of whether Boolean expressions tested in control structures are evaluated to both true and false

path coverage

the measure of whether each of the possible paths in each function has been followed

multiple condition coverage

the measure of whether every possible combination of Boolean subexpression occurs; requires very thorough testing in languages with short-circuit operators

Test Coverage Analysis

the process of finding areas of a program not exercised by a set of test cases, creating additional test cases to increase coverage, and determining a quantitative measure of code coverage that serves as an indirect measure of quality

Integration Testing

verify that separate systems can work together passing data back and forth correctly

Symbol for NOT function on Cause-Effect Graph

zigzag path

Debugging by Brute Force

A popular method of debugging that requires little thought, but that is inefficient and generally unsuccessful. Includes debugging in three categories: storage dump, print statements, automated debugging tools.

Think-Aloud Protocol

A procedure in which participants are asked to say out loud what they are thinking while performing the assigned software testing tasks.

Circulation Reviews

A review that takes on attributes of both a buddy check and a walkthrough; they can be informal or formal; the life-cycle product is passed around to each reviewer who review it and either attaches comments, questions, and recommendations directly on the life-cycle work product or places them into a separate document.

Agile Development

A software development methodology that delivers functionality in rapid iterations, measured in weeks, requiring frequent communication, development, testing, and delivery; that is customer-centric; and that welcomes change during the process.

Extreme Programming

A software process that helps developers create high-quality code rapidly

Non-Incremental (Big-Bang) Testing

A way of Integration testing in which you test each module independently

Incremental Testing

A way of integration testing in which first you test each module of the software individually, then continue testing by adding another module to it, then another, etc. This can be done either top-down, bottom-up, or sandwich.

checkArgs()

Asserts that the input value is a positive integer

CMMI

Capability Maturity Model Integration

primeCheck()

Checks the input value against a calculated list of numbers divisible only by itself and 1

assertFalse()

Checks whether the parameter supplied causes the method to return an incorrect Boolean value

XP Testing

Continuous unit testing comprises the bulk of the testing effort although acceptance testing also falls under this principle.

XP Planning

Identifying your customer's application requirements and designing user (or case) stories that meet them.

Logic (Statement) Coverage Testing (WBT)

If tester backs completely away from path testing, it may seem that a worthy goal would be to execute every statement in the program at least once. (Weak criterion)

Debugging by Induction

The use of clues (i.e. symptoms of the error and/or the results of one or more test cases) and relationships among the clues to determine where the error lies.

Debugging by Testing

The use of test cases specifically for debugging, to cover only a single condition or a few conditions for scrutiny.

Debugging by Deduction

The use of the processes of elimination and refinement to debug a program.

Boundary Value Analysis

A black box test design technique in which test cases are designed based on boundary values, those situations directly on, above, and beneath the edges of input and output equivalence classes.

Walkthrough

a less formal verification technique in which life-cycle work products are examined by a group of peers for the purpose of finding defects, omission, and contradictions; typically led by the author of the work

Milestone Review

Represent meaningful points in the project's schedule and are documented in the project management plan, tracked, and reviewed.

System Testing

Testing meant to compare the system or program to its original objectives, NOT testing the functions of the complete system or program (as Function Testing); Considered Black-Box Testing

Installation Testing

Testing meant to find errors during the installation process.; Performed by the organization that produced the system.

Remote User Testing

Testing conducted by the user a the user's business where the software may ultimately be applied

Extreme Unit Testing

Testing in which all code modules must have primary tests before coding begins, and these primary tests must be defined and created before coding the module.

Decision (Branch) Coverage Testing (WBT)

Testing in which one must write enough test cases that each decision has a true and a false outcome at least once.

Condition Coverage (WBT)

Testing in which one writes enough test cases to ensure that each condition in a decision takes on all possible outcomes at least once.

Multiple Condition Coverage (WBT)

Testing in which there are sufficient test cases such that all possible combinations of condition outcomes in each decision and all points of entry are invoked at least once.

Decision/Condition Coverage (WBT)

Testing in which there are sufficient test cases such that each condition in a decision takes on all possible outcomes at least once, each decision takes on all possible outcomes at least once, and each point of entry is invoked at least once.

Extreme Acceptance Testing

Testing which determines whether the application meets its functional and usable requirements, and which is created by the customers during the design/planning phases.

Module (Unit) Testing

Testing which focuses on testing smaller units of the program first, rather than initially testing the whole program

Systems Testing

Testing which measures and determines what the system capabilities are and ends when the system capabilities have been measured and enough of the problems have been corrected to have confidence that the acceptance is ready to executed

Black-Box Testing

Testing without concern about the internal behavior and structure of the program, instead concentrating on finding circumstances in which the program does not behave according to its specifications

Boundary value analysis

Tests each edge condition of an equivalence class (output and input)

Logic Coverage

Tests that exercise all decision point outcomes at least once, and ensure that all statements or entry points are executed at least once.

Automated Testing

Tests which provide the immediate feedback required by rapid development

Model (Unit) Test-Case Design (WBT)

The design of a test based on a specification for the module (defining the module's input and output parameters and its function) and the module's source code.

Error Analysis

The examination of the exact location of the error, the developer of the code, the preventive measures taken to avoid those errors in the future, etc.

Function Testing

The process of attempting to find discrepancies between the program and the external specification.

Acceptance Testing

The process of comparing the program to its initial requirements and the current needs of its end users; Performed by the program's customer or end user and normally is not considered the responsibility of the development organization

Debugging by Backtracking

The process of stepping backwards through the logic of a program until the programmer finds the point at which the logic went astray.

Inspection Team

Usually consists of four people: moderator, programmer, designer, test specialist

Cause-Effect Graphing

a black-box testing technique that aids in selecting, in a systematic way, a high-yield set of test cases and that has the benefit of pointing out incompleteness and ambiguities in the specification.

technical review

a formal team evaluation of a life-cycle work product to identify any discrepancies from specifications and standards, determine its suitability for use, and provide recommendations after the examination of various alternatives

Inspections

a formal verification technique in which life-cycle work products are examined in detail by a group of peers for the explicit purpose of detecting and identifying defects

inspections

a formal verification technique in which life-cycle work products are examined in detail by a group of peers for the explicit purpose of detecting and identifying defects; author cannot act as the leader or as the moderator