The document discusses questions and answers related to the ISTQB Advanced Level Certification exam. It provides definitions and explanations of key testing concepts such as regression testing, error frequency reports, adequacy criteria, limitations of testing, fault seeding, mutation analysis, conditions for faults to cause failures, symbolic analysis, specification oriented testing, and input domain testing.

1. ISTQB Advanced Level Certification – Study Guide (Part 3)
Prior to appearing for exam for ISTQB Advanced Level certification, it is wise to quickly brush up
your knowledge by reviewing the following questions – answers that are extremely important from
the examination point of view.
Q. 21: What is the underlying objective of Regression Testing?
Retesting the affected function is necessary after the change is incorporated since as many as 20
percent of all corrections result in additional errors. Frequently, additional functions will need to be
tested to ensure that no latent defects were induced by the correction, one method of resolution
would be to treat them as new errors and initiate a new error report. The description of regression
testing should include:
# A list of test paragraphs/objectives retested
# The version of software used to perform regression test
# Indication of successful/unsuccessful accomplishment of test.
<<<<<< =================== >>>>>>
Q. 22: What is the utility of an Error Frequency Report?
Error frequency charts report the quantity of errors per unit of software product. The unit used
may be a section of a requirements specification, a test procedure paragraph, a source code
program unit, or any other objectively identifiable component of a software. The utility of an error
frequency report is based on the Pareto Principle of non homogeneous error distribution. If errors
are non homogeneously distributed in the product to be examined, then units with high detected
error frequencies will probably also have a larger than normal number of latent errors.
<<<<<< =================== >>>>>>
Q. 23: What is the Adequacy Criteria for testing?
Verification of software by testing or other means, is quite indirect. It is necessary to judiciously
constrain the verification process. Conditions that are required to be satisfied during testing are
called adequacy criteria. For example, testing may be considered inadequate if the test data do
not include boundary cases specified by the requirements, do not cause execution of every line of
code, or do not cause the software to deal with error-prone situations.
The intent in establishing these criteria is to improve the quality of the testing. As such, adequacy
criteria serve a purpose somewhat akin to software development standards. Adequacy criteria act
as both specifier and judge: as specifier by indicating the constraints that must be satisfied by the
testing, and as judge by indicating deficiencies in a particular test. Adequacy criteria for testing
are generally expressed by stating some required coverage the test data should achieve.
Desirable coverages include the required features, the software structure, or the potential errors
that might occur in the life cycle.
<<<<<< =================== >>>>>>
Q. 24: What are the limitations of testing?
Some problems cannot be solved on a computer because are either intractable or undecidable.
An undecidable problem is one for which no algorithmic solution is possible. In general, programs
cannot be exhaustively tested (tested for each input). Huang shows that to test exhaustively a
program that reads two 32-bit integers would take on the order of 50 billion years. Even if the
input space is smaller, on the very first input it may be the case that the program does not halt

2. within a reasonable time. It may even be the case that it is obvious the correct output will be
produced if the program ever does halt. Exhaustive testing can only be completed, therefore, if all
non-halting cases can be detected and eliminated.
Another limitation on the power of testing is its reliance on an oracle. An oracle is a mechanism
that judges whether or not a given output is correct for a given input. In some cases, no oracle
may be available e.g., when the program is written to compute an answer that cannot, in practice,
be computed by hand. Imperfect oracles may be available, but their use is risky. The absence of
an oracle, or the presence of an imperfect oracle weakens significantly any conclusions drawn
from testing.
<<<<<< =================== >>>>>>
Q. 25: What is Fault Seeding?
Fault seeding is a statistical method used to assess the number and nature of the faults
remaining in a program. First, faults are seeded into a program. Then the program is tested, and
the number of faults discovered is used to estimate the number of faults yet undiscovered. A
difficulty with this technique is that the faults seeded must be representative of the yet-
undiscovered faults in the program.
<<<<<< =================== >>>>>>
Q. 26: What is Mutation Analysis?
Mutation analysis uses fault seeding to investigate properties of test data. Programs with seeded
faults are called mutants. Mutants are executed to determine whether or not they behave
differently from the original program. Mutants that behave differently are said to have been killed
by the test. The product of mutation analysis is a measure of how well test data kill mutants.
Mutants are produced by applying a mutation operator. Such an operator changes a single
expression in the program to another expression, selected from a finite class of expressions. For
example, a constant might be incremented by one, decremented by one, or replaced by zero,
yielding one of three mutants. Applying the mutation operators at each point in a program where
they are applicable forms a finite, albeit large, set of mutants.
<<<<<< =================== >>>>>>
Q. 27: What are the conditions necessary for a fault to cause a program failure?
Three conditions necessary and sufficient for a fault to cause a program failure are execution,
infection, and propagation. The fault location must be executed, the resulting data state must be
infected with an erroneous value, and the succeeding computation must propagate the infection
through erroneous data states, producing a failure.
Sensitivity analysis investigates the three conditions required for failure, with particular focus on
infection and propagation of errors.
Infection analysis employs mutation analysis to determine the probability of a data state’s being
infected after a potentially faulty statement is executed.
Propagation analysis mutates the data state to determine the probability that an infected data
state will cause a program failure.
<<<<<< =================== >>>>>>
Q. 28: What is Symbolic Analysis?

3. Symbolic analysis seeks to describe the function computed by a program in a more general way.
A symbolic execution system accepts three inputs: a program to be interpreted, symbolic input for
the program, and the path to follow. It produces two outputs: the symbolic output that describes
the computation of the selected path, and the path condition for that path. The specification of the
path can be either interactive or pre-selected. The symbolic output can be used to prove the
program correct with respect to its specification, and the path condition can be used for
generating test data to exercise the desired path. Structured data types cause difficulties,
however, since it is sometimes impossible to deduce what component is being modified.
<<<<<< =================== >>>>>>
Q. 29: What is Specification Oriented Testing?
Program testing is specification-oriented when test data are developed from documents and
understandings intended to specify a module’s behavior. Sources include, but are not limited to,
the actual written specification and the high- and low-level designs of the code to be tested. The
goal is to test for the presence of each (required) software feature, including the input domains,
the output domains, categories of inputs that should receive equivalent processing, and the
processing functions themselves.
Specification-oriented testing seeks to show that every requirement is addressed by the software.
An unimplemented requirement may be reflected in a missing path or missing code in the
software. Specification-oriented testing assumes a functional view of the software and sometimes
is called functional or black-box testing.
<<<<<< =================== >>>>>>
Q. 30: What is Input Domain Testing?
It is the testing based on the interface of the module. In extremal testing, test data are
chosen to cover the extremes of the input domain. Similarly, midrange testing selects data
from the interiors of domains. For structured input domains, combinations of extremal points
for each component are chosen. This procedure can generate a large quantity of data.
Read More articles on ISTQB CTAL Advanced Level Certifications at
http://www.softwaretestinggenius.com/categoryDetail.php?catId=166