Question Answers

Module 2
1 mark

1. What is White Box Testing?

It is software testing technique in which internal structure, design and coding of

software are tested to verify flow of input-output and to improve design, usability and
security.

2. What is Static Testing?

It is a type of software testing in which software application is tested without code
execution. The main objective of static testing is to improve the quality of software
applications by finding errors in early stages of software development process.

3. What is dynamic testing?

Under Dynamic Testing, a code is executed. It checks for functional behavior of
software system, memory/cpu usage and overall performance of the system.
4. What is Structural Testing?

Structure-based testing techniques use the internal structure of a software to derive

test cases. They are commonly called 'white-box' or 'glass-box' techniques, clear box
testing, open box testing, logic driven testing or path driven testing.

5. What is code coverage testing?

Code coverage is a software testing metric that determines the number of lines of code
that is successfully validated under a test procedure, which in turn, helps in analyzing
how comprehensively a software is verified.

2 marks

1. What are Dynamic Testing Techniques?

1. Unit Testing
Under Unit Testing, individual units or modules are tested by the developers.
It involves testing of source code by developers.
2. Integration Testing
Individual modules are grouped together and tested by the developers. The
purpose is to determine what modules are working as expected once they are
integrated.
3. System Testing
System Testing is performed on the whole system by checking whether the
system or application meets the requirement specification document.
 Also, Non-functional testing like performance, Security Testing fall under the
category of dynamic testing.

2. What are Structural Testing Techniques?

a. Statement Coverage - This technique is aimed at exercising all programming
statements with minimal tests.
b. Branch Coverage - This technique is running a series of tests to ensure that
all branches are tested at least once.
c. Path Coverage - This technique corresponds to testing all possible paths
which means that each statement and branch are covered.
3. How to Calculating Structural Testing Effectiveness?
a. Statement Testing = (Number of Statements Exercised / Total Number of
Statements) x 100 %
b. Branch Testing = (Number of decisions outcomes tested / Total Number of
decision Outcomes) x 100 %
c. Path Coverage = (Number paths exercised / Total Number of paths in the
program) x 100 %
4. What are the Importance of code coverage analysis?
a. Easy maintenance of code base – Writing scalable code is crucial to extend
the software program through the introduction of new or modified
functionalities. However, it is difficult to determine whether the written code
is scalable. It can prove to be a useful metric in that context The analysis
report will help developers to ensure code quality is well-maintained and new
features can be added with little-to-no efforts.
b. Exposure of bad code – Continuous analysis will help developers to
understand bad, dead, and unused code. As a result, they can improve
code-writing practices, which in turn, will result in better maintainability of
the product quality.
c. Faster time to market – With the help of this metric, developers can finish
the software development process faster, thereby increasing their productivity
and efficiency. As a result, they will be able to deliver more products, allowing
companies to launch more software applications on the market in lesser time.
This will undoubtedly lead to increased customer satisfaction and high ROI.

4 marks

1. Static Testing Techniques

1. Informal Reviews
 This is one of the types of review which doesn't follow any process to find errors
in the document. Under this technique, you just review the document and give
informal comments on it.
2. Technical Reviews
A team consisting of your peers, review the technical specification of the
software product and checks whether it is suitable for the project. They try to find
any discrepancies in the specifications and standards followed. This review
concentrates mainly on the technical documentation related to the software such
as Test Strategy, Test Plan and requirement specification documents.
3. Walkthrough
The author of the work product explains the product to his team. Participants can
ask questions if any. A meeting is led by the author. Scribe makes note of review
comments
4. Inspection
The main purpose is to find defects and meeting is led by a trained moderator.
This review is a formal type of review where it follows a strict process to find the
defects. Reviewers have a checklist to review the work products. They record the
defect and inform the participants to rectify those errors.
5. Static code Review
This is a systematic review of the software source code without executing the
code. It checks the syntax of the code, coding standards, code optimization, etc.
This is also termed as white box testing. This review can be done at any point
during development.
2. Difference between Static and Dynamic Testing

Static Testing Dynamic Testing

Static testing was done without Dynamic testing is done by executing
executing the program the program.
Static testing checks the code, Dynamic testing checks the functional
requirement documents, and design behavior of software system,
documents to find errors memory/CPU usage and overall
performance of the system.
Static testing is about the Dynamic testing is about finding and
prevention of defects fixing the defects.
Static testing does the verification Dynamic testing does the validation
process process.
Static testing is performed before Dynamic testing is performed after
compilation compilation
Static testing techniques are Dynamic testing techniques are
structural and statement coverage Boundary Value Analysis and
Equivalence Class Partitioning.
3. Explain the formula to calculate code coverage.
To calculate the code coverage percentage, simply use the following formula:
Code Coverage Percentage = (Number of lines of code executed by a testing
algorithm/Total number of lines of code in a system component) * 100.

Code Coverage Criteria

To perform code coverage analysis various criteria are taken into consideration. These
are the major methods/criteria which are considered.

1. Statement Coverage/Block coverage

The number of statements that have been successfully executed in the program
source code.
Statement Coverage = (Number of statements executed)/(Total Number of
statements)*100.

2. Decision Coverage/Branch Coverage

The number of decision control structures that have been successfully executed in
the program source code.

Decision Coverage = (Number of decision/branch outcomes exercised)/(Total

number of decision outcomes in the source code)*100.

3. Function coverage

The number of functions that are called and executed at least once in the source
code.
Function Coverage = (Number of functions called)/(Total number of
function)*100.
4. Condition Coverage/Expression Coverage

The number of Boolean condition/expression statements executed in the

conditional statement.

Condition Coverage = (Number of executed operands)/(Total Number of

Operands)*100.

4. Metrics of Code Complexity

The complexity of code considerably affects the efficiency of a software project.
Sometimes, it becomes so complicated that it can no longer support any significant
enhancement. In such situations, the only way to further improve the code is first to
reduce complexity.

The metrics used to measure code complexity

1. Source Lines of Code (SLOC) – It counts the number of lines in the source
code. It is the most straightforward metric used to measure the size of the
program. However, functionality and complexity do not relate that well as a
skilled developer might be able to deliver the same functionality with a
significantly smaller code.

2. Cyclomatic Complexity – This measures how much control flow exists in a

program. Since programs with more conditional logic are more complex,
measuring the level of complexity tells the developers how much need to be
managed. This is done by directly measuring the number of paths through the
code. Say a program is a graph of all possible operations. Then, complexity
measures the number of unique paths through that graph. Every if, while, or
for statement creates a new branch. It is even possible for one branch to
double the total number of paths. But the results from this method can
sometimes be very deceptive.

For example, a module can be complicated, but only have a few interactions with
other modules. On the other hand, a module can be simple but highly coupled with
external modules. The higher the communication with external modules, the higher
the complexity of the codebase. Complexity metrics will look bad in the first case. In
the second case, the metrics will look good, but the code will be quite complex.
Therefore, it is crucial to measure the coupling and cohesion of modules. Only then
can we get an accurate system-level complexity measure.

3. Halstead Volume – This metric measures how much information is in the

source code. It looks at how many variables are used and how often they are
used in programs and functions. Since these additional pieces of data affect
data flow, programmers must learn them.

4. Maintainability Index – It calculates the overall score of the maintainability

of a program. Maintainability index is more of an empirical measure,
unlike Cyclomatic complexity and Halstead volume. This index has been
developed over the years with consultants from Hewlett-Packard and its
 software teams. It weighs Cyclomatic complexity and Halstead volume against
the number of lines of code in the program. This analysis gives an overall
picture of software complexity.
5. What are the most significant benefits of measuring software complexity?

1. Dependable Testing – Measuring the complexity of the code tells the

developer how many paths there are in the code. Therefore, the developer
knows how many paths there are to test. This will help them calculate the
minimum number of tests required to cover the entire code.

2. Reduced Risk of Defects – One of the most famous sayings in the IT

industry is – “It’s harder to read code than to write it. Since code is read far
more than it is written, this saying is true. By reducing code complexity,
developers can reduce the risk of introducing more bugs. After all, a good
developer is never assessed by the lines of code they have written, but the
quality they have maintained.

3. Lower Maintenance Cost – By reducing complexity, we reduce the

probability of introducing defects. When the risk of potential bugs is
reduced, there are fewer defects to find. Therefore, maintenance cost
significantly reduces.

4. Greater Predictability – Measuring the complexity of code, helps

developers say how long a section of code takes to complete. This
knowledge allows organizations to predict better how long a release takes
to ship. Hence, businesses dependent on such software can better set their
goals and expectations. It also allows development teams to set more
realistic forecasts and budgets.

15 marks

1. How to calculate statement coverage, branch/decision coverage, path coverage?

Example
Read X
Read Y
IF X+Y > 10 THEN
Print “Large”
ENDIF
If X > 50 THEN
Print “X Large”
ENDIF
For calculating Statement, Decision (Branch) and Path coverage, created a
flow chart for better understanding

1. Nodes ( , ) represent statement of code [E.g.: entry, exit,

decisions]
2. Edges ( ) represent links between nodes

Statement Coverage
Statement coverage is a white box testing technique where the all the
statements at the source code are executed at least once. To calculate
Statement Coverage, find out the shortest number of paths following which all
the nodes will be covered.

In the above example, in case of Yes, while traversing through each statement
of code and the traversing path (A1-B2-C4-5-D6-E8), all the nodes are
covered. So by traveling through only one path all the nodes (A, B, C, D and
E) are covered.
 Statement coverage (SC) =1

Branch/Decision Coverage
Branch coverage covers both ways (true and false). It covers all the possible
outcomes of each condition at least once. Branch coverage is a white box testing
method that ensures that every possible branch from each decision point in the
code is executed at least once. To calculate Branch coverage, find out the
minimum number of paths which ensure covering of all the edges.
In the above example, in case of traversing through a Yes decision, path
(A1-B2-C4-5-D6-E8), maximum numbers of edges (1, 2, 4, 5, 6 and 8) are
covered but edges 3 and 7 are left out. To cover these edges, we have to follow
(A1-B3-5-D7). So by travelling through two paths (Yes, No), all the edges (1, 2, 3,
4, 5, 6, 7, 8) are covered.
Branch Coverage /Decision Coverage (BC) = 2
Path Coverage

It is executed in such a way that every path is executed at least once. It ensures
that every statement in the program is guaranteed to be executed at least one time.
Path Coverage ensures covering all the paths from beginning to end, in the above
example. All the possible paths are:
A1-B3-5-D7
A1-B2-C4-5-D6-E8
A1-B2-C4-5-D7
A1-B3-5-D6-E8
Path coverage (PC) = 4
Condition Coverage
It is related to decision coverage but has better sensitivity to the control flow.
Condition coverage reports the true or false outcome of each condition. It
measures the conditions independently of each other. Multiple condition coverage
is also known as condition combination coverage.
Let us take an example to explain condition coverage:
IF ("X && Y")
In order to suffice valid condition coverage for this pseudo-code, the following
tests will be sufficient.
TEST 1: X=TRUE, Y=FALSE
TEST 2: X=FALSE, Y=TRUE