ISTQB Advance Level Exam

7/31/2019 ISTQB Advance Level Exam

1/31

ISTQB Advanced CTAL Exam Study Guide (Part 1)

Q. 1: What is Configuration management?

Software configuration management encompasses the disciplines and techniques of initiating,

evaluating, and controlling change to software products during and after the development process. Itemphasizes the importance of configuration control in managing software production.

Configuration management is an integral part of the software development process across all phases of

the life cycle. It functions as a controlling discipline, enabling changes to be made to existing

documentation and products in such a way as not to destroy the integrity of the software. Since

configuration management extends over the life of the product, and since tools, techniques, and

standards exist solely aimed at its proper execution, configuration management can stand alone as a

module within a graduate curriculum.

>

Q. 2: What are the Requirements for the Success of Configuration Management?

The key requirement for success of configuration management is the commitment of all levels of

management to enforcing its use throughout the project lifetime. Configuration management, like other

parts of software engineering perceived as being tedious, may require some coercion for success. A

further requirement is the availability of a clearly stated configuration management plan.

>

Q. 3: How can we say that Configuration Management is a Cost Saving Tool?

By helping to maintain product integrity, configuration management reduces overall software

development costs. Cost savings during a particular phase of the life cycle depend on the depth of

application of configuration management. For instance, controlling individual source code modules costs

more than only controlling the fully integrated product, but should result in overall savings due to

reduction in side effects from individual changes. At this time, however, there are no quantitative

measures sufficiently well developed to document the cost savings. This is largely because the losses

due to lack of configuration management do not occur, and thus cannot be measured.

>

Q. 4: What are the Requirements for the Success of Configuration Management?

The key requirement for success of configuration management is the commitment of all levels of

management to enforcing its use throughout the project lifetime. Configuration management, like other

parts of software engineering perceived as being tedious, may require some coercion for success. A

further requirement is the availability of a clearly stated configuration management plan.


2/31

>

Q. 5: What are the Configuration Items?

A configuration item is a document or artifact explicitly placed under configuration control. The

minimum number of controlled items in a software project is whatever may be needed to effectively

maintain and enhance the product. These may include requirements, specification, and design

documents, source code, test plans, user and maintenance manuals, interface control documents,

memory maps, and others such as procedural or policy documents. The actual items under control vary

with the needs of the project, and certain items may be waived at specific points in the life cycle.

Remember that there are time and cost tradeoffs associated with the number and level of items under

control.

>

Q. 6: How many kinds of discrepancies can be identified in discrepancy reports?

1) Requirements Errors: This type of discrepancy is an error in the requirements. Either the customer or

marketing did not fully or clearly express the requirements, or incorrect information was given.

2) Development Errors: Another type of discrepancy is an error done during development. This means

that a correct requirement was improperly implemented. Development errors occur between the time

the requirements are baselined and the time the product is turned over to the customer or to

marketing.

3) Violations of Standards: Yet another type of discrepancy is a violation of development standards,

either the company standard or a customer standard in effect due to contract.

>

Q. 7: Describe the types of changes, which can be requested?

Change requests are treated largely like discrepancy reports. There are three kinds of changes that may

be requested.

1) Unimplementable Requirements: One reason for a change request is that a requirement turns out to

be unimplementable through resource constraints identified by the requester. Another reason is that a

"bad" implementation makes meeting all requirements impossible.

2) Enhancements: Enhancements are change requests that involve additional requirements.

3) Improvements: Improvements are change requests that will improve the product, though not in

terms of functionality or performance. An example would be a request to rewrite a block of code to

increase the understandability.


3/31

>

Q. 8: What is the most serious problem encountered during configuration management?

One of the most serious configuration management problems is that of simultaneous update, when two

or more programmers are modifying the same portion of code. There is a distinct possibility that one

persons changes will cancel or distort another persons, thus causing a software failure. Checking out

code and other documents for modification must be handled by mutual exclusion, either manually or

automatically (using version control software).

>

Q. 9: What is the relationship between quality assurance and the Software Life-cycle?

The function of Software Quality Assurance interacts to some degree with each phase of every software

development process. Planning should occur in the initial phases of a software project and shouldaddress the methods and techniques to be used in each phase. A description of every product resulting

from a phase and the attributes desired of each product should be defined in order to provide a basis for

objectively identifying satisfactory completion of the phase.

>

Q. 10: What are the factors having large impact on the software quality assurance program?

# Schedule requirements

# Available budget# Technical complexity of the software product

# Anticipated size of the software product

# Relative experience of the labor pool

# Available resources

# Contract requirements


4/31


Q. 11: What are Configuration audits?

Final acceptance of a software product is frequently based on completing a set of configuration audits.

These audits ensure that the product has satisfactorily met all of its applicable requirements.

1) Functional Configuration Audit:The primary purpose of the Functional Configuration Audit is to

ensure that the product that was tested to demonstrate compliance with contract requirements is

essentially the same as the product that will be delivered. Conducting software tests frequently takes

months or even years, during which time the software item being tested may undergo revisions and

modifications. The Functional Configuration Audit should ensure that none of these revisions adversely

affects the results of previous tests.

2) Physical Configuration Audit:The primary purpose of the Physical Configuration Audit is to ensure

that all of the requirements of the contract have been satisfied, with special emphasis on the

documentation and data delivery requirements. This audit usually is performed after the Functional

Configuration Audit has demonstrated that the item functions properly.

>

Q. 12: What are the activities covered under software Requirements Phase?

The activities and products of the software requirements phase should be examined throughout the

conduct of this phase. This examination should evaluate the following:

# Software development plan# Software standards and procedures manual

# Software configuration management plan

# Software quality program plan

# Software requirements specification

# Interface requirements specification

# Operational concept document

>

Q. 13: What are the activities covered under software Preliminary Design phase?

The activities and products of the software preliminary design phase should be examined throughout

the conduct of this phase. This examination should consist of the following evaluations:

# All revised program plans

# Software top level design document

# Software test plan


5/31

# Operators manual

# Users manual

# Diagnostic manual

# Computer resources integrated support document

>

Q. 14: What are the activities covered under software Detailed Design phase?

The activities and products of the software detailed design phase should be examined throughout the

conduct of this phase. This examination should consist of the following evaluations:


# Software detailed design document

# Interface design document

# Database design document

# Software development files

# Unit test cases

# Integration test cases

# Software test description

# Software programmers manual

# Firmware support manual

# All revised manuals

# Computer resources integrated support document

>

Q. 15: What are the activities covered under the software Coding & Unit Testing phase?

The activities and products of the software coding & unit testing phase should be examined throughout

the conduct of this phase. This examination should consist of the following evaluations:


# Source code

# Object code

# Software development folders

# Unit test procedures# Unit test results

# All revised description documents

# Integration test procedures

# Software test procedure



6/31

>

Q. 16: What are the activities covered under the Integration and Testing phase?

The activities and products of the integration & testing phase should be examined throughout theconduct of this phase. This examination should consist of the following evaluations:


# Integration test results

# All revised description documents

# Revised source code

# Revised object code

# Revised software development files

# Software test procedures


>

Q. 17: What are the activities covered under the System Testing phase?

The activities and products of the system testing phase should be examined throughout the conduct of

this phase. This examination should consist of the following evaluations:


# System test report

# All revised description documents# Revised source code

# Revised object code

# Revised software development files

# Software product specification

# Version description document

# All manuals

>

Q. 18: What are the various types of evaluations for software product?

The following types of evaluations apply to almost every software product.

The software quality assurance program plan specifies which products are evaluated, and which

evaluations are performed on those products.

# Adherence to required format and documentation standards


7/31

# Compliance with contractual requirements

# Internal consistency

# Understandability

# Traceability to indicated documents

# Consistency with indicated documents

# Appropriate requirements analysis, design, coding techniques used to prepare item

# Appropriate allocation of sizing, timing resources

# Adequate test coverage of requirements

# Testability of requirements

# Consistency between data definition and use

# Adequacy of test cases, test procedures

# Completeness of testing

# Completeness of regression testing

>

Q. 19: What are the constituents of an effective error reporting system?

No matter what software engineering techniques are used, errors seem to be a fact of life. Maintaining

an effective error reporting system, however will help minimize the potential impact of software errors.

Every software development project should establish an error reporting system even if it consists of

notes scribbled on the back of a napkin. It takes valuable resources to detect each error, but they are

wasted if they must be used to locate an error that had been previously detected.

An effective error reporting system is the one that addresses the following areas.

1. Identification of Defect

2. Analysis of Defect

3. Correction of Defect

4. Implementation of Correction

5. Regression Testing

6. Categorization of Defect

7. Relationship to Development Phases

>

Q. 20: How do we categorize defects?

Errors can frequently be grouped into categories, which will allow future data analysis of errors

encountered. The most efficient time to categorize them is usually as they are resolved while the

information is still fresh. Possible classifications for error categorization are


8/31

# Error type: Requirements, design, code, test, etc.

# Error priority: No work around available, work around available, cosmetic.

# Error frequency: Recurring, non-recurring.


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 probablyalso 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.


9/31

>

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 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 thepresence 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 mutationoperators 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,


10/31

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 states 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?

Symbolic analysis seeks to describe the function computed by a program in a more general way. Asymbolic 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 modules 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 calledfunctional or black-box testing.

>


11/31

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.


Q. 31: What is Equivalence partitioning?

Specifications frequently partition the set of all possible inputs into classes that receive equivalent

treatment. Such partitioning is called equivalence partitioning. A result of equivalence partitioning is the

identification of a finite set of functions and their associated input and output domains.

Input constraints and error conditions can also result from this partitioning. Once these partitions have

been developed, both extremal and midrange testing are applicable to the resulting input domains.

Equivalence partitioning can be compared with random testing on the basis of statistical confidence in

the probability of failure after testing is complete.

>

Q. 32: What is Syntax checking?

Every robust program must parse its input and handle incorrectly formatted data. Verifying this feature

is called syntax checking. One means of accomplishing this is to execute the program using a broad

spectrum of test data. By describing the data with a BNF grammar, instances of the input language canbe generated using algorithms from automata theory and describe systems that provide limited control

over the data to be generated.

>

Q. 33: What is Special value testing?

Selecting test data on the basis of features of the function to be computed is called special value testing.

This procedure is particularly applicable to mathematical computations. Properties of the function to be

computed can aid in selecting points that will indicate the accuracy of the computed solution.

For example, the periodicity of the sine function suggests use of test data values, which differ bymultiples of 2 Pi. Such characteristics are not unique to mathematical computations.

>

Q. 34: What are the Decision Tables?

Decision tables are a concise method of representing an equivalence partitioning. The rows of a decision


12/31

table specify all the conditions that the input may satisfy. The columns specify different sets of actions

that may occur. Entries in the table indicate whether the actions should be performed if a condition is

satisfied. Typical entries are "Yes," "No," or "Dont Care." Each row of the table suggests significant test

data. Cause-effect graphs provide a systematic means of translating English specifications into decision

tables, from which test data can be generated.

>

Q. 35: What is Implementation-oriented testing?

In implementation-oriented program testing, test data selection is guided by information derived from

the implementation [Howden75]. The goal is to ensure that various computational characteristics of the

software are adequately covered. It is hoped that test data that satisfy these criteria have higher

probability of discovering faults. Each execution of a program executes a particular path. Hence,

implementation oriented testing focuses on the following questions: What computational characteristics

are desirable to achieve? What paths for this program achieve these characteristics? What test data will

execute those paths? What are the computational characteristics of the set of paths executed by a given

test set?

Implementation oriented testing addresses the fact that only the program text reveals the detailed

decisions of the programmer. For the sake of efficiency, a programmer might choose to implement a

special case that appears nowhere in the specification. The corresponding code will be tested only by

chance using specification-oriented testing, whereas use of a structural coverage measure such as

statement coverage should indicate the need for test data for this case.

Implementation-oriented testing schemes may be classified according to two orthogonal axes: 1) Error

orientation and 2) Program view.

A testing schemes error orientation is the aspect of fault discovery that is emphasized: execution,infection, or propagation. A testing schemes program view is the program abstraction source that is

used to determine desirable computational characteristics: control flow, data flow, or computation flow.

Program view emphasizes how a particular strategy works; error orientation emphasizes the motivation

behind the strategy and helps one to better evaluate claims made about the strategy.

>

Q. 36: What is Structure-oriented testing?

A testing technique is structure-oriented if it seeks test data that cause various structural aspects of the

program to be exercised. Assessing the coverage achieved may involve instrumenting the code to keeptrack of which parts of the program are actually exercised during testing. The inexpensive cost of such

instrumentation has been a prime motivation for adopting structure-oriented techniques. Further

motivation comes from consideration of the consequences of releasing a product without having

executed all its parts and having the customer discover faults in untested code.

Following are the three essential components that are covered in Structure-oriented testing are:

computations, branches & data.


13/31

>

Q. 37: What is Statement testing?

Statement testing requires that every statement in the program be executed. While it is obvious that

achieving 100% statement coverage does not ensure a correct program, it is equally obvious that

anything less means that there is code in the program that has never been executed.

>

Q. 38: What is Branch testing?

Achieving 100% statement coverage does not ensure that each branch in the program flow graph has

been executed. For example, executing an if... then statement (no else) when the tested condition is

true, tests only one of two branches in the flow graph. Branch testing seeks to ensure that every branch

has been executed. Branch coverage can be checked by probes inserted at points in the program thatrepresent arcs from branch points in the flow graph. This instrumentation suffices for statement

coverage as well.

>

Q. 39: What is Data coverage testing?

In some programs, a portion of the flow control is determined by the data, rather than by the code.

Knowledge-based applications, some AI applications, and table-driven code are all examples of this

phenomenon. Data coverage testing seeks to ensure that various components of the data are

"executed," i.e., they are referenced or modified by the interpreter as it executes. Paralleling statementtesting, one can ensure that each data location is accessed. Furthermore, in the area of knowledge

bases, data items can be accessed in different orders, so it is important to cover each of these access

orders. These access sequences are analogous to branch testing.

>

Q. 40: What is Infection-oriented testing?

A testing technique is considered Infection-oriented if it seeks to establish conditions suitable for

infections to arise at locations of potential faults. Following are the testing techniques that require test

data to force infections if faults exist.

1) Conditional testing

2) Expression testing

3) Domain testing

4) Perturbation testing

5) Fault sensitivity testing


14/31


15/31


16/31

Path coverage does not imply condition coverage or expression coverage, since an expression may

appear on multiple paths but some subexpressions may never assume more than one value.

>

Q. 48: What is Compiler-based testing?

In a compiler based testing input-output pairs are encoded as a comment in a procedure, as a partial

specification of the function to be computed by that procedure. The procedure is then executed for

each of the input values and checked for the output values. The test is considered adequate only if each

computational or logical expression in the procedure is determined by the test; i.e., no expression can

be replaced by a simpler expression and still pass the test.

Simpler is defined in a way that allows only finitely many substitutions. Thus, as the procedure is

executed, each possible substitution is evaluated on the data state presented to the expression. Those

that do not evaluate the same as the original expression are rejected. Substitutions that evaluate the

same, but ultimately produce failures, are likewise rejected.

>

Q. 49: What is Data Flow Testing?

Data flow analysis can form the basis for testing exploiting the relationship between points where

variables are defined and points where they are used. By insisting on the coverage of various definition-

use pairs, data flow testing establishes some of the conditions necessary for infection and partial

propagation. The motivation behind data flow testing is that test data are inadequate if they do not

exercise these various definitions use combinations. It is clear that an incorrect definition that is never

used during a test will not be caught by that test. Similarly, if a given location incorrectly uses a

particular definition, but that combination is never tried during a test, the fault will not be detected.

Data flow connections may be determined statically or dynamically. Some connections may be infeasible

due to the presence of infeasible subpaths. Heuristics may be developed for generating test data based

on data flow information.

>

Q. 50: What is Mutation testing?

Mutation testing uses mutation analysis to judge the adequacy of test data. The test data are judged

adequate only if each mutant is either functionally equivalent to the original program or computes

output different from the original program on the test data. Inadequacy of the test data implies that

certain faults can be introduced into the code and go undetected by the test data.


17/31


18/31

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 programs 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 concernfor 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.

>


19/31

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. Theirpower 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


20/31

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 technologicalmechanisms 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 softwareprocess 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. Systemdevelopment in this model therefore spirals out only so far as needed according to the risk that must be

managed.

>


21/31


22/31

Q. 62: What are the types of errors targeted by regression testing?

1) Data corruption errors:These errors are side effects due to shared data.

2) Inappropriate control sequencing errors:These errors are side effects due to changes in execution

sequences. An example of this type of error is the attempt to remove an item from a queue before it isplaced into the queue.

3) Resource contention:Examples of these types of errors are potential bottlenecks and deadlocks.

4) Performance deficiencies:These include timing and storage utilization errors.

>

Q. 63: What are the types of errors targeted by integration testing?

1) Import/export range errors:This type of error occurs when the source of input parameters falls

outside of the range of their destination. For example, assume module A calls module B with table

pointer X. IfA assumes a maximum table size of 10 and B assumes a maximum table size of 8, an

import/export range error occurs. The detection of this type of error requires careful boundary-value

testing of parameters.

2) Import/export type compatibility errors:This type of error is attributed to a mismatch of user-

defined

types. These errors are normally detected by compilers or code inspections.

3) Import/export representation errors:This type of error occurs when parameters are of the sametype, but the meaning of the parameters is different in the calling and called modules. For example,

assume module A passes a parameter Elapsed_Time, of type real, to module B. Module A might pass the

value as seconds, while module Bis assuming the value is passed as milliseconds. These types of errors

are difficult to detect, although range checks and inspections provide some assistance.

4) Parameter utilization errors:Dangerous assumptions are often made concerning whether a module

called will alter the information passed to it. Although support for detecting such errors is provided by

some compilers, careful testing and/or inspections may be necessary to insure that values have not

been unexpectedly corrupted.

5) Integration time domain/ computation errors:A domain error occurs when a specific input follows

the wrong path due to an error in the control flow. A computation error exists when a specific input

follows the correct path, but an error in some assignment statement causes the wrong function to be

computed. Although domain and computation errors are normally addressed during module testing, the

concepts apply across module boundaries. In fact, some domain and computation errors in the


23/31

integrated program might be masked during integration testing if the module being integrated is

assumed to be correct and is treated as a black box.

>

Q. 64: What are the different strategies for integration testing?

Several strategies for integration testing exist. These strategies may be used independently or in

combination. The primary techniques are:

1) Top-down integration: Top-down integration attempts to combine incrementally the components of

the program, starting with the topmost element and simulating lower level elements with stubs. Each

stub is then replaced with an actual program component as the integration process proceeds in a top-

down fashion. Top-down integration is useful for those components of the program with complicated

control structures. It also provides visibility into the integration process by demonstrating a potentially

useful product early.

2) Bottom-up integration: Bottom-up integration attempts to combine incrementally components of

the program starting with those components that do not invoke other components. Test drivers must be

constructed to invoke these components. As bottom-up integration proceeds, test drivers are replaced

with the actual program components that perform the invocation, and new test drivers are constructed

until the "top" of the program is reached. Bottom-up integration is consistent with the notion of

developing software as a series of building blocks. Bottom-up integration should proceed wherever the

driving control structure is not too complicated.

3) Big-bang integration: Big-bang integration is not an incremental strategy and involves combining and

testing all modules at once. Except for small programs, big-bang integration is not a cost-effective

technique because of difficulty of isolating integration testing failures.

4) Threaded integration: Threaded integration is an incremental technique that identifies major

processing functions that the product is to perform and maps these functions to modules implementing

them. Each processing function is called a thread. A collection of related threads is often called a build.

Builds may serve as a basis for test management. To test a thread, the group of modules corresponding

to the thread is combined. For those modules in the thread with interfaces to other modules not

supporting the thread, stubs are used. The initial threads to be tested normally correspond to the

"backbone" or "skeleton" of the product under test. The addition of new threads for the product

undergoing integration proceeds incrementally in a planned fashion.

>


24/31

Q. 65: What are the guidelines for selecting paths in a transaction Flow?

1)Test every link/decision in the transaction flow graph.

2) Test each loop with a single, double, typical, maximum, and maximum- less-one number of iterations

3) Test combinations of paths within and between transaction flows.

4) Test that the system does not do things that it is not supposed to do, by watching for unexpected

sequences of paths within and between transaction flows.

Once the transaction flows have been identified black-box testing techniques can be utilized to generate

test data for selected paths through the transaction flow diagram.

>

Q. 66: What is Failure Analysis?

Failure analysis is the examination of the products reaction to failures of hardware or software. The

products specifications must be examined to determine precisely which types of failures must be

analyzed and what the products reaction must be. Failure analysis is sometimes referred to as "recovery

testing".

Failure analysis must be performed during each of the products V&V activities. It is essential during

requirement and specification V&V activities that a clear statement of the products response to various

types of failures be addressed in terms that allow analysis. The design must also be analyzed to show

that the products reaction to failures satisfies its specifications. The failure analysis of implementationsoften occurs during system testing. This testing may take the form of simulating hardware or software

errors or actual introduction of these types of errors.

Failure analysis is essential to detecting product recovery errors. These errors can lead to lost files, lost

data, duplicate transactions, etc. Failure analysis techniques can also be combined with other

approaches during V&V activities to insure that the products specifications for such attributes as

performance, security, safety, usability, etc., are met.

>

Q. 67: What is Concurrency Analysis?

Concurrency analysis examines the interaction of tasks being executed simultaneously within the

product to insure that the overall specifications are being met. Concurrent tasks may be executed in

parallel or have their execution interleaved. Concurrency analysis is sometimes referred to as

"background testing".


25/31

For products with tasks that may execute in parallel, concurrency analysis must be performed during

each of the products V&V activities. During design, concurrency analysis should be performed to

identify such issues as potential contention for resources, deadlock, and priorities. A concurrency

analysis for implementations normally takes place during system testing. Tests must be designed,

executed, and analyzed to exploit the parallelism in the system and insure that the specifications are

met.

>

Q. 68: What is Performance Analysis?

The goal of performance analysis is to insure that the product meets its specified performance

objectives. These objectives must be stated in measurable terms, so far as possible. Typical performance

objectives relate to response time and system throughput.

A performance analysis should be applied during each of the products V&V activities. Duringrequirement and specification V&V activities, performance objectives must be analyzed to insure

completeness, feasibility, and testability. Prototyping, simulation, or other modeling approaches may be

used to insure feasibility. For designs, the performance requirements must be allocated to individual

components.

These components can then be analyzed to determine if the performance requirements can be met.

Prototyping, simulation and other modeling approaches again are techniques applicable to this task. For

implementations a performance analysis can take place during each level of testing. Test data must be

carefully constructed to correspond to the scenarios for which the performance requirements were

specified.

>

Q. 69: What is Proof of Correctness?

Proof of correctness is a collection of techniques that apply the formality and rigor of mathematics to

the task of proving the consistency between an algorithmic solution and a rigorous, complete

specification of the intent of the solution. This technique is also often referred to as "formal

verification."

Proof of correctness techniques are normally represented in the context of verifying an implementation

against a specification. The techniques are also applicable in verifying the correctness of other products,

as long as they possess a formal representation.

>


26/31

Q. 70: What are the different types of evaluations for assuring software quality?

Different evaluation types are:

1) Internal consistency of product

2) Understandability of product

3) Traceability to indicated documents

4) Consistency with indicated documents

5) Appropriate allocation of sizing, timing resources

6) Adequate test coverage of requirements

7) Consistency between data definitions and use

8) Adequacy of test cases and test procedures

9) Completeness of testing

10) Completeness of regression testing


Q. 71: What type of information to be collected and documented for problem tracking as a part of

V&V plan?

1) When the problem had occurred

2) Where the problem had occurred

3) State of the system before occurrence

4) Evidence of the problem

5) Actions or inputs that appear to have led to occurrence

6) Description of how the system should work; reference to relevant requirements7) Priority for solving problem

8) Technical contact for additional information

>

Q. 72: What type of data needs to be collected and documented for tracking of test activities as a part

of V&V plan?

1) Number of tests executed

2) Number of tests remaining

3) Time used

4) Resources used

5) Number of problems found and the time spent finding them

This data can then be used to track actual test progress against scheduled progress. The tracking

information is also important for future test scheduling.


27/31

>

Q. 73: Explain the Shewarts Plan-Act-Check-Do paradigm?

Shewarts paradigm, applied to both the software product and process, generally consists of the

following activities:

1) Plan: The SEI capability maturity model is a general framework or plan for developing five increasingly

improved levels (initial, repeatable, defined, managed, and optimizing) of software process maturity.

Because the CMM is designed to be generic, each organization must customize its process improvement

plan for its own application(s), environment, and company organization. The five levels are designed as a

logical progression, so each level must be achieved, in order, from one to five. It is not possible to skip

levels.

2) Act: Because software is not produced by a manufacturing process, software designers must both

strive to meet the users functional requirements for the product and design for correct implementation

and easy maintainability.

3) Check: Software inspections and peer reviews are the major product control mechanism used.

Quantifiable inspections results such as change requests provide the foundation for measurable process

control and improvement. Audits are the most usual process verification process.

Auditors need to examine not only whether the standards, procedures, and tools are adequate,

but they also to see how well the project is following the prescribed process plans.

4) Do: Software quality control is often specified both by the customer acceptance criteria in the

contract or requirements specification and by whether the software product meets written standards.

Software measures are used to measure product quality in a quantifiable way.

The most common process quality control approach is tracking actual against expected performance.

Causes for significant deviation from the plan are found and corrected.

>

Q. 74: What are the uses of the CMM?

The capability maturity model, developed by the Software Engineering Institute, is designed to help both

development organizations and customers (government organizations or companies who acquire

software). Software organizations need to understand the quality of their software process and how to

improve it. Organizations contracting for software need ways to evaluate a potential contractors

capability to carry out the work.


28/31

The CMM has four intended uses to help organizations improve their software process capabilities:

1) Identify improvements

2) Identify risks in selecting contractors

3) Implement a process improvement program

4) Guide definition and development of the software process

>

Q. 75: What is SPA "Software Process Assessment" method for applying CMM?

A software process assessment is an in-house determination, primarily of the weaknesses of the

software process in an organization as a whole. It is an internal tool that an organization can choose as a

part of an overall program for improving its ability to produce high-quality products on time and within

budget.

The objectives of the SPA method are as under:

(1) Identify strengths, weaknesses, and existing improvement activities on which to base an

organization-wide improvement effort and

(2) To get organizational buy-in to that effort.

The method is used to help an organization identify key areas for improvement, begin to baseline its

software process, and initiate improvements.

>

Q. 76: What is SCE "Software Capability Evaluation" method for applying CMM?

A software capability evaluation is an independent evaluation of an organizations software process as it

relates to a particular acquisition. It is a tool that helps an external group (an "acquirer") determine the

organizations ability to produce a particular product having high quality and to produce it on time and

within budget.

The objective of the SCE method is to identify strengths, weaknesses, and existing improvement

activities in a suppliers software process that best indicate the risk associated with using that supplier

for a particular software acquisition. The method is used to identify software risks, help in mitigating

these risks, and motivate initiation of improvement programs.


29/31


30/31

achieving the goals of the KPA. Goals can be used to resolve whether an organization or project has

adequately implemented a key process area. Goals signify the scope, boundaries, and intent of each key

process area.

Key process areas are building blocksfundamental activities for organizations trying to improve their

software process. Other process areas exist, but these were selected as particularly effective in

improving process capability. Each key process area is unique to a single maturity level.

>

Q. 79: What are the Key Practices in CMM?

Key practices are the lowest level, specific details of the CMM. Key practices define each key process

area 3 by specifying policies, procedures, and activities that contribute to satisfying its goal. They are a

working definition of the key process area.

Key practices provide a link between the CMM and the maturity questionnaire. Specific questions relate

to specific key practices. Industry experience and empirical studies were used to identify the key

practices chosen by the SEI. Each key practice describes, but does not mandate, how that practice

should be performed.

>

Q. 80: What are the Maturity Questionnaire in CMM?

The maturity questionnaire consists of questions about the software process that sample the practicesin each key process area.

The maturity questionnaire is a springboard for an assessment or evaluation teams visit. The CMM

provides a hierarchical structure that guides the team in investigating an organizations software

process. Answers to the questions identify process strengths and weaknesses in terms of key process

areas. Questions in the maturity questionnaire are designed to determine the presence or absence of

the various key practices. Questions are not open-ended, but are intended to obtain a quantified result

from the following answers: yes, no, dont know, and not applicable.

The SCE team identifies strengths, weaknesses, and improvement activities that they consider to bemost relevant to performance on the acquisition contract. A group in the acquisition agency then

transforms the findings into acquisition risks and/or technical ratings, which, along with other criteria,

the agency can use to select a source or monitor a contract.

The SPA team also analyzes the questionnaire data to determine the current software process maturity

level, identify key findings (that is, determine what will impede capability to produce quality software),


31/31

and note strengths the organization can build upon. The team presents the results to senior

management and, often, to the entire organization that was assessed. The team often enlists the aid of

others within the organization to make recommendations for process improvement actions. An action

planning group (often a software engineering process group, under the guidance of a management

steering committee) develops the strategies for accomplishing long-term process improvement and

determines what improvements are achievable within a specific time frame. They work with many

others in the organization to create an action plan and implement it.

ISTQB Advance Level Exam

Documents

Transcript of ISTQB Advance Level Exam