Module III

Software Implementation and Testing

Coding – The objective of the coding phase is to transform the design of
system into code in a high-level language , and then to unit test this code.
Good software development organizations normally require their
programmers to adhere to some well-defined and standard style of coding
called coding standards. Most software development organizations
formulate their own coding standards that suit them most, and require their
engineers to follow these standards rigorously. The purpose of requiring all
engineers of an organization to adhere to a standard style of coding is the
following:
• A coding standard gives a uniform appearance to the codes written by
different engineers.
• It enhances code understanding.
• It encourages good programming practices
writing an efficient software code requires a thorough knowledge of
programming.
this knowledge can be implemented by following a coding style which comprises
several guidelines that help in writing the software code efficiently and with
minimum errors.
these guidelines, known as coding guidelines, are used to implement individual
programming language constructs, comments, formatting and so on.

these guidelines, if followed, help in preventing errors, controlling the

complexity of the program, and increasing the readability and understandability
of a program.
There are certain rules for naming variables, functions and methods in the software code. these naming
conventions help software developers in understanding the use of a particular variable or function. the
guidelines used to assign a name to any variable, function and method are listed below.
1. all the variables, functions and methods should be assigned names that make the code more
understandable to the reader. by using meaningful names, the code can be self -explanatory, thus
minimizing the effort of writing comments for variables. for example, if two variables are required to
refer to ‘sales tax’ and ‘income tax’ they should be assigned names such as ‘sales Tax’ and ‘income
Tax’.
2. For names, a full description in a commonly spoken language (for example, English) should be used.
in addition, the use of abbreviations should be avoided. for example, variable names like ‘contact
Number’ and ‘address’ should be used instead of ‘cno’ and ‘add’.
3. Short and clear names should be assigned in place of long names. for example, ‘multiply The Two
Numbers’ can be shortened to ‘multiply Numbers’ as it is clear and short enough to be ex pressed in
reasonable length.
commonly used conventions for naming variables and constants are listed in
table.
Naming conventions for variables and constants
Variable Naming Conventions Constant Naming Conventions

The variable names should be in camel case All the names of constants should be in
letters starting with a lower case letter. For upper case. In case the name of constant is
example, use 'total Amount' instead of Total too long, it should be separated by an
Amount underscore. For example, sales tax rate
should be written as 'SALES TAX_RATE’
Variable Naming Conventions Constant Naming Conventions

The temporary storage variables that are The use of literal should be avoided. Literal
restricted to a segment of code should be numbers such as ‘15' used in the software
short. For example, the variable 'temp' can code confuses the reader. These numbers
be used for temporary variable. It is are counted as integers and result in wrong
important to note that single temporary output of the program. However, the
variable should not be reused in the same numbers 0 and 1 can be used as constants.
program. For example, variables ‘I’,’J’or 'k'
are declared while using loops

The use of numbers in naming

variables should be avoided. For
example, 'first Number' should be
used instead of 'number1'.
as with variables and constants, there are some guidelines that should be
followed while naming functions in the software code. these conventions are
listed below
* the names of functions should be meaningful and should describe the purpose
of the function with clarity and briefness. like variables, the name should be self
-explanatory no additional description about the task of that function is required.

* the function name should begin with a verb. for example, the verb ‘display’
can be used for the function that displays the output on the screen. in case the
verb itself is not descriptive an additional noun or adjective can be used with the
verb. for example, the function name ‘add Marks’ should be used to clarify the
function and its purpose.
* in case the function returns a Boolean value, the helping verbs ‘is’ and ‘has’
should be used as prefixes for the function name. for example, the function name
‘is Deposited’ or ‘has Deposited’ should be used for functions that return true or
false values
comments are helpful in proper understanding of the code segment used in
program. Commenting conventions should be used efficiently to make the code
easy to grasp.
Generally, two types of commenting conventions are used: file header comments
and trailing comments.
file header comments are useful in providing information related to a file as a
whole and comprise identification information such as date of creation, name of
creator and brief description of the software code.
trailing comments are used to provide explanation of a single line of code. these
comments are used to clarify the complex code. these also specify the function of
the abbreviated variable names that are not clear.

in some languages, trailing commands are used with the help of a double Slash
(//)..
The commenting conventions that are commonly followed in the software code are listed
below
• comments should be used with important segments of code and code segments that are
difficult to understand.
• comments should be used to include information that is clearly understandable from the
software.
• Comments should be separated from the code to enhance readability of the software code
• indentation should be used to highlight a nested block. some nested blocks can be made with
the help
• indentation should be used to highlight a nested block. some nested blocks can be made with
the help of ‘if else’ and ‘do while’ loops.
• indentation is required if the statement is large enough to fit in a single line.
• indentation should be consistent at the beginning and at the end of the braces in the program.
• there should be a space after placing a comma between two function arguments
• there should be no space between function name and parenthesis.
• there should be spaces to align the operators vertically to emphasize program structure and
 Implementing coding guidelines:

if coding guidelines are used in a proper manner, errors can be detected at the
time of writing the software code. such detection in early stages helps in
increasing the performance of the software as well as reducing the additional and
unplanned cost of correcting and removing errors.
Moreover, if a well defined coding guideline is applied, the program yields a
software system that is easy to comprehend and maintain. some of the coding
guidelines that are followed in a programming language are listed
below.
* all the codes should be properly commented before being submitted to the
review team.
* all curly braces should start from a new line.
* all class names should start with the abbreviation of each group. for example
AA and CM can be used instead of academic administration and course
management respectively
* errors should be mentioned in the following format: [error code]: [explanation]
for example 0102:null pointer exception, where 0102 indicates the error code
and null pointer exception is the name of the error.
* every ‘if’ statement should be followed by a curly braces, even if there exist
only a single statement.
*every file should contain information about the author of the file, modification
date and version information.
similarly some of the commonly used coding guidelines in a database (organized
collection of information that is systematically organized for easy access and
analysis) are listed below.
* Table name should start with TBL. for example TBL_students
* if table names contain one word, field names should start with the first three
characters of the name of the table. for example STU_ FIRSTNAME.
➢ every table should have a primary key.
* long data type (or database equivalent) should be used for the primary key.
Incremental Software development
The incremental build model is a method of software development where
the product is designed, implemented and tested incrementally (a little
more is added each time) until the product is finished. ... The product is
defined as finished when it satisfies all of its requirements.
 Incrementally developing code
The coding activity starts when some form of design has been done and the
specifications of the modules to be developed are available.
Here we discuss some effective processes that developers use for
incrementally developing code.
1)An incremental coding Process - The process followed by many
developers is to write the code for the currently assigned module, and
when done, perform unit testing on it and fix the bugs found. Then the
code is checked in the project repository to make it available to
others in the project.
Here write code for implementing only part of the functionality of the module.
This code is compiled and tested with some quick tests to check the code that has
been written so far.
When the code passes these tests, the developer proceeds to add further
functionality to the code, which is then tested again. In other words,
the code is developed incrementally, testing it as it is built.
The basic advantage of developing code incrementally with testing being done
after every round of coding is to facilitate debugging.
2)Test-Driven Development - Instead of writing code and then developing test
cases to check the code, in TDD it is the other way around—a programmer first
writes the test scripts, and then writes the code to pass the tests. The whole
process is done incrementally, with tests being written based on the
specifications and code being written to pass the tests.
In TDD, some type of prioritization for code development naturally happens.

It is most likely that the first few tests are likely to focus on using the main
functionality. Generally, the test cases for lower-priority features or functionality
will be developed later. Consequently, code for high-priority features will be
developed first and lower-priority items will be developed later.
This has the benefit that higher-priority items get done first, but has the drawback
that some of the lower-priority features or some special cases for which
test cases are not written may not get handled in the code.
3)Pair Programming – *In Pair Programming the coding work is
assigned not to an individual but to a pair of individuals.
*One person will type the program while the other will actively participate
and constantly review what is being typed. When errors are noticed, they are
pointed out and corrected. When needed, the pair discusses the algorithms,
data structures, or strategies to be used in the code to be written. The roles
are rotated frequently making both equal partners and having similar roles.
 Managing Evolving Code
During this development the code undergoes changes. Besides the changes due to
the development process, code changes are also needed due to changes in
module specifications. In such a dynamic scenario, managing evolving code is a
challenge.
Here we Discuss two methods.
1)Source code Control and Build - In a project many different people develop
source code. Each programmer creates different source files, which are
eventually combined together to create executables. Programmers keep changing
their source files as the code evolves.
* A modern source code control system contains a repository, which is essentially
a controlled directory structure, which keeps the full revision history of all the
files produced by the different programmers in the project team.
* For a project, a repository has to be set up with permissions for different people
in the project. The files the repository will contain are also specified.
Programmers use the repository to make their source file changes available, as
well as obtain other source files.
*Some of the types of commands that are generally performed by a programmer
are:
a) Get a local copy - A programmer in a project works on a local copy of the file.
Commands are provided to make a local copy from the repository. Making a
local copy is generally called a checkout. A user will get the latest copy of the
file. However, if a user wants, any older version of a file can be obtained from
the repository, as the complete history is maintained. Many users can check out a
file.
b) Make changes to file(s) - The changes made to the local file by a programmer
remain local until the changes are committed back on the repository. By
committing the changes made to the local file are made to the repository, and are
hence available to others. This operation is also referred to as check in.

c) Update a local copy - Changes committed by project members to the

repository are not reflected in the local copies that were made before the changes
were committed. For getting the changes, the local copies of the files have to be
updated. By an update, all the changes made to the files are reflected in the local
copy.

d) Get reports - Source control tools provide a host of commands to provide

different reports on the evolution of the files. These include reports like the
difference between the local file and the latest version of the file, all changes
made to a file along with the dates and reasons for change.
2)Refactoring - *coding often involves making changes to some existing code.
enhancing the code to accommodate required changes becomes more complex,
time consuming, and error prone. In other words, the productivity and quality
start decreasing.
Refactoring is the technique to improve existing code and prevent this design
decay with time.
Testing
The process or method of finding error/s in a software application or program
so that the application functions according to the end user's requirement is
called software testing.

Software testing is the process of verifying a system with the purpose of

identifying any errors, gaps or missing requirement versus the actual
requirement. Software testing is broadly categorized into two types –

functional testing and non-functional testing.

When to start test activities: Testing should be started as early as possible
to reduce the cost and time to rework and produce software that is bug-free
so that it can be delivered to the client.

However, in Software Development Life Cycle (SDLC), testing can be

started from the Requirements Gathering phase and continued till the
software is out there in productions. It also depends on the development
model that is being used.
Who does Testing
It depends on the process and the associated stakeholders of the project(s). In
the IT industry, large companies have a team with responsibilities to evaluate the
developed software in context of the given requirements. Moreover, developers
also conduct testing which is called Unit Testing. In most cases, the following
professionals are involved in testing a system within their respective capacities:
• Software Tester
• Software Developer
• Project Leader/Manager
• End User
Different companies have different designations for people who test the
software on the basis of their experience and knowledge such as Software
Tester, Software Quality Assurance Engineer etc.
Unit Testing
Software products are normally tested first at the individual component
(or unit) level. This is referred to as testing in the small or unit testing. After
testing all the
components individually, the components are slowly integrated and tested
at each level of integration (integration testing). Finally, the fully integrated
system is tested (called system testing). Integration and system testing are
known as testing in the large.
Unit testing -A testing technique using which individual modules are tested to
determine if there are any issues by the developer himself. It is concerned with
functional correctness of the standalone modules.
The main aim is to isolate each unit of the system to identify, analyze and fix the
defects. Unit testing is undertaken after a module has been coded and successfully
reviewed. Unit testing (or module testing) is the testing of different units (or modules)
of a system in isolation. Driver and Stub modules
In order to test a single module, a complete environment is needed to provide all that is
necessary for execution of the module. That is, besides the module under test itself, the
following steps are needed in order to be able to test the module:
• The procedures belonging to other modules that the module under test calls.
• Nonlocal data structures that the module accesses.
• A procedure to call the functions of the module under test with appropriate parameters.
Modules required to provide the necessary environment (which either call or are called
by the module under test) is usually not available until they too have been unit tested,
stubs and drivers are designed to provide the complete environment for a module.
Stub - A stub procedure is a dummy procedure that has the same I/O parameters as the
given procedure but has a highly simplified behavior. For example, a stub procedure
may produce the expected behavior using a simple table lookup mechanism.
Driver - A driver module contain the nonlocal data structures accessed by
the module under test, and would also have the code to call the different
functions of the module with appropriate parameter values for testing.
Unit Testing - Advantages:
Reduces Defects in the Newly developed features or reduces bugs when
changing the existing functionality.
• Reduces Cost of Testing as defects are captured in very early phase.
• Improves design and allows better refactoring of code.
• Unit Tests, when integrated with build gives the quality of the build as
well
Unit Testing Techniques:
• Black Box Testing - Using which the user interface, input and output
are tested.
• White Box Testing - used to test each one of those functions
behavior is tested.
• Gray Box Testing - Used to execute tests, risks and assessment
methods.
Code Inspection and Reviews

This technique is a formal and systematic examination of the source code to

detect errors. The different stages in this process are:
planning, self-review, group review meeting, and rework and follow-up.
Key characteristics of code inspection
1) Code inspection is conducted by programmers and for programmers.
2) It is a structured process with defined roles for the participants.
3) The focus is on identifying defects, not fixing them.
4) Inspection data is recorded and used for monitoring the effectiveness of the
inspection process.
During this process, the software is presented to the project managers and the
users for a comment of approval. Before providing any comment, the inspection
team checks the source code for errors. Generally, this team consists of the
following.

1. Moderator: Conducts inspection meetings, checks errors-, and ensures

that the inspection process is followed.
2. Reader: Paraphrases the operation of the software code.
3. Recorder: Keeps record of each error in the software code. This frees the
the task of other team members to think deeply about the software code.
4.Author: Observes the code inspection process silently and helps only
when explicitly required. The role of the author is to understand the errors
found in the software code.
As mentioned above, the reader paraphrases the meaning of small sections of code during the
code inspection process. In other words, the reader translates the sections of code from a
computer language to a commonly spoken language (such as English). The inspection process
is carried out to check whether the implementation of the software code is done according to
the user requirements. Generally, to conduct code inspections the following steps are
performed.
1. Planning: After the code is compiled and there are no more errors and warning messages in
the software code, the author submits the findings to the moderator who is responsible for
forming the inspection team. After the inspection team is formed, the moderator distributes the
listings as well as other related documents like design documentation to each team member.
The moderator plans the inspection meetings and coordinates with the team members.
2. Overview: This is an optional step and is required only when the inspection team members
are not aware of the functioning of the project. To familiarize the team members, the author
provides details to make them understand the code.
3. Preparation(Self –Review): Each inspection team member individually examines the code
and its related materials. They use a checklist to ensure that each problem area is checked.
Each inspection team member keeps a copy of this checklist, in which all the problematic areas
are mentioned. fig
4. Inspection meeting(Group-Review Meeting): This is carried out with all team members to
review the software code. The moderator discusses the code under review with the inspection
team members. There are two checklists for recording the result of the code inspection, namely,
code inspection checklist and inspection error list. The code inspection checklist contains a
summary of all the errors of different types found in the software code. This checklist is used to
understand the effectiveness of inspection process. The inspection error list provides the details
of each error that requires rework. Note that this list contains details only of those errors that
require the whole coding process to be repeated.
All errors in the checklist are classified as major or minor. An error is said to be major if it
results in problems and later comes to the knowledge of the user. On the other hand, minor
errors are spelling errors and noncompliance with standards. The classification of errors is
useful when the software is to be delivered to the user and there is little time to review all the
errors present in the software code.
At the conclusion of the inspection meeting, it is decided whether the code should be accepted
in the current form or sent back for rework. In case the software code needs reworking, the
author makes all the suggested corrections and then compiles the code. When the code becomes
errorfree, it is sent back to the moderator. The moderator checks the code that has been
reworked. If the moderator is completely satisfied with the software code, inspection becomes
formally complete and the process of testing the software code begins.
Testing Concepts
1)Error ,Fault ,Failure
Error - is deviation from actual and expected value. It represents mistake made
by people.
Fault – is a condition that a causes a system to fail in performing its required
function. It is incorrect step, process or data definition in a computer program
which causes the program to behave in an unintended or unanticipated manner. It
is the result of the error.
This is synonymous with bug or defect. Bug is a fault in the program which
causes the program to behave in an unintended or unanticipated manner. It is an
evidence of fault in the program.
Defect - is an error in coding or logic that causes a program to malfunction or to
produce incorrect/unexpected results. A defect is said to be detected when a
failure is observed.
Failure - is the inability of a system or a component to perform its required
functions within specified performance requirements. Failure occurs when fault
executes.
Testing only reveals the presence of faults. The actual faults are identified by
separate activities referred as Debugging.
Example I wrote a C program as mentioned below:Add two numbers
program
When you compile and run this program you see the printed statement as below:
The addition of 5 + 3 = 2.
So after compiling and running this program we realize the program has failed to
do what it was supposed to do.
The program was supposed to add two numbers but it certainly did not add 5 and
3. 5 + 3 should be 8, but the result is 2. There could be various reasons as to why
the program displays the answer 2 instead of 8. For now we have detected a
failure. As the failure has been detected a defect can be raised
2)Test Case,Test suite,Test Harness
Test case - This is the triplet [I,S,O], where I is the data input to the system, S is
the state of the system at which the data is input, and O is the expected output of
the system.
Test suite - This is the set of all test cases with which a given software product is
to be tested.
Test Harness – With automated testing ,a test case typically a function call which
does all the activities of test case. A testing framework some times called Test
Harness. Test harness enables the automation of tests. It refers to the system test
drivers and other supporting tools that requires to execute tests. It provides stubs
and drivers which are small programs that interact with the software under
test.Test harness execute tests, by using a test library and generates a report. With
a test frame work ,attest suite is defined once , and then whenever needed,
complete testing can done by click of a button or giving a command.
Verification and Validation
Verification is the process of determining whether the output of one phase of
software development conforms to that of its previous phase, whereas
validation is the process of determining whether a fully developed system
conforms to its requirements specification. Thus while verification is concerned
with phase containment of errors, the aim of validation is that the final product
be error free.

3)Psychology of testing A basic purpose of testing is to detect the errors that

may be present in the program. Hence, one should not start testing with the
intent of showing that a program works; rather the intent should be to show that
a program does not work; to reveal any defect that may exist. Due to this,
testing has also been defined as the process of executing a program with the
intent of finding errors.
4)Levels of Testing - Testing is usually relied upon to detect the faults
remaining from earlier stages, in addition to the faults introduced during coding
itself. Due to this, different levels of testing are used. The basic levels are unit
testing, integration testing, system testing, and acceptance testing.
Unit Testing - The first level of testing is called unit testing, is essentially for
verification of the code produced by individual programmers, and is typically
done by the programmer of the module.
Integration Testing - The next level of testing is often called integration testing.
In this, many unit tested modules are combined into subsystems, which are then
tested. The goal here is to see if the modules can be integrated properly. Hence,
the emphasis is on testing interfaces between modules. This testing activity can
be considered testing the design.
System Testing and Acceptance Testing - The next levels are system testing
and acceptance testing. Here the entire software system is tested.
The reference document for this process is the requirements document, and the
goal is to see if the software meets its requirements. Acceptance testing is often
performed with realistic data of the client to demonstrate that the software is
working satisfactorily.
Acceptance testing essentially tests if the system satisfactorily solves the
problems for which it was commissioned. These levels of testing are performed
when a system is being built from the components that have been coded.
Regression Testing - There is another level of testing, called regression testing,
that is performed when some changes are made to an existing system. We know
that changes are fundamental to software; any software must undergo changes.
However, when modifications are made to an existing system, testing also has to
be done to make sure that the modification has not had any undesired side effect
of making some of the earlier services faulty. This is the task of regression
testing.
For regression testing, some test cases that have been executed on the old system
are maintained, along with the output produced by the old system. These test
cases are executed again on the modified system and its output compared with the
earlier output to make sure that the system is working as before on these test
cases.
 Testing Process
The basic goal of the software development process is to produce
software that has no errors or very few errors. for a project consist of three
high-level tasks – test planning , test case design and test execution.
1) Test Plan - Test planning, the most important activity to ensure that
there is initially a list of tasks and milestones in a baseline plan to track the
progress of the project. It also defines the size of the test effort.
Test Planning Activities:
• To determine the scope and the risks that need to be tested and that are NOT
to be tested.
• Documenting Test Strategy.
• Making sure that the testing activities have been included.• Deciding Entry
and Exit criteria.
• Evaluating the test estimate.
• Planning when and how to test and deciding how the test results will be
evaluated, and defining test exit criterion.
• Ensuring that the test documentation generates repeatable test assets.
2) Test case Design - Design The test plan focuses on how the testing for the
project will proceed, which units will be tested, and what approaches (and tools)
are to be used during the various stages of testing.
Test case design has to be done separately for each unit. Based on the approach
specified in the test plan, and the features to be tested, the test cases are designed
and specified for testing the unit. Test case specification gives, for each unit to
be tested, all test cases, inputs to be used in the test cases, conditions being
tested by the test case, and outputs expected for those test cases. If test cases are
specified in a document.
Test case design is a major activity in the testing process.
Exhaustive testing of almost any non-trivial system is impractical due to the fact
that the domain of input data values to most practical software systems is either
extremely large or infinite. Therefore, we must design an optional test suite that
is of reasonable size and can uncover as many errors existing in the system as
possible.
Actually, if test cases are selected randomly, many of these randomly selected test
cases do not contribute to the significance of the test suite, i.e. they do not detect
any additional defects not already being detected by other test cases in the suite.
Thus, the number of random test cases in a test suite is, in general, not an
indication of the effectiveness of the testing. In other words, testing asystem using
a large collection of test cases that are selected at random does not guarantee that
all (or even most) of the errors in the system will be uncovered. Consider the
following example code segment which finds the greater of two integer values x
and y. This code segment has a simple programming error.
If (x>y) max = x;
else max = x;
For the above code segment, the test suite, {(x=3,y=2);(x=2,y=3)} can
detect the error, whereas a larger test suite {(x=3,y=2);(x=4,y=3);(x=5,y=1)}
does not detect the error. So, it would be incorrect to say that a larger test
suite would always detect more errors than a smaller one, unless of course
the larger test suite has also been carefully designed. This implies that the
test suite should be carefully designed than picked randomly. Therefore,
systematic approaches should be followed to design an optimal test suite. In
an optimal test suite, each test case is designed to detect different errors.
There are some good reasons why test cases are specified before they are used
for testing.

* It is known that effectiveness of testing depends very heavily on the exact

nature of the test cases Evaluation of test cases is often done through test case
review. As for any review, a formal document or work product is needed, for
review of test cases, the test case specification document is required.
* By reviewing the conditions being tested by the test cases, the reviewers can
also check if all the important conditions are being tested.
* The tester can see the testing of the unit in totality and the effect of the total set
of test cases.
Test case design techniques example– Boundary value analysis,equivalence class
partitioning,statement coverage,branch coverage, path coverage etc
3)Test case Execution - With the specification of test cases, the next step in the testing
process is to execute them. . The test case specifications only specify the set of test cases for
the unit to be tested. It may also require modules to set up the environment as stated in the
test plan and test case specifications. Only after all these are ready can the test cases be
executed.
During test case execution, defects are found. These defects are then fixed and tesing is done
again to verify the fix. . Often the person who fixes a defect is not the person who finds or
reports the defect.
Let us understand the life cycle of a defect.
* A defect can be found by anyone at anytime. When a defect is found, it is logged in a defect
control system, along with sufficient information about the defect. The defect is then in the
state “submitted.
* The job of fixing the defect is then assigned to some person, who is generally the author of
the document or code in which the defect is found. The assigned person does the debugging
and fixes the reported defect, and the defect then enters the “fixed” state.
* The successful fixing of the defect is verified. This verification may be done by another
person (often the submitter), or by a test team, and typically involves running some tests.
Once the defect fixing is verified, then the defect can be marked as “closed.
Black-Box Testing(functional testing)
The technique of testing without having any knowledge of the interior workings of the application is
called black-box testing. The tester is oblivious to the system architecture and does not have access
to the source code. Typically, while performing a black-box test, a tester will interact with the
system's user interface by providing inputs and examining outputs without knowing how and where
the inputs are worked upon.
Advantages
1)Well suited and efficient for large code segments.
2)Code access is not required.
3) Clearly separates user's perspective from the developer's perspective through visibly defined
roles.
4) Large numbers of moderately skilled testers can test the application with no knowledge of
implementation, programming language, or operating systems
Disadvantages
1)Limited coverage, since only a selected number of test scenarios is actually performed.
2) Inefficient testing, due to the fact that the tester only has limited knowledge about an application.
3) Blind coverage, since the tester cannot target specific code segments or error-prone areas.
4) The test cases are difficult to design.
White-Box Testing (structural testing)
White-box testing is the detailed investigation of internal logic and structure of the code. White-box
testing is also called glass testing or open box testing. In order to perform white-box testing on an
application, a tester needs to know the internal workings of the code.The tester needs to have a look
inside the source code and find out which unit/chunk of the code is behaving inappropriately.
Advantages
1) As the tester has knowledge of the source code, it becomes very easy to find out which type of data
can help in testing the application effectively.
2) It helps in optimizing the code.
3) Extra lines of code can be removed which can bring in hidden defects.
4) Due to the tester's knowledge about the code, maximum coverage is attained during test scenario
writing.
Disadvantages
1) Due to the fact that a skilled tester is needed to perform white-box testing, the costs are increased.
2) Sometimes it is impossible to look into every nook and corner to find out hidden errors that may
create problems, as many paths will go untested.
3) It is difficult to maintain white-box testing, as it requires specialized tools like code analyzers and
debugging tools.
Black box test case Design techniques
1) Equivalence class partitioning 2) Boundary value analysis
3) Pairwise Testing 4)special cases 5) State based Testing
➢ EquivalenceEquivalence Class Partitioning
In this approach, the domain of input values to a program is partitioned into a set of
equivalence classes. This partitioning is done such that the behavior of the program is
similar for every input data belonging to the same equivalence class. The main idea
behind defining the equivalence classes is that testing the code with any one value
belonging to an equivalence class is as good as testing the software with any other
value belonging to that equivalence class. Equivalence classes for a software can be
designed by examining the input data and output data.
The following are some general guidelines for designing the equivalence classes
1. If the input data values to a system can be specified by a range of values, then one
valid and two invalid equivalence classes need to be defined. For example, if the
equivalence class is the set of integers in the range 1 to 10 (i.e., [1,10]), then the
invalid equivalence classes are [−∞,0], [11,+∞].
Example#1: For a software that computes the square root of an input
integer which can assume values in the range of 0 to 5000, there are three
equivalence classes: The set of negative integers, the set of integers in the
range of 0 and 5000, and the integers larger than 5000. Therefore, the test
cases must include representatives for each of the three equivalence
classes and a possible test set can be: {-5,500,6000}.
➢ Boundary Value Analysis
A type of programming error frequently occurs at the boundaries of different
equivalence classes of inputs. The reason behind such errors might purely be
due to psychological factors. Programmers often fail to see the special
processing required by the input values that lie at the boundary of the different
equivalenceclasses. For example, programmers may improperly use < instead
of <=, or conversely <= for <. Boundary value analysis leads to selection of test
cases at the boundaries of the different equivalence classes.
Example: For a function that computes the square root of integer values in the
range of 0 and 5000, the test cases must include the following values: {0, -
1,5000,5001}.
➢ Pairwise Testing- also known as All-pairs testing is a testing approach taken for testing the
software using combinatorial method. It's a method to test all the possible discrete combinations
of the parameters involved.
Assume we have a piece of software to be tested which has got 10 input fields and 10 possible
settings for each input field, then there are possible inputs to be tested. In this case, exhaustive
testing is impossible even if we wish to test all combinations.-this apporoach is combinatorial
testing.It is not feasible. For finding double-mode faults , we need not test the system with all
combinations of parameter values, but need to test all combinations of values for each pair of
parameters .This is called Pairwise Testing
As an example, consider a software product being developed for multiple platforms that uses the
browser as its interface. Suppose the software is being designed to work for three different
operating systems and three different browsers. In addition, as the product is memory intensive
there is a desire to test its performance under different levels of memory.
Operating System: Windows, Solaris, Linux
Memory Size: 128M, 256M, 512M
Browser: IE, Netscape, Mozilla
Each of them can have three values which we will refer to as a1 , a2 , a3 , b1 , b2 , b3 , and c1 ,
c2 , c3 . The total number of pairwise combinations is 9 * 3 = 27.
Pairwise testing is a practical way of testing large software systems that have
many different parameters with distinct functioning expected for different values

➢ Special Cases (also called Error Guessing)- It has been seen that programs
often produce incorrect behavior when inputs form some special cases.
For example, in an arithmetic routine, if there is a division and the divisor is
zero, some special action has to be taken, which could easily be forgotten by the
programmer. These special cases form particularly good test cases, which can
reveal errors that will usually not be detected by other test cases. Special cases
will often depend on the data structures and the function of the module. There
are no rules to determine special cases, and the tester has to use his intuition and
experience to identify such test cases.
Psychology is particularly important for error guessing. The tester should play
the “devil’s advocate” and try to guess the incorrect assumptions the programmer
could have made handled incorrectly. Then test cases are written for these
situations.
➢ State based Testing - State Transition testing, a black box testing technique, in
which outputs are triggered by changes to the input conditions or changes to 'state'
of the system.
There are some systems that are essentially stateless in that for the same inputs
they always give the same outputs or exhibit the same behavior. At a smaller level,
most functions are supposed to behave in this manner.
There are, however, many systems whose behavior is state based in that for
identical inputs they behave differently at different times and may produce
different outputs. The reason for different behavior is that the state of the system
may be different. The state of the system depends on the past inputs the system
has received. Theoretically, any software that saves state can be modeled as a state
machine. . A state model for a system has four components:
1.States - Represent the impact of the past inputs to the system.
2. Transitions - Represent how the state of the system changes from one state to
another in response to some events.3. Events - Inputs to the system.
4. Actions - The outputs for the events.
The state model shows what state transitions occur and what actions are
performed in a system in response to events.

When a state model is built from the requirements of a system, we can only
include the states, transitions, and actions that are stated in the requirements or
can be inferred from them. If more information is available from the design
specifications, then a richer state model can be built.

Sometimes making the state model may require detailed information about the
design of the system. Due to this, the state-based testing may be considered as
somewhat between black-box and white-box testing. Such strategies are
sometimes called gray-box testing.
 Deriving Test cases:
Understand the various state and transition and mark each valid and invalid
state
• Defining a sequence of an event that leads to an allowed test ending state
• Each one of those visited state and traversed transition should be noted
down
• Steps 2 and 3 should be repeated until all states have been visited and all
transitions traversed
• For test cases to have a good coverage, actual input values and the actual
output values have to be generated
White box testing strategy –
Basic concepts –strategy can either be fault-based or coverage based
1.Fault-based testing- targets to detect certain types of faults. Example mutation testing
a)mutation testing - After the initial testing is complete, mutation testing is taken up.
The idea behind mutation testing is to make few arbitrary changes to a program at a
time. Each time the program is changed, it is called as a mutated program and the
change effected is called as a mutant.
A mutated program is tested against the full test suite of the program. If there exists at
least one test case in the test suite for which a mutant gives an incorrect result, then the
mutant is said to be dead. If a mutant remains alive even after all the test cases have
been exhausted, the test data is enhanced to kill the mutant. The process of generation
and killing of mutants can be automated by predefining a set of primitive changes that
can be applied to the program. These primitive changes can be alterations such as
changing an arithmetic operator, changing the value of a constant, changing a data type,
etc.
disadvantage of the mutation-based testing approach is that it is computationally very
expensive.
2.Coverage based testing- attempts to execute or cover certain elements of a
program. Example control flow based testing includes statement
coverage ,branch coverage , path coverage.
Testing criterion for Coverage based testing – the set of specific program
elements that a testing strategy requires to be executed.
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. When two testing strategies detect errors that are different at
least with respect to some types of errors, then they are called complementary.
Control flow based criteria - Let the control flow graph (or simply flow graph)
of a program P be G. A node in this graph represents a block of statements that is
always executed together.
Let the control flow graph (or simply flow graph) of a program P be G.
A node in this graph represents a block of statements that is always executed
together, i.e., whenever the first statement is executed, all other statements are
also executed. An edge (i, j) (from node i to node j) represents a possible transfer
of control after executing the last statement of the block represented by node i to
the first statement of the blockrepresented by node j. A node corresponding to a
block whose first statement is the start statement of P is called the start node of
G, and a node corresponding to a block whose last statement is an exit statement
is called an exit node .

A path is a finite sequence of nodes (n1 , n2 , ..., nk ), k > 1, such that there is an
edge (ni , ni+1 ) for all nodes ni in the sequence (except the last node nk ). A
complete path is a path whose first node is the start node and the last node is an
exit node.
1)Statement coverage(all nodes criterion) - the simplest coverage criterion is
statementcoverage, which requires that each statement of the program be executed at
least once during testing. In other words, it requires that the paths executed during
testing include all the nodes in the graph. This is also called the all-nodes criterion.
This coverage criterion is not very strong, and can leave errors undetected. For example,
if there is an if statement in the program without having an else clause, No test case is
needed that ensures that the condition in the if statement evaluates to false. This is a
serious shortcoming because decisions in programs are potential sources of errors.
As an example, consider the following function to compute the absolute value of a
number:
int abs (x)
int x;
{ if (x >= 0) x = 0 - x;
return (x) }
This program is clearly wrong. Suppose we execute the function with the set of test
cases { x=0 } (i.e., the set has only one test case). The statement coverage criterion will
be satisfied by testing with this set, but the error will not be revealed.
2)Branch coverage -branch coverage requires that each decision in the
program be evaluated to true and false values at least once during testing.
Testing based on branch coverage is often called branch testing. The
100% branch coverage criterion is also called the all-edges criterion .
Branch coverage implies statement coverage.

Consider the following code, and the test suite {5}.

if(x>2) x+=1;The test suite would achieve statement coverage. However, it

does not achieve branch coverage, since the condition (x > 2) is not made
false by any test case in the suite.
3)Multiple Condition coverage - The trouble with branch coverage comes if a decision has
many conditions in it (consisting of and and or). In such situations, a decision can evaluate to
true and false without actually exercising all the conditions.
Consider the composite conditional expression ((c1 .and.c2 ).or.c3). A test suite would achieve
MC coverage, if all the component conditions c1, c2 and c3 are each made to assume both true
and false values.
For example, consider the following function that checks the validity of a data item.
The data item is valid if it lies between 0 and 100.
int check(x)
int x;
{ if ((x >=0 ) && (x <= 200))
check = True;
else check = False; }
The module is incorrect, as it is checking for x ≤ 200 instead of 100
(perhaps a typing error made by the programmer). Suppose the module is tested with the
following set of test cases: { x = 5, x = -5 }. The branch coverage criterion will be satisfied for
this module by this set.
The condition (x ≤ 200) never evaluates to false during this test, hence the error
in this condition is not revealed. This problem can be resolved by requiring that
all conditions evaluate to true and false.
4)Path coverage(all paths criterion) - Path testing is a structural testing method
that involves using the source code of a program in order to find every possible
executable path. It helps to determine all faults lying within a piece of code. This
method is designed to execute all or selected path through a computer program.
The objective of path testing is to ensure that each independent path (basis
path)through the program is executed at least once.
An independent program path is one that traverses at least one new edge in the
flow graph.
Any software program includes, multiple entry and exit points. Testing each
of these points is a challenging as well as time consuming. Defines test cases
based on the flows or logical path that can be taken through the program. It
involves execution of all possible blocks in a program and achieves maximum
path coverage with least number of test cases. It is a hybrid of branch testing and
path testing methods.
The objective behind basis path testing is that it defines the number of
independent paths, thus the number of test cases needed can be defined explicitly
(maximizes the coverage of each test case). Rajib mall fig Fig.summarizes how
the CFG for these three types of statements can be drawn.