Software Engineering and Project Management - A Beginner's Guide - Part 4

21CSC303J – SOFTWARE
ENGINEERING AND PROJECT
MANAGEMENT
UNIT IV

CODING STANDARDS
• Developers are given software design specifications in the form of use
cases, flow diagrams, UI mock ups, etc., and they are supposed to write a
code so that the built software matches these specifications.
• Converting the specifications into software code is totally dependent on
the construction team.
• How well they do it depends on their experience, skills and the process
they follow to do their job.
• Apart from these facilities, they also need some standards in their coding
so that the work is fast as well as has other benefits like maintainability,
readability and reusability (Figure in next slide).

CODING STANDARDS - SOURCE CODE
PREPARATION FROM SOFTWARE DESIGN

CODING STANDARDS
• At any time, a code written by a developer will always be different from that
written by any other developer.
• This poses a challenge in terms of comprehending the code while reusing the
code, maintaining it, or simply reviewing it.
• A uniform coding standard across all construction teams working on the
same project will make sure that these issues can be minimized if not
eliminated (Figure below - Software Construction Characteristics).
• Some of the coding standards include standards for code modularity, clarity,
simplicity, reliability, safety and maintainability.

CODING STANDARDS
SOFTWARE CONSTRUCTION CHARACTERISTICS

CODING STANDARDS
Software Construction characteristics
1) Modularity
• The produced software code should be modular in nature.
• Each major function should be contained inside a software code module.
• The module should contain not only structure, but it should also process
data.
• Each time a particular functionality is needed in the software
construction, it can be implemented using that particular module of
software code.
• This increases software code reuse and thus enhances productivity of
developers and code readability.

CODING STANDARDS
Software Construction characteristics (continued)
2).Clarity
• The produced code should be clear for any person who would read the
source code.
• Standard naming conventions should be used so that the code has
ample clarity.
• There should be sufficient documentation inside the code block, so that
anybody reading the code could understand what a piece of code is
supposed to do.
• There should also be ample white spaces in the code blocks, so that no
piece of code should look crammed. White spaces enhance readability
of written code.

CODING STANDARDS
3) Reliability
• Reliability is one of the most important aspects of industry strength software products.
• Reliability of source code can be increased by sticking to the standard processes for
software construction.
• During reviews, if any defects are found, they can be fixed easily if the source code is neat,
simple, and clear.
• Reliable source code can be achieved by first designing the software product with future
enhancement in consideration as well as by having a solid structure on which the software
product is to be built.
• When writing pieces of source code based on this structure, there will be little chance of
defects entering into the source code.
• Generally during enhancements, the existing structure is not able to take load of additional
source code and thus the structure becomes shaky.
• If the development team feels that this is the case, then it is far better to restructure the
software design and then write a code based on the new structure than to add a spaghetti
code on top of a crumbling structure.

CODING STANDARDS
4) Safety
• Safety is important, considering that software products are used by many
industries where human lives are concerned and that human lives could be in
danger because of faulty machine operation or exposure to a harmful
environment.
• In these industries, the software product must be ensured to operate correctly
and chances of error are less than 0.00001%.
• Industries like medicine and healthcare, road safety, hazardous material
handling need foolproof software products to ensure that either human lives are
saved (in case of medicine and healthcare) or human lives are not in danger.
• Here the software code must have inbuilt safety harnesses.

CODING STANDARDS
5) Simplicity
• The source code should have simplicity and no unnecessary complex logic;
improvisation should be involved, if the same functionality can be achieved
by a simpler piece of source code.
• Simplicity makes the code readable and will help in removing any defects
found in the source code.
• Simplicity of written code can be enhanced by adopting best practices for
many programming paradigms.
• For instance, in the case of object-oriented programming, abstraction and
information hiding add a great degree of simplicity.
• Similarly, breaking the product to be developed into meaningful pieces that
mimic real life parts makes the software product simple.

CODING STANDARDS
6) Maintainability
• As it has been pointed out after several studies, maintenance
costs are more than 70% of all costs including software
development, implementation, and maintenance.
• To make sure that maintenance costs are under limit during
software construction, it should be made sure that the source
code is maintainable.
• It will be easy to change the source code for fixing defects during
maintenance

CODING FRAMEWORK
Need for Coding framework
• Like most construction work, you need to set up an infrastructure based on
which construction can take place.
• For software construction, you need to have a coding framework that will ensure
a consistent coding production with standard code that will be easy to debug and
test.
• In object oriented programming, what base classes are to be made, which will be
used throughout construction, is a subject that is part of the coding framework.
• In general, coding frameworks allow construction of the common infrastructure
of basic functionality which can be extended later by the developers.
• This way of working increases productivity and allows for a robust and well
structured software product.
• It is similar in approach to house building where a structure is built based on a
solid foundation.

CODING FRAMEWORK
• For software construction, a coding framework is needed that will ensure a
consistent coding production with standard code that will be easy to debug and
test .
• In object oriented programming, what base classes are to be made, which will
be used throughout construction, is a subject that is part of the coding
framework.
• In general, coding frameworks allow construction of the common infrastructure
of basic functionality which can be extended later by the developers.
• Benefits: Increases productivity ,
Allows for a robust and
Well structured software product.

REVIEW TECHNIQUES
REVIEW TECHNIQUES

REVIEWS(QUALITY CONTROL)
• Almost 70% of software defects arise from faulty software code.
• To solve this problem, software construction is the most labor intensive
phase in software development.
• Any construction rework means wasting a lot of effort already put in.
• Moreover, it is also a fact that it is cheaper to fix any defects found during
construction at the phase level itself.
• If those defects are allowed to go in software testing , then fixing those
defects will become costlier .
• That is why review of the software code and fixing defects is very important.

SOFTWARE REVIEW
The software review is also a very integral part of the SDLC which helps to
verify the quality, features, other important parameters, and modules of the
software. It involves the complete procedure to verify the software, and to
confirm that it is working properly as per the requirements shared by the
customers.
Objectives of Software Review
The objectives of the software review are listed below −
• The software review enhances the efficiency of the development team.
• The software review works towards making the testing activities short,
and cost saving.
• The software review minimizes the probability of finding defects in the
production. It identifies flaws in the complete software development
process.

SOFTWARE REVIEW
Process of Software Review
The process of the software review are listed below −
Step 1 − The first step involves the entry evaluation. In this step, the complete
documentation, initial requirements, and feedback from the stakeholders are
gathered which adds to the overall reliability of the software.
Step 2 − The second step involves the management of the complete review
process. It involves the assignment of the roles and responsibilities, collecting
the resources, and other management related activities.
Step 3 − The third step involves the planning of the complete review process. It
involves defining the objectives and scopes for the review, sending review
meeting invites to the concerned parties, timings etc.
Step 4 − The fourth step involves the preparation of the complete review process.
It involves segregation of the correct resources, providing appropriate time for
the reviewers, and to detect errors.
• Step 5 − The fifth step involves the analysis and exit evaluation of the
complete review process. It involves going through the outcomes, taking
corrective actions on errors, and to assess the overall quality of the software
development process.

SOFTWARE REVIEW
Types of Software Review
The different types of the software review are listed below −
1. Peer Review
It is the technique of reviewing the source code of fellow developers. It
involves checking the test cases created by the team mates, providing
the required suggestions, and to reduce the issues encountered at time
of testing. The different types of peer review include code review, pair
programming, walkthrough, technical review, and inspection.
2. Management Review
It is the technique used to assess the status of progress of the work.
3. Software Audit Review
• It is an exterior review in which a single or multiple reviewers who are
outside the development team, take up self-sufficient inspection of the
software development processes to check if they are working as per the
standards, requirements, specifications, and compliances.

SOFTWARE REVIEW
ADVANTAGES OF SOFTWARE REVIEW:
• The software review detects defects from the early stages of the software
development life cycle (SDLC).
• The early identification of defects reduces the maintenance cost of the
software. It determines the in competencies in the software development
process which may result in bugs in the future.
• The software review guides the technical authors.

TYPES OF SOFTWARE REVIEW
• There are some techniques available
1. Deskchecks
2. Buddy Checking
3. walkthroughs
4. code reviews
5. inspections
6. Pair programming
etc. that ensure quality of the written code.

Source code review methods and their
operation sequence
Source code review methods and their
operation sequence

DESK CHECKING(PEER REVIEWS)
Desk check is a manual process used for reviewing and troubleshooting algorithms or computer
programs before actual implementation or testing. It involves thoroughly examining the written
code, step by step, to detect any errors or flaws in the logic. This technique aims to identify and
correct issues to ensure efficient and accurate functioning of the code.
1. Desk Check is a manual debugging technique that involves going through the code line by line,
executing the logic in your head or on paper, to find and fix errors.
2. It helps the programmer to understand their own code, identify potential faults and improve
efficiency by finding any logical errors or areas of redundancy.
3. Desk Check is especially useful for small programs or isolated sections of a larger code base, and
it is a valuable tool for learning and improving programming skills.
purpose of a deskcheck is To manually review the code for logic errors

DESK CHECKING
Importance of Desk Check
Desk Check is an important technology term as it refers to a valuable technique
used in software development, specifically for debugging and ensuring the
accuracy of a program or algorithm before it is executed.
Through desk checking, developers manually go through each line of code, tracing
the logic and data flow to detect any errors or anomalies.
• By identifying and resolving potential issues in the early stages, programmers
can prevent unforeseen problems during the actual execution, and thus,
improve the overall performance and functionality of the software.

BUDDY CHECKING
In software engineering, "buddy checking" (also known as "pair
testing" or "peer testing") is a collaborative approach where two
team members, often a developer and a tester, work together to
identify defects in a software module or application.
Collaborative exploration for enhanced quality. Buddy testing
is a collaborative approach to software testing where a
developer and a tester pair up. Together, they dive into a specific
module, exchanging insights and identifying any defects or
bugs.

WALKTHROUGH
The software development life cycle (SDLC) has multiple phases. Each and every phase of it plays a critical role
in the process of software development. Code walkthrough is an informal process of code review.
A team of developers and stakeholders performs the walkthrough.
An inspection is a formal process, while a walkthrough is informal.
Code Walkthrough
A code walkthrough is primarily a review meeting initiated by the code author. He reads through the code in
this meeting and other team mates ask questions, point out the coding errors and wherever code
standards are not followed.
The author of the code leads a code walkthrough meeting and other team members attend it. There is no
requirement of a moderator in this meeting. It is an open-ended discussion and there is not much focus
on documentation. In short, a code walkthrough is a type of peer review and forms a part of the static
testing. No formal review process is followed here.
In the hierarchy of code review which consists of technical review, inspection, and code walkthrough, the code
walkthrough comes at the lowest level in terms of formality of the process.

WALKTHROUGH
ADVANTAGES OF WALKTHROUGH
• It is an informal approach of finding errors in the code.
• It enables all the team members to gather together and have a common
understanding of the code, thereby increasing the collaboration and
cooperation among all.
• It allows gathering of multiple feedbacks and open interactions among
the team members.
DISADVANTAGES OF CODE WALKTHROUGH
• There may be defects in the sections of the code which are not discussed in the
walkthrough meeting.
• It takes a lot of time to conduct it.
• As the author himself leads the meeting, there is no guarantee to the fact that what is
being discussed actually matches with code.

CODE REVIEW
The developed code for a software needs to be reviewed in order to make it
robust. No matter how experienced a developer is, every piece of code
has to be re-checked to produce a world class software.
Code Review
• The code review is a methodical process where a group of developers
work together to analyze and check another developers code to detect
errors, give suggestions, and confirm if the developed code is as per the
standards. The objective of code review is to enhance the quality,
maintainability, stability, security etc of the software which bring positive
results to the project. Also, the findings from the code review promote
sharing knowledge and learnings among the team members.

CODE REVIEW
Code review is done for the following reasons:
• It helps to detect errors, defects, issues etc in the code prior to being deployed to
production. Thus a code review helps to fix bugs at the initial phases of software
development life cycle (SDLC).
• It motivates developing clean, maintainable, and effective code. The reviewers
pass feedback and comments so that the code is as per the standards and best
practices.
• It implements consistency in coding among all the developers which enables easy
maintenance and understanding of the code base.
• The findings from the code reviews can be shared across teams which propagate
domain knowledge and coding guidelines.
• The code reviewers take partial ownership of the code they review thereby
increasing collective responsibility towards ensuring quality.
• The code reviewers can work together and collaborate to improve the entire
review process which helps in enhancing the overall software quality.
To improve code quality and find defects early – purpose of code review.
Faster execution of code is not a benefit of code review.

INSPECTION
Inspection is the most formal form of reviews, a strategy adopted during
static testing phase.

INSPECTION
CHARACTERISTICS OF INSPECTION:
• Inspection is usually led by a trained moderator, who is not the author.
Moderator's role is to do a peer examination of a document
• Inspection is most formal and driven by checklists and rules.
• This review process makes use of entry and exit criteria.
• It is essential to have a pre-meeting preparation.
• Inspection report is prepared and shared with the author for appropriate
actions.
• Post Inspection, a formal follow-up process is used to ensure a timely
and a prompt corrective action.
• Aim of Inspection is NOT only to identify defects but also to bring in for
process improvement.

PAIR PROGRAMMING
• Pair programming is a technique in which two programmers
work simultaneously at a single computer and continuously
review each others’ work.
• Although many programmers were introduced to pair
programming as a part of Extreme Programming, it is a practice
that can be valuable in any development environment.
• Pair programming improves the organization by ensuring that at
least two programmers can maintain any piece of the software.

PAIR PROGRAMMING
• In pair programming, two programmers sit at one computer to write code.
Generally, one programmer will take control and write code, while the other
watches and advises.
• Some teams have found that pair programming works best for them if the pairs are
constantly rotated; this helps diffuse the shared knowledge throughout the organization.
Others prefer to pair a more junior person with a more senior for knowledge sharing.
• The project manager should not try to force pair programming on the team; it helps
to introduce the change slowly, and where it will meet the least resistance.
• It is difficult to implement pair programming in an organization where the programmers
do not share the same nine-to-five (or ten-to-six) work schedule.
• Some people do not work well in pairs, and some pairs do not work well together.

AUTOMATIC CODE GENERATION
• Constructing and generating software code is very
labor-intensive work.
• Some CASE and modelling tools are available that
generate software code.
• Then there are business analyst platforms developed
by many ERP software vendors that generate code
automatically when analysts configure the product.

AUTOMATIC CODE GENERATION
• Automatic code generation has certain advantages
over traditional coding.
– High Quality
– Consistent
– Productive
– Coding Abstractly

TWO TYPES OF CODE GENERATORS
• Passive code generators generate code once and then give up all
responsibility for it.
– The wizards and builders that you find in modern IDEs are typically
passive code generators. They're good for coming up with code that the
developer later customizes, but once the code has been generated, a
passive code generator can't regenerate it with changes.
• In contrast, active code generators are designed to maintain a
link with the code that is generated over the long term by
allowing the generator to be run multiple times over the same
code.
• The key point to keep in mind about active code generators is
that the template is the source code..

EXAMPLE – ACTIVE CODE
Suppose you're generating 500 class files from a single
template. With an active code generator, if you find a
bug in the architecture of those classes (say, you've
made a mistake in the way that you're handling object
persistence), it's not a huge problem. You just fix the
one template and regenerate the 500 classes. This
obviously saves you an incredible amount of time over
fixing the same bug over and over again in 500 separate
class files

ACTIVE CODE GENERATOR
• Active code generators typically comprise three different parts:
metadata, a pattern template, and the code generator itself:
• Metadata.
– Metadata is data that describes other data, thereby giving data shape and
form. Metadata is available from many sources, including databases, XML
schemas, and UML models.
• Pattern template.
– The pattern template is used by the code generator to render the data
described by the metadata in a new form.
Code generator.
– The code generator binds the metadata with the pattern template to
produce the desired output. The code generator can also embody code
generation rules that further define the form of the generated code.

BENEFITS OF ACTIVE CODE
• Increased speed.
• Improved accuracy.
• Better agility.

SOFTWARE TESTING
• Testing is the process of exercising a program with the specific intent
of finding errors prior to delivery to the end user.
• Basic Definitions
• Errors
• An error is a mistake, misconception, or misunderstanding on the part
of a software developer.
• Faults (Defects)
• A fault (defect) is introduced into the software as the result of an error.
It is an anomaly in the software that may cause it to behave incorrectly,
and not according to its specification.
• Failures
• A failure is the inability of a software system or component to perform
its required functions within specified performance requirements

SOFTWARE TESTING
Software testing is a type of investigation to find out if there are any
defects or errors present in the software so that the errors can be
reduced or removed to increase the quality of the software and to check
whether it fulfills the specified requirements or not.
According to Glen Myers, software testing has the following objectives:
 The process of investigating and checking a program to find whether
there is an error or not and does it fulfills the requirements or not is
called testing.
 When the number of errors found during the testing is high, it indicates
that the testing was good and is a sign of a good test case.
 Finding an unknown error that wasn’t discovered yet is a sign of a
successful and good test case.

42
• Test Case
• A test case in a practical sense is a test-related item which contains the following
• information:
• 1. A set of test inputs. These are data items received from an external source by
• the code under test. The external source can be hardware, software, or human.
• 2. Execution conditions. These are conditions required for running the test, for
• example, a certain state of a database, or a configuration of a hardware device.
• 3. Expected outputs. These are the specified results to be produced by the code
• under test.
• Test
• A test is a group of related test cases, or a group of related test cases and test
procedures
• Test Bed
• A test bed is an environment that contains all the hardware and software needed
to test a software component or a software system.

43
Verification vs validation
• Software testing is part of a broader group of activities called verification and validation that are involved
in software quality assurance
• Verification (Are the algorithms coded correctly?)
– The set of activities that ensure that software correctly implements a specific function or algorithm
– It refers to the set of tasks that ensure that software correctly implements a specific function
Verification: “Are we building the product right?”
• Validation (Does it meet user requirements?)
– The set of activities that ensure that the software that has been built is traceable to customer
requirements
Validation: “Are we building the right product?”
• Verification and validation includes a wide array of SQA activities: technical reviews, quality and
configuration audits, performance monitoring, simulation, feasibility study, documentation review,
database review, algorithm analysis, development testing, usability testing, qualification testing,
acceptance testing, and installation testing

44
Software testing strategy – big picture
Code
Design
Requirements
System Engineering
Unit Testing
Integration Testing
Validation Testing
System Testing
N
a
r
r
o
w
t
o
B
r
o
a
d
e
r
s
c
o
p
e
A
b
s
t
r
a
c
t
t
o
c
o
n
c
r
e
t
e

45
Software Testing Strategy
The main objective of software testing is to design the tests in
such a way that it systematically finds different types of errors
without taking much time and effort so that less time is required
for the development of the software. The overall strategy for
testing software includes:

46
Requirements to be specified for
Before testing starts, it’s necessary to identify and specify the requirements
of the product in a quantifiable manner. Different characteristics quality
of the software is there such as maintainability that means the ability to
update and modify, the probability that means to find and estimate any
risk, and usability that means how it can easily be used by the customers
or end-users. All these characteristic qualities should be specified in a
particular order to obtain clear test results without any error.
1. Specifying the objectives of testing in a clear and detailed manner. Several
objectives of testing are there such as effectiveness that means how
effectively the software can achieve the target, any failure that means
inability to fulfill the requirements and perform functions, and the cost of
defects or errors that mean the cost required to fix the error. All these
objectives should be clearly mentioned in the test plan.

47
2. For the software, identifying the user’s category and developing a
profile for each user. Use cases describe the interactions and
communication among different classes of users and the system to
achieve the target. So as to identify the actual requirement of the
users and then testing the actual use of the product.
3. Developing a test plan to give value and focus on rapid-cycle
testing. Rapid Cycle Testing is a type of test that improves quality
by identifying and measuring the any changes that need to be
required for improving the process of software. Therefore, a test
plan is an important and effective document that helps the tester
to perform rapid cycle testing.

48
4. Robust software is developed that is designed to test itself. The
software should be capable of detecting or identifying different
classes of errors. Moreover, software design should allow automated
and regression testing which tests the software to find out if there is
any adverse or side effect on the features of software due to any
change in code or program.
5. Before testing, using effective formal reviews as a filter. Formal
technical reviews is technique to identify the errors that are not
discovered yet. The effective technical reviews conducted before
testing reduces a significant amount of testing efforts and time
duration required for testing software so that the overall
development time of software is reduced.

49
6. Conduct formal technical reviews to evaluate the nature, quality
or ability of the test strategy and test cases. The formal technical
review helps in detecting any unfilled gap in the testing approach.
Hence, it is necessary to evaluate the ability and quality of the test
strategy and test cases by technical reviewers to improve the
quality of software.
7. For the testing process, developing a approach for the continuous
development. As a part of a statistical process control approach, a
test strategy that is already measured should be used for software
testing to measure and control the quality during the development
of software.

50
Advantages of Software Testing
 Improves software quality and reliability – Testing helps to identify and fix
defects early in the development process, reducing the risk of failure or
unexpected behavior in the final product.
 Enhances user experience – Testing helps to identify usability issues and
improve the overall user experience.
 Increases confidence – By testing the software, developers and stakeholders
can have confidence that the software meets the requirements and works as
intended.
 Facilitates maintenance – By identifying and fixing defects early, testing makes
it easier to maintain and update the software.
 Reduces costs – Finding and fixing defects early in the development process is
less expensive than fixing them later in the life cycle.

51
Disadvantages of Software Testing
1.Time-consuming – Testing can take a significant amount of time,
particularly if thorough testing is performed.
2. Resource-intensive – Testing requires specialized skills and resources,
which can be expensive.
3. Limited coverage – Testing can only reveal defects that are present in
the test cases, and it is possible for defects to be missed.
4. Unpredictable results – The outcome of testing is not always
predictable, and defects can be hard to replicate and fix.
5. Delays in delivery – Testing can delay the delivery of the software if
testing takes longer than expected or if significant defects are identified.

52
Testing Strategies for Conventional
software
• Blackbox testing strategy
• Whitebox testing strategy
• Validation testing strategy
• System testing strategy
• Unit testing strategy
• Integration testing strategy

53
Black Box testing
Black box testing is a technique of software testing which examines the
functionality of software without peering into its internal structure or
coding. The primary source of black box testing is a specification of
requirements that is stated by the customer.
• In this method, tester selects a function and gives input value to examine
its functionality, and checks whether the function is giving expected
output or not. If the function produces correct output, then it is passed in
testing, otherwise failed. The test team reports the result to the
development team and then tests the next function. After completing
testing of all functions if there are severe problems, then it is given back
to the development team for correction.
• Blackbox testing examines software functionalities without
knowledge of internal code

54
Black Box testing
Generic steps of black box testing
• The black box test is based on the specification of requirements, so
it is examined in the beginning.
• In the second step, the tester creates a positive test scenario and an
adverse test scenario by selecting valid and invalid input values to
check that the software is processing them correctly or incorrectly.
• In the third step, the tester develops various test cases such as
decision table, all pairs test, equivalent division, error estimation,
cause-effect graph, etc.
• The fourth phase includes the execution of all test cases.
• In the fifth step, the tester compares the expected output against
the actual output.
• In the sixth and final step, if there is any flaw in the software, then it
is cured and tested again.

55
Black box testing
• Black-box testing, also called behavioural testing, focuses on the
functional requirements of the software. That is, black-box testing
techniques enable you to derive sets of input conditions that will fully
exercise all functional requirements for a program.
• Black-box testing is not an alternative to white-box techniques. Rather,
it is a complementary approach that is likely to uncover a different
class of errors than whitebox methods.
• Black-box testing attempts to find errors in the following categories:
• (1) incorrect or missing functions, (2) interface errors,
• (3) errors in data structures or external database access,
• (4) behaviour or performance errors, and
• (5) initialization and termination errors.

56
Questions answered by black box
1. How is functional validity tested?
2. How are system behavior and performance tested?
3. What classes of input will make good test cases?
4. Is the system particularly sensitive to certain input values?
5. How are the boundary values of a data class isolated?
6. What data rates and data volume can the system tolerate?
7. What effect will specific combinations of data have on system operation?

57
Graph based testing method
• The first step in black-box testing is to understand the
objects that are modelled in software and the
relationships that connect these objects
• The next step is to define a series of tests that verify “all
objects have the expected relationship to one another”
• Software testing begins by creating a graph of
important objects and their relationships and then
devising a series of tests that will cover the graph so
that each object and relationship is exercised, and errors
are uncovered.

58
Steps
1. creating a graph—a collection of nodes that
represent objects,
2. links that represent the relationships between
objects,
3. Node weights that describe the properties of a node
4. link weights that describe some characteristic of a
link

59
Graph based testing
1. A directed link (represented by an arrow) indicates
that a relationship moves in only one direction.
2. A bidirectional link, also called a symmetric link,
implies that the relationship applies in both directions.
3. Parallel links are used when a number of different
relationships are established between graph nodes
• After creating the graph derive test cases by
traversing the graph and covering each of the
relationships shown. These test cases are designedin
an attempt to find errors in any of the relationships.

60
Behavioral testing methods
• 1. Transaction flow modeling. The nodes represent steps in some transaction
(e.g., the steps required to make an airline reservation using an online
service), and the links represent the logical connection between steps
• 2. Finite state modeling. The nodes represent different user-observable
states of the software (e.g., each of the “screens” that appear as an order
entry clerk takes a phone order), and the links represent the transitions that
occur to move from state to state
• 3. Data flow modeling. The nodes are data objects, and the links are the
transformations that occur to translate one data object into another.
• 4. Timing modeling. The nodes are program objects, and the links are the
sequential connections between those objects. Link weights are used to
specify the required execution times as the program executes.

61
EQUIVALENCE Partitioning
• A black-box testing method that divides the input domain of a program into
classes of data from which test cases are derived
• An ideal test case single-handedly uncovers a complete class of errors, thereby
reducing the total number of test cases that must be developed
• Test case design is based on an evaluation of equivalence classes for an input
condition
• An equivalence class represents a set of valid or invalid states for input
conditions
• Typically, an input condition is either a specific numeric value, a range of values,
a set of related values,or a Boolean condition.
• From each equivalence class, test cases are selected so that the largest number
of attributes of an equivalence class are exercise at once

62
contd
• Complements white-box testing by uncovering
different classes of errors
• Focuses on the functional requirements and the
information domain of the software
• Used during the later stages of testing after white
box testing has been performed
• The tester identifies a set of input conditions that
will fully exercise all functional requirements for a
program
• The test cases satisfy the following:
• Reduce, by a count greater than one, the number of additional test cases that must be
designed to achieve reasonable testing
• Tell us something about the presence or absence of classes of errors, rather than an error
associated only with the specific task at hand

63
Guidelines for Defining Equivalence Classes
• If an input condition specifies a range, one valid and two
invalid equivalence classes are defined
– Input range: 1 – 10 Eq classes: {1..10}, {x < 1}, {x > 10}
• If an input condition requires a specific value, one valid and
two invalid equivalence classes are defined
– Input value: 250 Eq classes: {250}, {x < 250}, {x > 250}
• If an input condition specifies a member of a set, one valid
and one invalid equivalence class are defined
– Input set: {-2.5, 7.3, 8.4}Eq classes: {-2.5, 7.3, 8.4}, {any other x}
• If an input condition is a Boolean value, one valid and one
invalid class are define
– Input: {true condition} Eq classes: {true condition}, {false condition}

64
Boundary Value Analysis
• A greater number of errors occur at the boundaries of the
input domain rather than in the "center"
• Boundary value analysis is a test case design method that
complements equivalence partitioning
– It selects test cases at the edges of a class
– It derives test cases from both the input domain and output domain
• Boundary value analysis is a test-case design technique that
complements equivalence partitioning. Rather than
selecting any element of an equivalence class, BVA leads to
the selection of test cases at the “edges” of the class

65
Guidelines for Boundary Value Analysis
• 1. If an input condition specifies a range bounded by values a and b, test cases
should be designed with values a and b as well as values just above and just
below a and b
• 2. If an input condition specifies a number of values, test case should be
developed that exercise the minimum and maximum numbers. Values just
above and just below the minimum and maximum are also tested
• 3. Apply guidelines 1 and 2 to output conditions; produce output that reflects
the minimum and the maximum values expected; also test the values just below
and just above
• 4. If internal program data structures have prescribed boundaries (e.g., an array),
design a test case to exercise the data structure at its minimum and maximum
boundaries

66
Orthogonal Array Testing
• In certain application the number of input parameters is small and
the values that each of the parameters may take are clearly
bounded.
• When these numbers are very small (e.g., three input parameters
taking on three discrete values each), it is possible to consider
every input permutation and exhaustively test the input domain
• However, as the number of input values grows and the number of
discrete values for each data item increases, exhaustive testing
becomes impractical or impossible.
• Orthogonal array testing can be applied to problems in which the
input domain is
• relatively small but too large to accommodate exhaustive testing

67
Orthogonal Array Testing
• It’s used for small number of inputs, but with exhaustive number of possibilities.
It’s a black box testing with systematic and statistics techniques so, you don’t
need to have the knowledge of the implementation of the system. The main
aim is maximizing the coverage by comparatively lesser number of test cases
• Orthogonal arrays can be applied in user interface testing, system testing,
regression testing, configuration testing and performance testing.
• The orthogonal array testing method is particularly useful in finding region faults
—an error category associated with faulty logic within a software component.
• one input item at a time” approaches, consider a system that has three input
items, X, Y, and Z. Each of these input items has three discrete values associated
with it. There are 33
= 27 possible test cases
• A geometric view of the possible test cases associated with X, Y, and Z

68
• When orthogonal array testing occurs, an L9
orthogonal array of test cases is created.
The L9 orthogonal array has a “balancing
property”. That is, test cases (represented
by dark dots in the figure) are “dispersed
uniformly throughout the test domain,” as
illustrated in the right-hand cube. Test
coverage across the input domain is more
complete.

69
contd
• Given the relatively small number of input parameters and discrete values,
exhaustive testing is possible. The number of tests required is 34 =
81, large but
manageable.
• All faults associated with data item permutation would be found, but the effort
required is relatively high.
• The orthogonal array testing approach enables you to provide good test
coverage with far fewer test cases than the exhaustive strategy.

70
Example – orthogonal array testing
• If we have 3 parameters, each can have
3 values then the possible Number of
tests using conventional method is 3^3
= 27. While the same using OAT, it boils
down to 9 test cases.
The array is orthogonal,
because all possible pair-
wise combinations
between parameters occurs
only once.

71
Inferences - oat
• The given L9 Orthogonal Array assess result of test cases as follows:
• Single Mode Faults - Single mode faults occur only due to one
parameter. For example, in above Orthogonal array if test cases 7, 8
and 9 show error, we can expect that value 3 of parameter 1 is causing
the error. Likewise we can detect as well as isolate the error.
• Double Mode Fault - Double mode fault is caused by the two specific
parameters values interacting together. Such an interaction is a
harmful interaction between interacting parameters.
• Multimode Faults - If more than two interacting components produce
the consistent erroneous output, then it is a multimode fault.
Orthogonal array detects the multimode faults.

72
Model based testing
• Model-based testing (MBT) is a black-box testing technique that uses
information contained in the requirements model as the basis for the
generation of test cases.
• In many cases, the model-based testing technique uses UML state
diagrams, an element of the behavioral model, as the basis for the
design of test cases

73
Steps of Model Based Testing
• 1. Analyze an existing behavioral model for the software or
create one
• 2. Traverse the behavioral model and specify the inputs that
will force the software to make the transition from state to
state
• 3. Review the behavioral model and note the expected outputs
as the software makes the transition from state to state
• 4. Execute the test cases
• 5. Compare actual and expected results and take corrective
action as required
• MBT helps to uncover errors in software behaviour, and therefore, it is
• extremely useful when testing event-driven applications.

74
White Box testing
White box testing follows some working steps to make
testing manageable and easy to understand what the
next task to do. There are some basic steps to perform
white box testing.
Whitebox testing focuses on Internal structure and code logic

75
White Box testing
Generic steps of white box testing
• Design all test scenarios, test cases and prioritize them according to high
priority number.
• This step involves the study of code at runtime to examine the resource
utilization, not accessed areas of the code, time taken by various
methods and operations and so on.
• In this step testing of internal subroutines takes place. Internal
subroutines such as nonpublic methods, interfaces are able to handle all
types of data appropriately or not.
• This step focuses on testing of control statements like loops and
conditional statements to check the efficiency and accuracy for different
data inputs.
• In the last step white box testing includes security testing to check all
possible security loopholes by looking at how the code handles security.

76
White Box testing
The box testing approach of software testing consists of black box testing
and white box testing. We are discussing here white box testing which also
known as glass box is testing, structural testing, clear box testing, open
box testing and transparent box testing.
It tests internal coding and infrastructure of a software focus on checking of
predefined inputs against expected and desired outputs. It is based on inner
workings of an application and revolves around internal structure testing.
In this type of testing programming skills are required to design test cases.
The primary goal of white box testing is to focus on the flow of inputs and
outputs through the software and strengthening the security of the software.
The term 'white box' is used because of the internal perspective of the system. The
clear box or white box or transparent box name denote the ability to see through
the software's outer shell into its inner workings.

77
White Box testing
Developers do white box testing. In this, the developer will test every line of
the code of the program. The developers perform the White-box testing
and then send the application or the software to the testing team, where
they will perform the black box testing and verify the application along
with the requirements and identify the bugs and sends it to the developer.
The developer fixes the bugs and does one round of white box testing and
sends it to the testing team. Here, fixing the bugs implies that the bug is
deleted, and the particular feature is working fine on the application.
Here, the test engineers will not include in fixing the defects for the following
reasons:
• Fixing the bug might interrupt the other features. Therefore, the test
engineer should always find the bugs, and developers should still be
doing the bug fixes.
• If the test engineers spend most of the time fixing the defects, then they
may be unable to find the other bugs in the application.

78
White Box testing
Reasons for white box testing
• It identifies internal security holes.
• To check the way of input inside the code.
• Check the functionality of conditional loops.
• To test function, object, and statement at an individual level.
Advantages of White box testing
• White box testing optimizes code so hidden errors can be identified.
• Test cases of white box testing can be easily automated.
• This testing is more thorough than other testing approaches as it covers
all code paths.
• It can be started in the SDLC phase even without GUI.
Disadvantages of White box testing
• White box testing is too much time consuming when it comes to large-
scale programming applications.
• White box testing is much expensive and complex.
• It can lead to production error because it is not detailed by the
developers.
• White box testing needs professional programmers who have a detailed
knowledge and understanding of programming language and
implementation.

79
White Box testing methods
The white box testing contains various tests, which
are as follows:
• Path testing
• Loop testing
• Condition testing
• Testing based on the memory perspective
• Test performance of the program

80
White Box testing
Path testing
In the path testing, we will write the flow graphs and test all independent
paths. And test all the independent paths implies that suppose a path
from main() to function G, first set the parameters and test if the program
is correct in that particular path, and in the same way test all other paths
and fix the bugs.
Here writing the flow graph implies that flow graphs are representing the flow
of the program and also show how every program is added with one
another as we can see in the below image:

81
White Box testing
Loop testing
In the loop testing, we will test the loops such as while, for, and do-while, etc. and also
check for ending condition if working correctly and if the size of the conditions is
enough.
For example: we have one program where the developers have given about 50,000 loops.
1. {
2. while(50,000)
3. ……
4. ……
5. }
We cannot test this program manually for all the 50,000 loops cycle. So we write a small
program that helps for all 50,000 cycles, as we can see in the below program, that
test P is written in the similar language as the source code program, and this is
known as a Unit test. And it is written by the developers only.
6. Test P
7. {
8. ……
9. …… }
• As we can see in the below image that, we have various requirements such as 1, 2, 3,
4. And then, the developer writes the programs such as program 1,2,3,4 for the
parallel conditions. Here the application contains the 100s line of codes.

82
White Box testing
Condition testing
In this, we will test all logical conditions for both true and false values; that is, we will verify
for both if and else condition.
For example:
1. if(condition) - true
2. {
3. …..
4. ……
5. ……
6. }
7. else - false
8. {
9. …..
10. ……
11. ……
12. }
• The above program will work fine for both the conditions, which means that if the
condition is accurate, and then else should be false and conversely.

83
White Box testing
Testing based on the memory (size) perspective
The size of the code is increasing for the following reasons:
• The reuse of code is not there: let us take one example, where we have
four programs of the same application, and the first ten lines of the
program are similar. We can write these ten lines as a discrete function,
and it should be accessible by the above four programs as well. And also,
if any bug is there, we can modify the line of code in the function rather
than the entire code.
• The developers use the logic that might be modified. If one
programmer writes code and the file size is up to 250kb, then another
programmer could write a similar code using the different logic, and the
file size is up to 100kb.
• The developer declares so many functions and variables that might
never be used in any portion of the code. Therefore, the size of the
program will increase.

84
White Box testing - example
1. Int a=15;
2. Int b=20;
3. String S= "Welcome";
4. ….
5. …..
6. …..
7. ….
8. …..
9. Int p=b;
10. Create user()
11. {
12. ……
13. ……
14. ….. 200's line of code
15. }
In the above code, we can see that the integer a has never been called anywhere in the
program, and also the function Create user has never been called anywhere in the
code. Therefore, it leads us to memory consumption.
• We cannot remember this type of mistake manually by verifying the code because
of the large code. So, we have a built-in tool, which helps us to test the needless
variables and functions. And, here we have the tool called Rational purify.

86
White Box testing
Suppose we have three programs such as Program P, Q, and R, which
provides the input to S. And S goes into the programs and verifies the
unused variables and then gives the outcome. After that, the developers
will click on several results and call or remove the unnecessary function
and the variables.
This tool is only used for the C programming language and
C++ programming language; for another language, we have other
related tools available in the market.
• The developer does not use the available in-built functions; instead they
write the full features using their logic. Therefore, it leads us to waste of
time and also postpone the product releases.

87
White Box testing
Test the performance (Speed, response time) of the
program
The application could be slow for the following reasons:
• When logic is used.
• For the conditional cases, we will
use or & and adequately.
• Switch case, which means we cannot use nested if,
instead of using a switch case.

89
White Box testing
As we know that the developer is performing white box testing, they
understand that the code is running slow, or the performance of the
program is also getting deliberate. And the developer cannot go
manually over the program and verify which line of the code is slowing
the program.
To recover with this condition, we have a tool called Rational Quantify,
which resolves these kinds of issues automatically. Once the entire code
is ready, the rational quantify tool will go through the code and execute
it. And we can see the outcome in the result sheet in the form of thick
and thin lines.
Here, the thick line specifies which section of code is time-consuming. When
we double-click on the thick line, the tool will take us to that line or piece
of code automatically, which is also displayed in a different color. We can
change that code and again and use this tool. When the order of lines is
all thin, we know that the presentation of the program has enhanced.
And the developers will perform the white box testing automatically
because it saves time rather than performing manually.
• Test cases for white box testing are derived from the design phase of the
software development lifecycle. Data flow testing, control flow testing,
path testing, branch testing, statement and decision coverage all these
techniques used by white box testing as a guideline to create an error-
free software.

90
Techniques used in White Box testing
Techniques Used in White Box Testing
Data Flow Testing
Data flow testing is a group of testing strategies that examines the control flow of programs in order to
explore the sequence of variables according to the sequence of events.
Control Flow Testing
Control flow testing determines the execution order of statements or instructions of the program through a
control structure. The control structure of a program is used to develop a test case for the program. In this
technique, a particular part of a large program is selected by the tester to set the testing path. Test cases
represented by the control graph of the program.
Branch Testing
Branch coverage technique is used to cover all branches of the control flow graph. It covers all the possible
outcomes (true and false) of each condition of decision point at least once.
Statement Testing
Statement coverage technique is used to design white box test cases. This technique involves execution of all
statements of the source code at least once. It is used to calculate the total number of executed statements in
the source code, out of total statements present in the source code.
Decision Testing
This technique reports true and false outcomes of Boolean expressions. Whenever there is a possibility of two
or more outcomes from the statements like do while statement, if statement and case statement (Control
flow statements), it is considered as decision point because there are two outcomes either true or false.

91
BASIS PATH TESTING
• Basis Path testing is a White-box testing technique proposed by Tom
McCabe
• Enables the test case designer to derive a logical complexity measure of
a procedural design
• Uses this measure as a guide for defining a basis set of execution paths
• Test cases derived to exercise the basis set are guaranteed to execute
every statement in the program at least one time during testing

92
Flow graph notation -
• Flow Graph Notation - simple notation for the representation of control
flow is using flow graph or program graph.
• Flow graph :
• A circle in a graph represents a node, which stands for a sequence of one or
more procedural statements
• A sequence of process boxes and a
decision diamond can map into a single
node. The arrows on the flow graph, called
edges or links
• A node containing a simple conditional expression is referred to as a
predicate node
• Each compound condition in a conditional expression containing one or more
Boolean operators (e.g., and, or) is represented by a separate predicate node
• A predicate node has two edges leading out from it (True and False)

93
Flow graph notations
• An edge, or a link, is a an arrow representing flow of control in a specific direction
• An edge must start and terminate at a node
• An edge does not intersect or cross over another edge

94
Flow graph example
Flow Chart Flow Graph
• Areas bounded by a set of edges and nodes are called regions
• When counting regions, include the area outside the graph as a region, too

95
Independent program paths
• Defined as a path through the program from the start node until the end node
that introduces at least one new set of processing statements or a new
condition (i.e., new nodes)
• Must move along at least one edge that has not been traversed before by a
previous path
•
• Basis set for flow graph on previous slide
• Path 1: 0-1-11
• Path 2: 0-1-2-3-4-5-10-1-11
• Path 3: 0-1-2-3-6-8-9-10-1-11
• Path 4: 0-1-2-3-6-7-9-10-1-11
• The number of paths in the basis set is determined by the cyclomatic complexity
• Paths 1 through 4 constitute a basis set for the flow graph

96
Cyclomatic complexity
• This is used to determine on how many paths to test .
• A Software metric that provides a quantitative measure of the logical
complexity of a program
• Defines the number of independent paths in the basis set
• Provides an upper bound for the number of tests that must be conducted
to ensure all statements have been executed at least once
• Can be computed three ways
• The number of regions
• V(G) = E – N + 2, where E is the number of edges and N is the
number of nodes in graph G
• V(G) = P + 1, where P is the number of predicate nodes in the flow
graph G

97
• Results in the following equations for the
example flow graph
• Number of regions = 4
• V(G) = 11 edges – 9 nodes + 2 = 4
• V(G) = 3 predicate nodes + 1 = 4
• Therefore cyclomatic complexity = 4
1
2
4
6
5
7 8
9
10
11

98
CYCLOMATIC COMPLEXIty - example
• if (month == 1) {
• if (day == 1) {
• print('HAPPY NEW
YEAR');
• } else {
• print('HAVE A NICE DAY');
• }
• }
• print('END');
Control Flow
Graph
Source code
1
2
3
4
5
6
7
8
Cyclomatic complexity
V(G) = E – N + 2
No of edges = 8 (E)
No of Nodes = 7 (N)
Therefore
V(G) = 8 – 7 + 2 = 3

99
Example – To calculate cyclomatic complexity
1 int functionZ(int y)
2 {
3 int x = 0;
4 while (x <= (y * y))
5 {
6 if ((x % 11 == 0) &&
7 (x % y == 0))
8 {
9 printf(“%d”, x);
10 x++;
11 } // End if
12 else if ((x % 7 == 0) ||
13 (x % y == 1))
14 {
15 printf(“%d”, y);
16 x = x + 2;
17 } // End else
18 printf(“n”);
19 } // End while
20 printf("End of listn");
21 return 0;
22 } // End functionZ
21
6
4
3
7
9
10
12 13
15
16
18
20

100
Example on calculating cyclomatic complexity
Cyclomatix Complexity Calculation
V( G) = E – N + 2
E = No of Edges = 15
N = No of Nodes = 13
V(G) = E-N + 2
15-13 + 2 = 2+2 = 4
13
3
2
1
4
5
8
6 7
9
10
11
12
1
2
3
6
5
7
8
9
1
2
4
1
3
1
4
1
5
1
0
1
1
Line numbers of Code is represented as Nodes , so the node numbers are
given in the control flow graph

101
Graph matrices
• The procedure for deriving the flow graph and even
determining a set of basis paths is amenable to mechanization.
• A data structure, called a graph matrix, can be quite useful for
developing a software tool that assists in basis path testing.
• A graph matrix is a square matrix whose size (i.e., number of
rows and columns) is equal to the number of nodes on the flow
graph. Each row and column corresponds to an identified node,
and matrix entries correspond to connections (an edge)
between nodes.

102
GRAPH MATRICES
• Each node on the flow graph is identified by numbers, while each edge
is identified by letters. A letter entry is made in the matrix to
correspond to a connection between two nodes. For example, node 3
is connected to node 4 by edge b.
• The link weight provides additional information about control flow

103
GRAPH MATRICES
• In its simplest form, the link weight is 1 (a connection exists) or 0 (a
connection does not exist).
• But link weights can be assigned other, more interesting properties:
– • The probability that a link (edge) will be execute.
– • The processing time expended during traversal of a link
– • The memory required during traversal of a link
– • The resources required during traversal of a link.
• Using these techniques, the analysis required to design test cases can
be partially or fully automated.

104
Deriving the Basis Set and Test Cases
1) Using the design or code as a foundation, draw a corresponding flow
graph
2) Determine the cyclomatic complexity of the resultant flow graph
3) Determine a basis set of linearly independent paths
4) Prepare test cases that will force execution of each path in the basis
set

105
Control structure testing
• The basis path testing technique is one of a number of techniques for control structure
testing.
• Although basis path testing is simple and highly effective, it is not sufficient in itself. Hence
there is a variation on control structure testing which broadens the testing coverage and
improve the quality of white-box testing.
• 1. Condition Testing
• Condition testing is a test-case design method that exercises the logical conditions contained
in a program module. A simple condition is a Boolean variable or a relational expression,
possibly preceded with one NOT (¬) operator. A relational expression takes the form
– E1 <relational-operator> E2
• where E1 and E2 are arithmetic expressions and <relational-operator> is one of the
• following: < , <=,=, not equal, > , >=
•

106
Control Structure testing
• 1. Condition Testing - To test logical conditions in the program
module
• 2. Data Flow Testing – This method select test paths based on
location of definition and use of variables in the program
• 3. Loop Testing – Focus extensively on the validity of loop
constructs in the program module
 Simple Loops
 Nested Loops
 Concatenated Loops
 Un Structured Loops

107
Condition testing
• A compound condition is composed of two or more simple conditions,
Boolean operators, and parentheses.
• We assume that Boolean operators allowed in a compound condition
include OR (), AND (&),and NOT (¬).
• A condition without relational expressions is referred to as a Boolean
expression.
• If a condition is incorrect, then at least one component of the condition
is incorrect.
• The condition testing method focuses on testing each condition in the
program to ensure that it does not contain errors.

108
Loop testing
• Loops are the cornerstone for the vast majority of all algorithms
implemented in software. And yet, we often pay them little heed
while conducting software tests
• A white-box testing technique that focuses exclusively on the
validity of loop constructs
• Four different classes of loops exist
– Simple loops
– Nested loops
– Concatenated loops
– Unstructured loops
• Testing occurs by varying the loop boundary values
– Examples:
for (i = 0; i < MAX_INDEX; i++)
while (currentTemp >= MINIMUM_TEMPERATURE)

110
Testing of simple loops
1) Skip the loop entirely
2) Only one pass through the loop
3) Two passes through the loop
4) m passes through the loop, where m < n
5) n –1, n, n + 1 passes through the loop
‘n’ is the maximum number of allowable passes through the loop

111
Testing of nested loops
1) Start at the innermost loop; set all other loops to minimum values
2) Conduct simple loop tests for the innermost loop while holding the outer loops at
their minimum iteration parameter values; add other tests for out-of-range or
excluded values
3) Work outward, conducting tests for the next loop, but keeping all other outer
loops at minimum values and other nested loops to “typical” values
4) Continue until all loops have been tested

112
Testing of concatenated loops
• Concatenated loops can be tested using the approach defined for
simple loops, if each of the loops is independent of the other.
• However, if two loops are concatenated and the loop counter for
loop 1 is used as the initial value for loop 2, then the loops are not
independent.
• When the loops are not independent, the approach applied to nested
loops is recommended

113
Tesing of unstructured loops
• Redesign the code to reflect the use of structured programming
practices
• Depending on the resultant design, apply testing for simple loops,
nested loops, or concatenated loops

114
Black box testing
• Black-box testing, also called behavioural testing, focuses on the
functional requirements of the software. That is, black-box testing
techniques enable you to derive sets of input conditions that will fully
exercise all functional requirements for a program.
• Black-box testing is not an alternative to white-box techniques. Rather,
it is a complementary approach that is likely to uncover a different
class of errors than whitebox methods.
• Black-box testing attempts to find errors in the following categories:
• (1) incorrect or missing functions, (2) interface errors,
• (3) errors in data structures or external database access,
• (4) behaviour or performance errors, and
• (5) initialization and termination errors.

115
WHITE BOX testing
• White-box testing, sometimes called glass-box testing, clear ,
structural testing.
• It is a testing technique which evaluates the code and the
internal structure of a program.
• It is a test-case design philosophy that uses the control structure
described as part of component-level design to derive test cases.
• White box testing guarantees
• Guarantee that all independent paths within a module have been exercised at least once
• Exercise all logical decisions on their true and false sides
• Execute all loops at their boundaries and within their operational bounds
• Exercise internal data structures to ensure their validity

116
WHITE BOX TESTING - COVERAGE
• White Box Testing is coverage of the specification in the code:
• 1. Code coverage
• 2. Segment coverage/statement coverage: Ensure that each code statement is executed once.
• 3. Branch Coverage or Node Testing: Coverage of each code branch in from all possible ways.
• 4. Compound Condition Coverage: For multiple conditions test each condition with multiple paths and
combination of the different path to reach that condition.
• 5. Basis Path Testing: Each independent path in the code is taken for testing.
• 6. Data Flow Testing (DFT): In this approach you track the specific variables through each possible
calculation, thus defining the set of intermediate paths through the code. DFT tends to reflect
dependencies but it is mainly through sequences of data manipulation. In short, each data variable is
tracked and its use is verified. This approach tends to uncover bugs like variables used but not initialize,
or declared but not used, and so on.
• 7. Path Testing: Path testing is where all possible paths through the code are defined and covered. It’s a
time-consuming task.
• 8. Loop Testing: These strategies relate to testing single loops, concatenated loops, and nested loops.
Independent and dependent code loops and values are tested by this approach.

118
Difference between White Box testing and blackbox
testing
White-box testing Black box testing
The developers can perform white
box testing.
The test engineers perform the black
box testing.
To perform WBT, we should have
an understanding of the
programming languages.
To perform BBT, there is no need to
have an understanding of the
programming languages.
In this, we will look into the source
code and test the logic of the code.
In this, we will verify the functionality
of the application based on the
requirement specification.
In this, the developer should know
about the internal design of the
code.
In this, there is no need to know about
the internal design of the code.

119
Major Types of testing
• Unit testing [white box]
– Concentrates on each component/function of the software as implemented in the source
code
• Integration testing
– Focuses on the design and construction of the software architecture
• Validation testing
– Requirements are validated against the constructed software
• System testing
– The software and other system elements are tested as a whole
– There are other sublevel testing are performed like
– Functional Testing (after Unit testing) – Testing technique used – Black box
– Regression Testing
– Smoke Testing (will see in detail in later slides)

121
Testing strategy applied to conventional
applications
Unit testing
 Exercises specific paths in a component's control structure to ensure complete coverage and maximum
error detection
 Components are then assembled and integrated
Integration testing
 Focuses on inputs and outputs, and how well the components fit together and work together
Validation testing
 Provides final assurance that the software meets all functional, behavioral, and performance requirements
System testing
 Verifies that all system elements (software, hardware, people, databases) mesh properly and that overall
system function and performance is achieved

122
Unit testing
• Individual components are tested.
• It is a path test.
• To focus on a relatively small segment of code and aim to exercise a high percentage of the
internal path
• Concentrates on the internal processing logic and data structures
• Is simplified when a module is designed with high cohesion
• Reduces the number of test cases
• Allows errors to be more easily predicted and
uncovered
• Concentrates on critical modules and those with high cyclomatic complexity when testing
resources are limited

123
Targets for unit test cases
• Module interface
– Ensure that information flows properly into and out of the module
• Local data structures
– Ensure that data stored temporarily maintains its integrity during all steps in
an algorithm execution
• Boundary conditions
– Ensure that the module operates properly at boundary values established to limit or
restrict processing
• Independent paths (basis paths)
– Paths are exercised to ensure that all statements in a module have been executed at least
once
• Error handling paths
– Ensure that the algorithms respond correctly to specific error conditions

124
Driver and stub for unit testing
• Driver
– A simple main program that accepts test case data, passes such data
to the component being tested, and prints the returned results
• Stubs
– Serve to replace modules that are subordinate to (called by) the component to be
tested
– It uses the module’s exact interface, may do minimal data manipulation, provides
verification of entry, and returns control to the module undergoing testing
• Drivers and stubs both represent overhead
– Both must be written but don’t constitute part of the installed software product

125
SOME common error – unit testing
• Misunderstood or incorrect arithmetic precedence
• Mixed mode operations (e.g., int, float, char)
• Incorrect initialization of values
• Precision inaccuracy and round-off errors
• Incorrect symbolic representation of an expression (int vs. float)
• Failure to exit when divergent iteration is encountered
• Improperly modified loop variables
• Boundary value violations

126
Integration testing
• Defined as a systematic technique for constructing the software architecture
– At the same time integration is occurring,
conduct tests to uncover errors associated with
interfaces
• Objective is to take unit tested modules and build a program structure based on the prescribed
design
• Two Approaches
– Non-incremental Integration Testing
– Incremental Integration Testing

127
Non-incremental testing
• Commonly called the “Big Bang” approach
• All components are combined in advance
• The entire program is tested as a whole
• Chaos results
• Many seemingly-unrelated errors are encountered
• Correction is difficult because isolation of causes is complicated
• Once a set of errors are corrected, more errors occur, and testing
appears to enter an endless loop

128
Incremental testing
• Three kinds
• Top-down integration
• Bottom-up integration
• Sandwich integration
• The program is constructed and tested in small increments
• Errors are easier to isolate and correct
• Interfaces are more likely to be tested completely
• A systematic test approach is applied

129
Top-down integration testing
 Modules are integrated by moving downward through the control hierarchy, beginning with the
main module .
 The control program is tested first. Modules are integrated one at a time. Emphasize on interface
testing
 Subordinate modules are incorporated in either a depth-first or breadth-first fashion
– DF: All modules on a major control path are
integrated
– BF: All modules directly subordinate at each
level are integrated

130
TOP DOWN integration
• Advantages
• This approach verifies major control or decision points early in the test process
• No test drivers needed
• Interface errors are discovered early
• Modular features aid debugging
• Disadvantages
• Stubs need to be created to substitute for modules
•that have not been built or tested yet; this code is later discarded.
• Because stubs are used to replace lower level modules,
•no significant data flow can occur until much later in the
•integration/testing process.

131
Bottom-up integration
• Integration and testing starts with the most atomic modules in the
control hierarchy
• Allow early testing aimed at proving feasibility and emphasize on
module functionality and performance

132
Bottom –up integration
• Advantages
– This approach verifies low-level data processing early in the testing process
– Need for stubs is eliminated
• Disadvantages
– Driver modules need to be built to test the lower-level modules; this code
is later discarded or expanded into a full-featured version
– Drivers inherently do not contain the complete algorithms that will
eventually use the services of the lower-level modules; consequently,
testing may be incomplete or more testing may be needed later when the
upper level modules are available

133
Sandwich integration
• Consists of a combination of both top-down and bottom-up integration
• Occurs both at the highest level modules and also at the lowest level
modules
• Proceeds using functional groups of modules, with each group
completed before the next
• High and low-level modules are grouped based on the control and data
processing they provide for a specific program feature
• Integration within the group progresses in alternating steps between the high
and low level modules of the group
• When integration for a certain functional group is complete, integration and
testing moves onto the next group
• Recaps the advantages of both types of integration while minimizing
the need for drivers and stubs
• Requires a disciplined approach so that integration doesn’t tend
towards the “big bang” scenario

135
Regression testing
• Each new addition or change to baselined software may cause problems
with functions that previously worked flawlessly
• Regression testing re-executes a small subset of tests that have already
been conducted
• Ensures that changes have not propagated unintended side effects
• Helps to ensure that changes do not introduce unintended behavior or additional
errors
• May be done manually or through the use of automated capture/playback tools
• Regression test suite contains three different classes of test cases
• A representative sample of tests that will exercise all software functions
• Additional tests that focus on software functions that are likely to be affected by
the change
• Tests that focus on the actual software components that have been changed
• Regression Testing helps to ensure that changes do not introduce
unintended behviour or additional errors

136
Smoke testing
• A Common approach for creating “daily builds” for product software
• Taken from the world of hardware
• Power is applied and a technician checks for sparks, smoke, or other dramatic
signs of fundamental failure
• Designed as a pacing mechanism for time-critical projects
• Allows the software team to assess its project on a frequent basis
• Includes the following activities
• The software is compiled and linked into a build
• A series of breadth tests is designed to expose errors that will keep the build
from properly performing its function
• The goal is to uncover “show stopper” errors that have the highest likelihood of
throwing the software project behind schedule
• The build is integrated with other builds and the entire product is smoke tested
daily
• Daily testing gives managers and practitioners a realistic assessment of the
progress of the integration testing
• After a smoke test is completed, detailed test scripts are executed

137
SMOKE testing - benefits
• Integration risk is minimized
• Daily testing uncovers incompatibilities and show-stoppers early in the testing
process, thereby reducing schedule impact
• The quality of the end-product is improved
• Smoke testing is likely to uncover both functional errors and architectural and
component-level design errors
• Error diagnosis and correction are simplified
• Smoke testing will probably uncover errors in the newest components that
were integrated
• Progress is easier to assess
• As integration testing progresses, more software has been integrated and
more has been demonstrated to work
• Managers get a good indication that progress is being made

138
SMOKE testing - benefits
• Integration risk is minimized
• Daily testing uncovers incompatibilities and show-stoppers early in the testing
process, thereby reducing schedule impact
• The quality of the end-product is improved
• Smoke testing is likely to uncover both functional errors and architectural and
component-level design errors
• Error diagnosis and correction are simplified
• Smoke testing will probably uncover errors in the newest components that
were integrated
• Progress is easier to assess
• As integration testing progresses, more software has been integrated and
more has been demonstrated to work
• Managers get a good indication that progress is being made

139
Test strategies – object oriented software
• With object-oriented software, you can no longer test a single
operation in isolation (conventional thinking)
• Traditional top-down or bottom-up integration testing has little
meaning
• Class testing for object-oriented software is the equivalent of unit
testing for conventional software
• Focuses on operations encapsulated by the class and the state
behavior of the class
• Because a class can contain a number of different operations,
and a particular operation may exist as part of a number of
different classes, the tactics applied to unit testing must change

140
• You can no longer test a single operation in isolation (the
conventional view of unit testing) but rather as part of a class
• To illustrate the above point , consider a class hierarchy in which an operation X is defined
for the superclass and is inherited by a number of subclasses. The context in which operation
X is used varies in subtle ways
• So it is necessary to test operation X in the context of each of the subclasses.
• This means that testing operation X in a stand-alone fashion (the conventional unit-testing
approach) is usually ineffective in the object-oriented context.
• class testing for OO software is driven by the operations encapsulated by
the class and the state behavior of the class
• Drivers can be used
• To test operations at the lowest level and for testing whole groups of classes
• To replace the user interface so that tests of system functionality can be conducted prior
to implementation of the actual interface
• Stubs can be used
• In situations in which collaboration between classes is required but one or more of the
collaborating classes has not yet been fully implemented

141
Integration testing – oo software
• Because object-oriented software does not have an obvious hierarchical
control structure, traditional top-down and bottom-up integration
strategies have little meaning
• There are two different strategies for integration testing of OO systems
– Thread-based testing
• Integrates the set of classes required to respond to one input or event for the system
• Each thread is integrated and tested individually
• Regression testing is applied to ensure that no side effects occur
– Use-based testing
• First tests the independent classes that use very few, if any, server classes
• Then the next layer of classes, called dependent classes, are integrated
• This sequence of testing layer of dependent classes continues until the entire system
is constructed

142
Test strategy – web apps
• Adopts the basic principles for all software testing and applies a
strategy and tactics that are used for object-oriented systems
• Summary
• The content model for the WebApp is reviewed to uncover errors.
• 2. The interface model is reviewed to ensure that all use cases can be
• accommodated.
• 3. The design model for the WebApp is reviewed to uncover navigation
errors.
• 4. The user interface is tested to uncover errors in presentation and/or
navigation mechanics.

143
• 5. Each functional component is unit tested.
• 6. Navigation throughout the architecture is tested.
• 7. The WebApp is implemented in a variety of different environmental
configurations
• and is tested for compatibility with each configuration.
• 8. Security tests are conducted in an attempt to exploit vulnerabilities in
the
• WebApp or within its environment.
• 9. Performance tests are conducted.
• 10. The WebApp is tested by a controlled and monitored population of
end users.

144
Validation testing
• It follows the after the integration testing, when individual components have been
exercised, the software is completely assembled as a package, and interfacing
errors have been uncovered and corrected.
• The distinction between conventional and object-oriented software
disappears
• Focuses on user-visible actions and user-recognizable output from the
system
• Demonstrates conformity with requirements
the main goal of validation testing is To ensure the software meets
user requirements
• Designed to ensure that
– All functional requirements are satisfied
– All behavioral characteristics are achieved

145
Contd..
– All performance requirements are attained
– Documentation is correct
– Usability and other requirements are met (e.g., transportability,
compatibility, error recovery, maintainability)
• After each validation test
– The function or performance characteristic conforms to specification and is accepted
– A deviation from specification is uncovered and a deficiency list is created
• A configuration review or audit ensures that all elements of the software
configuration have been properly developed, cataloged, and have the necessary
detail for entering the support phase of the software life cycle

146
Alpha and beta testing
• Alpha testing
– Conducted at the developer’s site by end users
– Software is used in a natural setting with developers watching intently
– Testing is conducted in a controlled environment
• Beta testing
– Conducted at end-user sites
– Developer is generally not present
– It serves as a live application of the software in an environment that
cannot be controlled by the developer
– The end-user records all problems that are encountered and reports these
to the developers at regular intervals
• After beta testing is complete, software engineers make software
modifications and prepare for release of the software product to the
entire customer base

147
Acceptance testing
• A variation on beta testing, called customer acceptance testing,
is sometimes performed when custom software is delivered to a
customer under contract.
• The customer performs a series of specific tests in an attempt to
uncover errors beforeaccepting the software from the developer.
• In some cases (e.g., a major corporate orgovernmental system)
acceptance testing can be very formal and encompass many days
or even weeks of testing.

148
System testing
System testing method checks the software system as a whole
system.
• Recovery Testing
• Security Testing
• Stress Testing
• Performance Testing
• Deployment Testing

149
Recovery testing & security testing
• Recovery testing
• Tests for recovery from system faults
• Forces the software to fail in a variety of ways and verifies that
recovery is properly performed
• Tests reinitialization, checkpointing mechanisms, data recovery, and
restart for correctness
• Security testing
• Verifies that protection mechanisms built into a system will, in fact, protect
it from improper access or penetration

150
Stress testing
• Stress testing
• Executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume Stress testing executes a system in a manner that demands
resources in abnormal quantity, frequency, or volume
• Examples
• (1) special tests may be designed that generate ten interrupts per second, when
one or two is the average rate,
• (2) input data rates may be increased by an order of magnitude to determine how
input functions will respond,
• (3) test cases that require maximum memory or other resources are executed,
• (4) test cases that may cause thrashing in a virtual operating system are designed,
• (5) test cases that may cause excessive hunting for disk-resident data are created.
Essentially, the tester attempts to break the program.

151
sensitivity testing
• Variation of Stress Testing
• In some situations (the most common occur in mathematical algorithms), a very
small range ofdata contained within the bounds of valid data for a program may
cause extreme and even erroneous processing or profound performance
degradation.
• Sensitivity testing attempts to uncover data combinations within valid input
classes that may cause instability or improper processing.

152
Performance testing
– Tests the run-time performance of software within the context of an
integrated system
– Often coupled with stress testing and usually requires both hardware and
software instrumentation
• It is often necessary to measure resource utilization (e.g., processor cycles) in an
exacting fashion. External instrumentation can monitor execution intervals, log
events (e.g., interrupts) as they occur, and sample machine states on a regular
basis.
– Can uncover situations that lead to degradation and possible system failure

153
Deployment testing
• Deployment testing, sometimes called configuration testing, exercises the
software in each environment in which it is to operate.
• In addition, deployment testing examines all installation procedures and
specialized installation software (e.g., “installers”) that will be used by
customers, and all documentation that will be used to introduce the
software to end users.
• A more thorough deployment test might encompass combinations of Web
browsers with various operating systems (e.g., Linux, Mac OS, Windows).
• Because security is a major issue, a complete set of security tests would be
integrated with the deployment test.

154
Testing fundamentals - characteristics
• Operable
• The better it works (i.e., better quality), the
easier it is to test
• Observable
• Incorrect output is easily identified; internal
errors are automatically detected
• Controllable
• The states and variables of the software can
be controlled directly by the tester
• Decomposable
• The software is built from independent
modules that can be tested independently
• Simple

155
Test Characteristics
• A good test has a high probability of finding an error
• The tester must understand the software and how it might fail
• A good test is not redundant
• Testing time is limited; one test should not serve the same purpose as another test
• A good test should be “best of breed”
• Tests that have the highest likelihood of uncovering a whole class of errors should be used
• A good test should be neither too simple nor too complex
• Each test should be executed separately; combining a series of tests could cause side
effects and mask certain errors

System Testing and Debugging
In this section, we are going to understand the difference
between Testing and Debugging. Both the terminologies are the integral parts of
SDLC as both are used at the different phase of Software Development Life
Cycle and gives distinct types of outcomes.
At the time of development and after the outcome of any application or the software
product established in any programming language, both Testing and
Debugging play a vital role in finding and removing mistakes.
Note: Both Testing and Debugging are two words that seem to share a similar meaning but
intensively different from one another.
They have quite an equivalent function, but they are diverse in terms of designs,
requirements, benefits, and performance.
Therefore, it is required for us to understand the differences between testing and
debugging properly that will support us in receiving better software development
outcomes.
• Before we see the difference between testing and debugging, we will discuss
the in-detail evaluation of testing and debugging, which will help us distinguish
both of them appropriately.

Debugging process
Debugging is the process of identifying and fixing code defects

Software Testing
Software testing is a process of identifying defects in the software product. It is
performed to validate the behavior of the software or the application compared
to requirements.
In other words, we can say that the testing is a collection of techniques to
determine the accuracy of the application under the predefined specification
but, it cannot identify all the defects of the software.
• Each software or application needs to be tested before delivering to the clients
and checks whether the particular software or the application is working fine as
per the given requirements.

What is Debugging?
As opposed to Testing, Debugging is the action where the development team or a
developer implements after receiving the test report related to the bugs in the
software from the testing team.
In the software development process, debugging includes detecting and modifying
code errors in a software program.
In debugging process, the developer needs to identify the reason behind the
particular bug or defect, which is carried out by analyzing the coding
rigorously.
• The developer changes the code and then rechecks whether the defect has
been deleted whenever the bug or error is found.

Once the debugging is successfully finished, the application is again sent back to
the test engineers, who remain in the process of testing.
The debugging process allows us an earlier finding of an error and makes software
development stress-free and easy.
• Now, based on features and technique of practice, we can distinguish
between Testing and Debugging.
Testing Vs. Debugging

S.NO Testing Debugging
1. It is the implementation of the software with the intent of identifying the defects The process of fixing and resolving the defects is
known as debugging.
2. Testing can be performed either manually or with the help of some automation tools. The debugging process cannot be automated.
3. A group of test engineers executes testing, and sometimes it can be performed by the
developers.
Debugging is done by the developer or the
programmer.
4. The test engineers perform manual and automated test cases on the application, and if they
detect any bug or error, they can report back to the development team for fixing.
The developers will find, evaluates, and removes
the software errors.
5. Programming knowledge is not required to perform the testing process. Without having an understanding of the
programming language, we cannot proceed with
the debugging process.
6. Once the coding phase is done, we proceed with the testing process. After the implementation of the test case, we can
start the Debugging process.
7. Software Testing includes two or more activities such as validation and verification of the
software.
Debugging tries to match indication with cause,
hence leading to the error correction.
8. It is built on different testing levels such as Unit Testing, Integration Testing, System Testing,
etc.
It is built on different kinds of bugs because there
is no such level of debugging is possible.
9. Software testing is the presentation of defects. It is a logical procedure.
10. Software testing is the vital phase of SDLC (Software Development Life Cycle). It is not a part of SDLC because it occurs as a
subset of testing.

Software Engineering and Project Management - A Beginner's Guide - Part 4

More Related Content

Similar to Software Engineering and Project Management - A Beginner's Guide - Part 4 (20)

Recently uploaded (20)

Software Engineering and Project Management - A Beginner's Guide - Part 4