Software Engineering (3150711)

Unit 6: Software Coding & Testing

1. List set of guidelines for BVA. Also Explain merits and demerits of BVA.
 BVA means Boundary value analysis is done to check boundary conditions.
 A boundary value analysis is a testing technique in which the elements at the edge of the
domain are selected and tested.
 Using boundary value analysis, instead of focusing on input conditions only the test cases
from output domain are also derived.
 Boundary value analysis is a test case design technique that complements equivalence
partitioning technique.

Guidelines for boundary value analysis technique are:

1. If the input condition specified the range bounded by values x and y, then test cases
should be designed with values x and y. Also test cases should be with the values above
and below x and y.
2. If input condition specifies the number of values, then the test cases should be designed
with minimum and maximum values as well as with the values that are just above and
below the maximum and minimum should be tested.
3. If the output condition specified the range bounded by values x and y, then test case s
should be designed with values x and y. Also test cases should be with the values above
and below x and y.
4. If output condition specifies the number of values, then the test cases should be designed
with minimum and maximum values as well as with the values that are just above and
below the maximum and minimum should be tested.
5. If the internal program data structures specify such boundaries, then the test cases must be
designed such that the values at the boundaries of data structure can be tested.

Merits of BVA
 It is easier and faster to find defects using this technique. This is because the density
of defects at boundaries is more.
 Instead of testing will all set of test data, we only pick the one at the boundaries. So,
the overall test execution time reduces.
 The test cases generated through BVA are very small.
 BVA is the best approach in cases where the functionality of a software is based on
numerous variables representing physical quantities.
 Easy to understand
 Can control the expenses made on the testing
 BVA is the best technique to test the functionality of a test case
 Performs the best in revealing potential user input troubles

Dr. Subhash University, Junagadh Page 1

 Software Engineering (3150711)

 Crystal clear procedure and test cases

 Test cases generated by BVA are very small

Demerits of BVA
 This technique sometimes fails to test all the potential input values. And so, the
results are unsure.
 The dependencies with BVA are not tested between two inputs.
 This technique doesn’t fit well when it comes to Boolean Variables.
 It only works well with independent variables that depict quantity.

2. Explain White Box Testing With an Example.

 Also known as structural testing.
 White Box Testing is a software testing method in which the internal
structure/design/implementation of the module being tested is known to the tester.
 Focus is on ensuring that even abnormal invocations are handled gracefully.
 Using white-box testing methods, you can derive test cases that:
o Guarantee that all independent paths within a module have been exercised at least once
o Exercise all logical decisions on their true and false sides
o Execute all loops at their boundaries
o Exercise internal data structures to ensure their validity
 It is applicable to the following levels of software testing:
o Unit Testing: For testing paths within a unit
o Integration Testing: For testing paths between units
o System Testing: For testing paths between subsystems

Advantages:

 White box testing is very thorough as the entire code and structures are tested.
 It results in the optimization of code removing error and helps in removing extra lines
of code.
 It can start at an earlier stage as it doesn’t require any interface as in case of black box
testing.
 Easy to automate.

Disadvantages:

 Main disadvantage is that it is very expensive.

 Redesign of code and rewriting code needs test cases to be written again.
 Testers are required to have in-depth knowledge of the code and programming
language as opposed to black box testing.

Dr. Subhash University, Junagadh Page 2

 Software Engineering (3150711)

 Missing functionalities cannot be detected as the code that exists is tested.

 Very complex and at times not realistic.

Example of WhiteBox Testing:

 Consider the following piece of code:

Printme (int a, int b)

{
int result = a+ b;
If (result> 0)
Print ("Positive", result)
Else
Print ("Negative", result)
}

 The goal of WhiteBox testing in software engineering is to verify all the decision
branches, loops, and statements in the code.

3. What is Cyclomatic complexity? Define Steps to find Cyclomatic

complexity using flow graph.

 Cyclomatic complexity is a source code complexity measurement that is being correlated

to a number of coding errors. It is calculated by developing a Control Flow Graph of the
code that measures the number of linearly-independent paths through a program module.
 Lower the Program's Cyclomatic complexity, lower the risk to modify and easier to
understand. It can be represented using the below formula:

Cyclomatic complexity = E - N + 2*P

Where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points

Define Steps to find Cyclomatic complexity using flow graph:

1. Count the number of regions on the graph
2. No. of predicates
3. No of edges – no. of nodes + 2
 First and foremost start numbering the statement
 Now you can clearly see which statement executes first and which last etc. so
drawing the CFG becomes simple.

Dr. Subhash University, Junagadh Page 3

 Software Engineering (3150711)

 Now, to calculate Cyclomatic complexity you use one of three methods

4. Explain Formal Technical Review.

 A formal technical review (FTR) is a software quality control activity performed by
software engineers.
 The objectives of an FTR are:
1. To uncover errors in function, logic, or implementation; for any representation of
the software
2. To verify that the software under review meets its requirements
3. To ensure that the software has been represented according to predefined
standards
4. To achieve software that is developed in a uniform manner
5. To make projects more manageable
 During the FTR, a reviewer (the recorder) actively records all issues that have been raised.
 These are summarized at the end of the review meeting, and a reviewed issues list is
produced.
 In addition, a formal technical review summary report is completed.

Steps in FTR:

1. The review meeting.

2. Review reporting and record keeping.
3. Review guidelines.

Guideline for review may include following things:

1. Concentrate on work product only. That means review the product not the producers.
2. Set an agenda of a review and maintain it.
3. When certain issues are raised then debate or arguments should be limited. Reviews
should not ultimately results in some hard feelings.
4. Find out problem areas, but don’t attempt to solve every problem noted.
5. Take written notes (it is for record purpose)
6. Limit the number of participants and insists upon advance preparation.
7. Develop a checklist for each product that is likely to be reviewed.
8. Allocate resources and time schedule for FTRs in order to maintain time schedule.
9. Conduct meaningful trainings for all reviewers in order to make reviews effective.
10. Reviews earlier reviews which serve as the base for the current review being
conducted.

Dr. Subhash University, Junagadh Page 4

 Software Engineering (3150711)

5. Consider the program given below

void main()
{
int i,j,k;
readln(i,j,k);
if( (i < j) || ( i > k) )
{
writeln("then part");
if (j <k)
writeln ("j less then k");
else writeln ( " j not less then k");
}
else writeln( "else Part");
}
(i) Draw the flow graph.
(ii) Determine the cyclomatic complexity.
(iii) Arrive at all the independent paths.
 Draw the flow graph.

Dr. Subhash University, Junagadh Page 5

 Software Engineering (3150711)

 Determine the cyclomatic complexity.

Cyclomatic complexity = E - N + 2 = 12 - 10 + 2 = 4
 Arrive at all the independent paths.
Path1 : 1 2 3 9 10
Path2 : 1 2 4 5 7 8 10
Path3 : 1 2 4 5 6 8 10
Path4 : 1 2 3 4 5 7 8 10

6. What is mobile testing? Mention the challenges in mobile testing.

 Mobile application testing is a process by which application software developed for
handheld mobile devices is tested for its functionality, usability and consistency.
 Mobile application testing can be an automated or manual type of testing.
 There is change in behavior and usage pattern of mobile application.
 Testing mobile application is more complex and time consuming as compared to
traditional desktop and web applications.

Mobile app testing challenges:

 Multitude Mobile Devices
 Over 500m Android devices shipped since Android 1.0, about 220m iOS devices
have been shipped since 2007.
 These huge number of mobile devices availability ranging from handsets to smart
phones, to tabs, to pads and wearable tech provides a huge diversity of environments
which your mobile app faces.

 Device Fragmentation & Various OS Platforms

 Perhaps the most difficult aspect of the mobile testing matrix is device
fragmentation. Though the iOS device matrix is growing more than ever,
fragmentation is especially an issue for the Android operating system.
 Mobile application testing is also challenging, due to compatibility issues as a
mobile application can be deployed across devices which have different-
o Operating systems like iOS, Android, Blackberry, Windows etc.
o Versions of an operating system such as iOS 4.X, iOS 5.X, BB 4.X, 5.X and 6.X.

 Different Mobile App Types

 A mobile app can be a native app, a web app or a hybrid app which has both
contents.
 Testing of each such app type is different than another as their implementation is
quite different from one another.
 Numerous Test Interfaces
 Mobile emulators and simulators are the important testing tool and they enable us to
verify general functionality and perform regular regression testing.

Dr. Subhash University, Junagadh Page 6

 Software Engineering (3150711)

 The very character of emulators and simulators means testing is being conducted in
an environment which is not real.

 Variety of Testing Tools

 Summarizing the daunting complexity of mobile test automation, even more,
daunting is the huge availability of mobile test automation tools in the market.
 Free/Paid. For native app or web app? For Android or for iOS, so which is the one
automation tool for your mobile test automation needs, or the question is – Is there a
single tool for our Mobile Test automation needs?

7. Explain Integration testing.

 Integration testing is the process of testing the interface between two software units or
modules.
 A group of dependent components are tested together to ensure their quality of their
integration unit.
 The objective is to take unit tested components and build a program structure that has
been dictated by software design.
 The focus of integration testing is to uncover errors in:
o Design and construction of software architecture.
o Integrated function or operations at subsystem level.
o Interface and interactions between them.
o Resource integration and/or environment integration.
 The integration testing can be carried out using two approaches:
1. The non-incremental integration
2. Incremental integration
 The non-incremental integration is given by the “big bang” approach. All components
are combined in advance. The entire program is tested as a whole. And chaos usually
results. A set of errors is tested as a whole. Correction is difficult because isolation of
causes is complicated by the size of the entire program. Once these errors are corrected
new ones appear. This process continues infinitely.
Advantages of big-bang: This approach is simple.
Disadvantages: 1. It is hard to debug.
2. It is not easy to isolate errors while testing.
3. In this approach It is not easy to validate test result.
4. After performing testing, It is impossible to form on integrated system.
 An incremental construction strategy includes:
o Top down integration
o Bottom up integration
o Regression integration
o Smoke integration

Dr. Subhash University, Junagadh Page 7

 Software Engineering (3150711)

Top down integration:

 Testing take place from top to bottom.

 High level modules are tested first and then low-level modules and finally integrated the
low level modules to high level to ensure the system is working as intended.
 Stubs are used as a temporary module, if a module is not ready for integration testing.

Example:
 In the top-down integration testing, if depth-first approach is adopted then we will
start integration from module M1. Then we will integrate M2, then M3, M4, M5,
M6, and at last M7.

 In the top-down integration testing, if breadth-first approach is adopted, then we

will integrate module M1 first, then M2, M6. Then we will integrate module M3,
M4, M5, and at last M7.
Advantages:
 There is no need to write drivers.
 Interface errors are identified at an early stage and fault localization is also easier.
 Low-level utilities that are not important are not tested well and high-level testers
are tested well in an appropriate manner. Representation of test cases is easier and
simple once Input-Output functions are added.
Disadvantages:
 It requires a lot of stubs and mock objects.
 Representation of test cases in stubs can be not easy and might be difficult before
Input-Output functions are added.
 Low-level utilities that are important are also not tested well.

Dr. Subhash University, Junagadh Page 8

 Software Engineering (3150711)

Bottom up integration:

 Testing take place from bottom to up.

 Lowest level modules are tested first and then high-level modules and finally integrated
the high level modules to low level to ensure the system is working as intended.
 Drivers are used as a temporary module, if a module is not ready for integration testing.

Example
 In the last, modules or components are combined together to form cluster 1 and
cluster 2. After this, each cluster is tested with the help of a control program.
 The cluster is present below the high-level module or driver.
After testing, driver is removed and clusters are combined and moved upwards with
modules.

Advantages:
 It is easy and simple to create and develop test conditions.
 It is also easy to observe test results.
 It is not necessary to know about the details of the structural design.
 Low-level utilities are also tested well and are also compatible with the object -
oriented structure.
Disadvantages:
 Towards top of the Hierarchy, it becomes very complicated.
 There is no concept regarding early skeletal system.
 There will be an impact on sibling and higher-level unit tests due to changes.

Dr. Subhash University, Junagadh Page 9

 Software Engineering (3150711)

8. Compare and contrast alpha and beta testing.

Alpha Testing Beta Testing
 Alpha testing involves both the white  Beta testing commonly uses black-
box and black box testing. box testing.
 Alpha testing is performed by testers  Beta testing is performed by clients
who are usually internal employees who are not part of the organization.
of the organization.
 Alpha testing is performed at the  Beta testing is performed at the end-
developer’s site. user of the product.
 Alpha testing requires a testing  Beta testing doesn’t require a testing
environment or a lab. environment or lab.
 Alpha testing may require a long  Beta testing requires only a few
execution cycle. weeks of execution.
 Developers can immediately address  Most of the issues or feedback
the critical issues or fixes in alpha collected from the beta testing will
testing. be implemented in future versions of
the product.
 Multiple test cycles are organized in  Only one or two test cycles are there
alpha testing. in beta testing.
 The main goal is to evaluate the  The main goal is to evaluate
quality of the product customer satisfaction.
 Long execution cycles maybe require  Only a few weeks are required for
for alpha testing. the execution of beta testing.
 Alpha testing is conducting in the  Beta testing reversed of alpha
presence of developers and the testing.
absence of end-users.

9. Explain the process of code review.

 Code Review is carried out after the module is successfully compiled and all the syntax
errors have been eliminated.
 Code Reviews are extremely cost-effective strategies for reduction in coding errors and to
produce high quality code.
 Type of Code Review:
o Code Walk Through
o Code Inspection

Code Walk Through

 Code walk through is an informal code analysis technique.
 The main objectives of the walk through are to discover the algorithmic and logical errors
in the code.

Dr. Subhash University, Junagadh Page 10

 Software Engineering (3150711)

 A few members of the development team are given the code few days before the walk -
through meeting to read and understand code.
 Each member selects some test cases and simulates execution of the code by hand.
 The members note down their findings to discuss these in a walk-through meeting where
the coder of the module is present.

Code Inspection
 The aim of Code Inspection is to discover some common types of errors caused due to
improper programming.
 In other words, during Code Inspection the code is examined for the presence of certain
kinds of errors.
o For instance, consider the classical error of writing a procedure that modifies a
parameter while the calling routine calls that procedure with a constant actual
parameter.
o It is more likely that such an error will be discovered by looking for these kinds
of mistakes in the code.
 In addition, commitment to coding standards is also checked.

10. What are the different levels of testing? Briefly discuss the goal of each
level.
Different Levels of Testing:
 The levels of software testing involve the different methodologies, which can be used
while we are performing the software testing.
 In software testing, we have four different levels of testing, which are as discussed
below:
1. Unit Testing
2. Integration Testing
3. System Testing
4. Acceptance Testing

 As we can see in the above image that all of these testing levels have a specific objective
which specifies the value to the software development lifecycle.
 For our better understanding, let's see them one by one:

Level1: Unit Testing

 Unit testing is the first level of software testing, which is used to test if software modules
are satisfying the given requirement or not.

Dr. Subhash University, Junagadh Page 11

 Software Engineering (3150711)

 The first level of testing involves analyzing each unit or an individual component of
the software application.
 Unit testing is also the first level of functional testing. The primary purpose of executing
unit testing is to validate unit components with their performance.
 A unit component is an individual function or regulation of the application, or we can say
that it is the smallest testable part of the software. The reason of performing the unit
testing is to test the correctness of inaccessible code.
 Unit testing will help the test engineer and developers in order to understand the base of
code that makes them able to change defect causing code quickly. The developers
implement the unit.

Level2: Integration Testing

 The second level of software testing is the integration testing. The integration testing
process comes after unit testing.
 It is mainly used to test the data flow from one module or component to other
modules.
 In integration testing, the test engineer tests the units or separate components or modules
of the software in a group.
 The primary purpose of executing the integration testing is to identify the defects at the
interaction between integrated components or units.
 When each component or module works separately, we need to check the data flow
between the dependent modules, and this process is known as integration testing.
 We only go for the integration testing when the functional testing has been completed
successfully on each application module.
 In simple words, we can say that integration testing aims to evaluate the accuracy of
communication among all the modules.

Level3: System Testing

 The third level of software testing is system testing, which is used to test the software's
functional and non-functional requirements.
 It is end-to-end testing where the testing environment is parallel to the production
environment. In the third level of software testing, we will test the application as a
whole system.
 To check the end-to-end flow of an application or the software as a user is known
as System testing.
 In system testing, we will go through all the necessary modules of an application and test
if the end features or the end business works fine, and test the product as a complete
system.

Dr. Subhash University, Junagadh Page 12

 Software Engineering (3150711)

 In simple words, we can say that System testing is a sequence of different types of tests to
implement and examine the entire working of an integrated software computer system
against requirements.

Level4: Acceptance Testing

 The last and fourth level of software testing is acceptance testing, which is used to
evaluate whether a specification or the requirements are met as per its delivery.
 The software has passed through three testing levels (Unit Testing, Integration Testing,
System Testing). Some minor errors can still be identified when the end-user uses the
system in the actual scenario.
 In simple words, we can say that Acceptance testing is the squeezing of all the testing
processes that are previously done.
 The acceptance testing is also known as User acceptance testing (UAT) and is done by
the customer before accepting the final product.
 Usually, UAT is done by the domain expert (customer) for their satisfaction and checks
whether the application is working according to given business scenarios and real-time
scenarios.

11. Explain various coding standard.

Coding Standards:
 Any good software development approach suggests to adhere to some well - defined
standards or rules for coding. These rules are called coding standards.

1. Naming Conventions
 Following are some commonly used naming conventions in the coding.
o Package name and variable names should be in lower case.
o Variable names must not begin with numbers.
o The type name should be noun and it should start with capital letter.
o Constants must be in upper case (For example PI, SIZE).
o Method name must be given in lower case.
o The variables with large scope must have long name. For example count_total,
sum, Variables with short scope must have short name. For example i,j.
 The prefix is must be used for Boolean type of variables. For example isEmpty or is
Full.

2. Files
 Reader must get an idea about the purpose of the file by its name. In some
programming language like Java.
o The file extension must be java.

Dr. Subhash University, Junagadh Page 13

 Software Engineering (3150711)

o The name of the file and the class defined in the file must have the same
name.
o Line length in the file must be limited to 80 characters.

3. Commenting / Layout
 Comments are non executable part of the code. But it is very important because it
enhances the readability of the code. The purpose of the code is to explain the logic
of the program.
o Single line comments must be given by //
o For the names of the variables comments must be given.
o A black of comment must be enclosed within / and * /.

4. Statements
 There are some guidelines about the declaration and executable statements.
o Declare some related variables on same line and unrelated variables on
another line.
o Class variable should never be declared public.
o Make use of only loop control within the for loop.
o Avoid make use of break and continue statements in the loop.
o Avoid complex conditional expressions Make use of temporary variables
instead.
o Avoid the use of do while statement.
Advantages of Coding Standards:

1. Coding standard brings uniform appearance in system implementation.

2. The code becomes readable and hence can be understood easily.
3. The coding standard helps in adopting good programming practices.

12. Explain concept of test case.

 Test Case is a set of conditions or variables under which a tester will determine whether a
system under test satisfies requirements or works correctly.
 The process of developing test cases can also help find problems in the requirements or
design of an application.
 A test case is a defined format for software testing required to check if a particular
application/software is working or not.
 A test case consists of a certain set of conditions that need to be checked to test an
application or software i.e. in more simple terms when conditions are checked it checks
if the resultant output meets with the expected output or not.
 A test case consists of various parameters such as Id, condition, steps, input, expected
result, result, status, and remarks.

Dr. Subhash University, Junagadh Page 14

 Software Engineering (3150711)

Parameters of a Test Case:

 Module Name: Subject or title that defines the functionality of the test.
 Test Case Id: A unique identifier assigned to every single condition in a test case.
 Tester Name: The name of the person who would be carrying out the test.
 Test scenario: The test scenario provides a brief description to the tester, as in
providing a small overview to know about what needs to be performed and the small
features, and components of the test.
 Test Case Description: The condition required to be checked for a given software. for
eg. Check if only numbers validation is working or not for an age input box.
 Test Steps: Steps to be performed for the checking of the condition.
 Prerequisite: The conditions required to be fulfilled before the start of the test
process.
 Test Priority: As the name suggests gives the priority to the test cases as in which had
to be performed first, or are more important and which could be performed later.
 Test Data: The inputs to be taken while checking for the conditions.
 Test Expected Result: The output which should be expected at the end of the test.
 Test parameters: Parameters assigned to a particular test case.
 Actual Result: The output that is displayed at the end.
 Environment Information: The environment in which the test is being performed,
such as operating system, security information, the software name, software version,
etc.
 Status: The status of tests such as pass, fail, NA, etc.
 Comments: Remarks on the test regarding the test for the betterment of the softwa re.

Example:

Test Test Test Test Test Actual Status Remarks

Id Condition Steps Input Expected Result
Result
1. Checks if 1. abcdefghij Accepts Accepts Pass None
the Give klm for for
username input thirteen thirteen
field characters. characters.
accepts
the input
of thirteen
characters.

Dr. Subhash University, Junagadh Page 15

 Software Engineering (3150711)

13. What are the different testing strategies? Explain any one with suitable
example.
Testing strategies:
1. Unit Testing
2. Integration Testing
3. Validation Testing
4. System Testing

1. Unit testing
 Unit testing focus on the smallest unit of software design, i.e module or software
component.
 Test strategy conducted on each module interface to access the flow of input and output.
 The local data structure is accessible to verify integrity during execution.
 Boundary conditions are tested.
 In which all error handling paths are tested.
 An Independent path is tested.

 Drivers and stub software need to be developed to test incomplete software.

 The " driver " is a program that accepts the test data and prints the relevant results . And
the " stub " is a subprogram that uses the module interfaces and performs the minimal
data manipulation if required.

Dr. Subhash University, Junagadh Page 16

 Software Engineering (3150711)

 The unit testing is simplified when a component with high cohesion (with one function)
is designed. In such a design the number of test cases are less and easily predict or
uncover errors.

14. What is black box testing? What are the different black box testing
techniques?

 Black - box testing is also known as behavioural testing. It focuses only on the functional
requirements of the software.
 The black box testing helps the software developer to derive the sets of input conditions.
These input conditions exercise all the functional requirements for program.
 Black - box testing is a different approach and it cannot be the alternative or the
replacement of white - box testing approach It is a complementary testing method that
detects a different class of errors compared to white box testing methods.
 Following are categories of errors that can be detected by using black box testing
approach:
o The performance errors or the behavioural errors
o Missing or incorrectly defined functions
o Data structures incorrectly defined and external data base access errors,
o Errors occurred during initialization and termination.
o Errors occurred during interface.
 In contrast to white - box testing, where testing begins early in the testing. process, the
black box testing is applied in the final stages of testing.
 Different black - box testing methods are:
1. Graph - Based Testing Method

Dr. Subhash University, Junagadh Page 17

 Software Engineering (3150711)

2. Equivalence Partitioning
3. Boundary Value Analysis
4. Orthogonal Array Testing

Graph-Based Testing:

 This technique of Black box testing involves a graph drawing that depicts the link
between the causes (inputs) and the effects (output), which trigger the effects.
 This testing utilizes different combinations of output and inputs. It is a helpful
technique to understand the software’s functional performance, as it visualizes the flow
of inputs and outputs in a lively fashion.

Equivalence Class Partitioning:

Dr. Subhash University, Junagadh Page 18

 Software Engineering (3150711)

 This technique of Black box testing is widely used to write test cases. It can be useful
in reducing a broad set of possible inputs to smaller but effective ones.
 It is performed through the division of inputs as classes, and each class is given a value.
 It is applied when the need for exhaustive testing arises and for resisting the
redundancy of inputs.

BVA or Boundary Value Analysis:

 It is one among the useful and critical Black box testing technique that helps in
equivalence partitioning. BVA helps in testing any software having a boundary or
extreme values.
 This technique is capable of identifying the flaws of the limits of the input values rather
than focusing on the range of input value. Boundary Value Analysis also deals with
edge or extreme output values.

Orthogonal Array Testing

 In various applications, the input domain is relatively limited and hence orthogonal
array testing is a good option in such situations orthogonal array testing, the problems
in which the input domain is small but it is large enough to accommodate the
exhaustive testing.
 The orthogonal array testing approach is specially and in detecting that are caused by
the faulty logic within a software component.
 To explain the comparison between orthogonal array testing and more conventional
approaches, consider the following system in which there are three input values X, Y
and Z.
 All these input values have three discrete values associated with each of it. The
probability of test cases is 3
 In the figure, a geometric view of the possible test cases associated are explained by
considering the input values i.e. X, Y, and Z.

Dr. Subhash University, Junagadh Page 19

 Software Engineering (3150711)

 In the Figure, one input value at a time is changing in accordance with the input axis.
The results obtained are generally having less coverage of the input values.
 An L9 orthogonal array of test cases is created whenever an orthogonal array testing is
conducted. Generally a L9 orthogonal array has an important property called as
balancing property. In this the test coverage more complete with the input domain.

15. What is white box testing? What are the different coverage based testing
strategies.

 Also known as structural testing.

 White Box Testing is a software testing method in which the internal
structure/design/implementation of the module being tested is known to the tester.
 Focus is on ensuring that even abnormal invocations are handled gracefully.
 Using white-box testing methods, you can derive test cases that:
o Guarantee that all independent paths within a module have been exercised at
least once
o Exercise all logical decisions on their true and false sides
o Execute all loops at their boundaries
o Exercise internal data structures to ensure their validity
 It is applicable to the following levels of software testing:
o Unit Testing: For testing paths within a unit
o Integration Testing: For testing paths between units
o System Testing: For testing paths between subsystems

Dr. Subhash University, Junagadh Page 20

 Software Engineering (3150711)

White-box testing strategies:

 One white-box testing strategy is said to be stronger than another strategy, if all types of
errors detected by the first testing strategy is also detected by the second testing strategy,
and the second testing strategy additionally detects some more types of errors.

1. Statement coverage
2. Branch coverage
3. Path coverage

1. Statement coverage:

 In this technique, the aim is to traverse all statement at least once. Hence, each line
of code is tested. In case of a flowchart, every node must be traversed at least once.
Since all lines of code are covered, helps in pointing out faulty code.

2. Branch Coverage:

 In this technique, test cases are designed so that each branch from all decision points
are traversed at least once.
 In a flowchart, all edges must be traversed at least once.

Dr. Subhash University, Junagadh Page 21

 Software Engineering (3150711)

3. Basis Path Testing:

 In this technique, control flow graphs are made from code or flowchart and then
Cyclomatic complexity is calculated which defines the number of independent paths
so that the minimal number of test cases can be designed for each independent path.
Steps:
o Make the corresponding control flow graph
o Calculate the cyclomatic complexity
o Find the independent paths
o Design test cases corresponding to each independent path
 Flow graph, Cyclomatic Complexity and Graph Metrices are used to arrive at basis
path.

Flow graph notation: It is a directed graph consisting of nodes and edges. Each
node represents a sequence of statements, or a decision point. A predicate node is
the one that represents a decision point that contains a condition after which the
graph splits. Regions are bounded by nodes and edges.

Dr. Subhash University, Junagadh Page 22

 Software Engineering (3150711)

Cyclomatic Complexity: It is a measure of the logical complexity of the software

and is used to define the number of independent paths. For a graph G, V(G) is its
cyclomatic complexity.

Calculating V(G):

V(G) = P + 1, where P is the number of predicate nodes in the flow graph

V(G) = E – N + 2, where E is the number of edges and N is the total number of

nodes

V(G) = Number of non-overlapping regions in the graph

Example:

Dr. Subhash University, Junagadh Page 23

 Software Engineering (3150711)

V(G) = 4 (Using any of the above formulae)

No of independent paths = 4

P1: 1 – 2 – 4 – 7 – 8

P2: 1 – 2 – 3 – 5 – 7 – 8

P3: 1 – 2 – 3 – 6 – 7 – 8

P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8

Graph Matrix: A graph matrix is a square matrix whose size represents the number
of nodes in the control flow graph. If you do not know what control flow graphs are,
then read this article. Each row and column in the matrix identifies a node and the
entries in the matrix represent the edges or links between these nodes.
Conventionally, nodes are denoted by digits and edges are denoted by letters.

Example:

o Let’s convert this control flow graph into a graph matrix. Since the graph
has 4 nodes, so the graph matrix would have a dimension of 4 X 4. Matrix
entries will be filled as follows :
 (1, 1) will be filled with ‘a’ as an edge exists from node 1 to node 1
 (1, 2) will be filled with ‘b’ as an edge exists from node 1 to node
2. It is important to note that (2, 1) will not be filled as the edge is
unidirectional and not bidirectional

Dr. Subhash University, Junagadh Page 24

 Software Engineering (3150711)

 (1, 3) will be filled with ‘c’ as edge c exists from node 1 to node 3
 (2, 4) will be filled with ‘d’ as edge exists from node 2 to node 4(3,
4) will be filled with ‘e’ as an edge exists from node 3 to node 4
o The graph matrix formed is shown below :

16. What is Software Testing? What is the role of a Software Tester?

Compare Black Box and White Box Testing. OR Discuss the differences
between black box and white box testing.

Software Testing:
 Software testing is the process of evaluating and verifying that a software product or
application does what it is supposed to do.
 The benefits of testing include preventing bugs, reducing development costs and
improving performance.
 The purpose of software testing is to identify errors, gaps or missing requirements in
contrast to actual requirements.
Role of a Software Tester:
 Defining the testing activities for subordinates – testers or test engineers.
 All responsibilities of test planning.
 To check if the team has all the necessary resources to execute the testing activities.
 To check if testing is going hand in hand with the software development in all phases.
 Prepare the status report of testing activities.
 Required Interactions with customers.
 Updating project manager regularly about the progress of testing activities.

Dr. Subhash University, Junagadh Page 25

 Software Engineering (3150711)

Black Box Testing White Box Testing

 Black Box Testing is called  White Box Testing is called glass
behavioural testing. box testing.
 It is a way of software testing in  It is a way of testing the software in
which the internal structure or the which the tester has knowledge
program or the code is hidden and about the internal structure or the
nothing is known about it. code or the program of the software.
 It is mostly done by software testers.  It is mostly done by software
developers.
 No knowledge of implementation is  Knowledge of implementation is
needed. required.
 It can be referred to as outer or  It is the inner or the internal software
external software testing. testing.
 It is applicable to the higher levels of  It is generally applicable to the
testing of software. lower levels of software testing.
 It is also called closed testing.  It is also called as clear box testing.
 It is least time consuming.  It is most time consuming.

 During black box testing the program  White box testing lead to the test the
cannot be tested 100 percent. program thoroughly.
 This type of testing is suitable for  This type of testing is suitable for
large project. small project.
 Example: Search something on  Example: By input to check and
google by using keywords verify loops
 Black-box test design techniques-  White-box test design techniques-
 Decision table testing  Control flow testing
 All-pairs testing  Data flow testing
 Equivalence partitioning  Branch testing
 Error guessing

 It is less exhaustive as compared to  It is comparatively more exhaustive

white box testing. than black box testing.

Dr. Subhash University, Junagadh Page 26