ISTQB Advanced Level Certification – Study Guide (Part 6)

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. 51: What is Error-based Testing?

Error-based testing seeks to demonstrate that certain errors have not been committed in the
programming process. Error-based testing can be driven by histories of programmer errors,
measures of software complexity, knowledge of error-prone syntactic constructs, or even error
guessing.

Error-based testing begins with the programming process, identifies potential errors in that
process and then asks how those errors are reflected as faults. It then seeks to demonstrate the
absence of those faults.

In the error-based approach to program testing and analysis, the focus is on errors that a
programmer or designer may make during the software development process, and on techniques
that can be used to detect their occurrence. It is often the case that a program is constructed
without any formal, detailed specification. In this case the code itself is the only complete
specification. This means that the only way to verify such a program is to ensure that no errors
were made by the programmer during programming. The term “errors” here means errors that
occur due to human fallibility. This requires that we study the ways in which humans make
mistakes in the construction of artifacts, and then build methods to detect when they have
occurred.

There is a simple model in which human errors are classified as being either errors of
decomposition or errors of abstraction.

<<<<<< =================== >>>>>>

Q. 52: What is Flavor analysis?

Flavor analysis is a kind of dynamic type checking. It allows the programmer to document
properties of objects that change during the operation of a program, and to check if assumptions
about an object’s current set of properties are correct.

<<<<<< =================== >>>>>>

Q. 53: What is Fault-based testing?

Fault-based testing aims at demonstrating that certain prescribed faults are not in the code. Fault-
based testing methods differ in both extent and breadth. One with local extent demonstrates that
a fault has a local effect on computation; it is possible that this local effect will not produce a
program failure. A method with global extent demonstrates that a fault will cause a program
failure. Breadth is determined by whether the technique handles a finite or an infinite class of
faults. Extent and breadth are orthogonal. Infection- and propagation-oriented techniques could
be classified as fault-based if they are interpreted as seeking to demonstrate the absence of
particular faults. Infection-oriented techniques are of local extent.

Morell has defined a fault-based method based on symbolic execution that permits elimination of
infinitely many faults through evidence of global failures. Symbolic faults are inserted into the
code, which is then executed on real or symbolic data. Program output is then an expression in
terms of the symbolic faults. It thus reflects how a fault at a given location will impact the
program’s output. This expression can be used to determine actual faults that could not have
been substituted for the symbolic fault and remain undetected by the test.

<<<<<< =================== >>>>>>

Q. 54: What is a software life cycle model?

A sofware life cycle model is either a descriptive or prescriptive characterization of software

evolution. Typically, it is easier to articulate a prescriptive life cycle model for how software
systems should be developed. This is possible since most such models are intuitive. This means
that many software development details can be ignored, glossed over, or generalized. This, of
course, should raise concern for the relative validity and robustness of such life cycle models
when developing different kinds of application systems in different kinds of development settings.
Descriptive life cycle models, on the other hand, characterize how software systems are actually
developed. As such, they are less common and more difficult to articulate for an obvious reason:
one must observe or collect data throughout the development of a software system, a period of
elapsed time usually measured in years. Also, descriptive models are specific to the systems
observed, and only generalizable through systematic analysis. Therefore, this suggests the
prescriptive software life cycle models will dominate attention until a sufficient base of
observational data is available to articulate empirically grounded descriptive life cycle models.

<<<<<< =================== >>>>>>

Q. 55: How can we use software life cycle models?

Some of the ways these models can be used include:

1) To organize, plan, staff, budget, schedule and manage software project work over
organizational time, space, and computing environments.

2) As prescriptive outlines for what documents to produce for delivery to client.

3) As a basis for determining what software engineering tools and methodologies will be most
appropriate to support different life cycle activities.

4) As frameworks for analyzing or estimating patterns of resource allocation and consumption

during the software life cycle.

5) As comparative descriptive or prescriptive accounts for how software systems come to be the
way they are.

6) As a basis for conducting empirical studies to determine what affects software productivity,
cost, and overall quality.

<<<<<< =================== >>>>>>

Q. 56: What is a software process model?

A software process model often represents a networked sequence of activities, objects,

transformations, and events that embody strategies for accomplishing software evolution. Such
models can be used to develop more precise and formalized descriptions of software life cycle
activities. Their power emerges from their utilization of a sufficiently rich notation, syntax, or
semantics, often suitable for computational processing.

Software process networks can be viewed as representing methodical task chains. Task chains
structure the transformation of computational entities through a passage of sequence of actions
that denote each process activity. Task chains are idealized plans of what actions should be
accomplished, and in what order.

<<<<<< =================== >>>>>>

Q. 57: What is the difference between Evolutionistic and Evolutionary Models?

Every model of software evolution makes certain assumptions about what is the meaning of
evolution. In one such analysis of these assumptions, two distinct views are apparent:

Evolutionistic models focus attention to the direction of change in terms of progress through a
series of stages eventually leading to some final stage; evolutionary models on the other hand
focus attention to the mechanisms and processes that change systems. Evolutionistic models are
often intuitive and useful as organizing frameworks for managing and tooling software
development efforts. But they are poor predictors of why certain changes are made to a system,
and why systems evolve in similar or different ways.

Evolutionary models are concerned less with the stage of development, but more with the
technological mechanisms and organizational processes that guide the emergence of a system
over space and time. As such, it should become apparent that the traditional models are
evolutionistic, while the most of the alternative models are evolutionary.

<<<<<< =================== >>>>>>

Q. 58: What is Classic Software life cycle?

The classic software life cycle is often represented as a simple waterfall software phase model,
where software evolution proceeds through an orderly sequence of transitions from one phase to
the next in linear order. Such models resemble finite state machine descriptions of software
evolution. However, such
models have been perhaps most useful in helping to structure and manage large software
development projects in organizational settings.

<<<<<< =================== >>>>>>

Q. 59: What is the Spiral Model or Non-Operational Process Model?

The spiral model of software development and evolution represents a risk-driven approach to
software process analysis and structuring. The approach incorporates elements of specification-
driven and prototype driven process methods. It does so by representing iterative development
cycles in a spiral manner, with inner cycles denoting early analysis and prototyping, and outer
cycles denoting the classic system life cycle.

The radial dimension denotes cumulative development costs, and the angular dimension denotes
progress made in accomplishing each development spiral. Risk analysis, which seeks to identify
situations, which might cause a development effort to fail or go over budget/schedule, occurs
during each spiral cycle. In each cycle, it represents roughly the same amount of angular
displacement, while the displaced sweep volume denotes increasing levels of effort required for
risk analysis. System development in this model therefore spirals out only so far as needed
according to the risk that must be managed.

<<<<<< =================== >>>>>>

Q. 60: What are the various levels of testing?

Following are the different levels of testing activities each with its own specific goals.

1) Module Testing: Module (or unit) testing is the lowest level of testing and involves the testing
of a software module or unit. The goal of module-level testing is to insure that the component
being tested conforms to its specifications and is ready to be integrated with other components of
the product.

2) Integration Testing: Integration testing consists of the systematic combination and execution
of product components Multiple levels of integration testing are possible with a combination of
hardware and software components at several different levels. The goal of integration testing is to
insure that the interfaces between the components are correct and that the product components
combine to execute the product’s functionality correctly.

3) System Testing: System testing is the process of testing the integrated hardware and
software system to verify that the system meets its specified requirements. Practical
priorities must be established to complete this task effectively. One general priority is
that system testing must concentrate more on system capabilities rather than
component capabilities. This suggests that system tests concentrate on insuring the
use and interaction of functions rather than testing the details of their implementations.
Another priority is that testing typical situations is more important that testing special
cases. This suggests that test cases be constructed corresponding to high-probability
user scenarios. This facilitates early detection of critical problems that would greatly
disrupt a user.

4) Regression Testing: Regression testing can be defined as the process of executing

previously defined test cases on a modified program to assure that the software
changes have not adversely affected the program’s previously existing functions. The
error-prone nature of software modification demands that regression testing be
performed.

Read More articles on ISTQB CTAL Advanced Level Certifications at

http://www.softwaretestinggenius.com/categoryDetail.php?catId=166