Unit 3

Chapter 3
DESIGN CONCEPTS AND
TESTING
 SYLLABUS
• The Design Concepts
• The Design Model
• Architectural Design
• User Interface Design: Interface Analysis
• Interface Design Steps
• Requirements Modeling
• Software Testing Fundamentals
• Black Box Testing
• White Box Testing
• Unit Testing
• Integration Testing
• Validation testing
• System testing
• Art of debugging
• Project management
 Design Concepts
Software Design is the process to transform the user
requirements into some suitable form, which helps the
programmer in software coding and implementation.
During the software design phase, the design document is
produced, based on the customer requirements as documented in
the SRS document. The following items are designed and
documented during the design phase:
– Different modules required.
– Control relationships among modules.
– Interface among different modules.
– Data structure among the different modules.
– Algorithms required to implement among the individual
modules.
 Design Concepts
Objectives of Software Design:
– Correctness
– Efficiency
– Understandability
– Completeness
– Maintainability

Software Design Concepts:

The software design concept simply means the idea or principle
behind the design. It describes how you plan to solve the
problem of designing software, the logic, or thinking behind how
you will design software. It allows the software engineer to
create the model of the system or software or product that is to
be developed or built.
 Design Concepts
The following points should be considered while designing
Software:
- Abstraction- hide Irrelevant data
– Modularity- subdivide the system
– Architecture- design a structure of something
– Refinement- removes impurities
– Pattern- a repeated form
– Information Hiding- hide the information
– Refactoring- reconstruct something
Different levels of Software Design
– Architectural Design
– Preliminary or high-level design
– Detailed design
 Design Concepts
The software design process can be divided into the following three
levels of phases of design:
– Interface Design
– Architectural Design
– Detailed Design
The software design process can be divided into the following three
levels of phases of design:
– Interface Design
• Precise description of events in the environment, or
messages from agents to which the system must respond.
• Precise description of the events or messages that the
system must produce.
• Specification on the data, and the formats of the data
coming into and going out of the system.
 Design Concepts
• Specification of the ordering and timing relationships
between incoming events or messages, and outgoing
events or outputs.
– Architectural Design
• Gross decomposition of the systems into major
components.
• Allocation of functional responsibilities to components.
• Component Interfaces
• Component scaling and performance properties, resource
consumption properties, reliability properties, and so forth.
• Communication and interaction between components.
– Detailed Design
• Decomposition of major system components into program
units.
 Design Concepts
– Detailed Design
• Decomposition of major system components into program
units.
• Allocation of functional responsibilities to units.
• User interfaces
• Unit states and state changes
• Data and control interaction between units
• Data packaging and implementation, including issues of
scope and visibility of program elements
• Algorithms and data structures

– Outcome of the Design Process - The following items are

designed and documented during the design phase.
 Design Concepts
• Different modules required:
– The different modules in the solution should be clearly
identified.
– Each module is a collection of functions and the data shared by
the functions of the module.
– Each module should accomplish some well-defined task out of
the overall responsibility of the software.
• Control relationships among modules:
– A control relationship between two modules essentially arises
due to function calls across the two modules.
– The control relationships existing among various modules
should be identified in the design document.
• Interfaces among different modules:
– The interfaces between two modules identifies the exact data
items that are exchanged between the two modules
 Design Concepts
• Data structures of the individual modules:
– Suitable data structures for storing and managing the data of a
module need to be properly designed and documented.
• Algorithms required implementing the individual modules:
– Each function in a module usually performs some processing
activity.
– The algorithms required to accomplish the processing activities
of various modules need to be carefully designed and
documented with due considerations given to the accuracy of
the results, space and time complexities.
• Classification of Design Activities –
– A good software design is seldom realised by using a single
step procedure, rather it requires iterating over a series of
steps called the design activities.
– We can broadly classify them into two important stages.
 Design Concepts
• Preliminary (or high-level) design, and
• Detailed design.
• The meaning and scope of these two stages can vary considerably
from one design methodology to another.
– Traditional function-oriented design approach,
– The objectives of the high-level design as follows:
• High-level design-
– Problem is decomposed into a set of modules.
– Control relationships among the modules & interfaces among
various modules are identified.
– The outcome of high-level design is called the program
structure or the software architecture.
– Problem Decomposed into many small functionally
independent modules that are cohesive, have low coupling
 The Design Concepts
– Many different types of notations have been used to represent
a high-level design.
• Function-oriented design -
– Another popular design representation techniques called UML
that is being used to document object-oriented design
– Involves developing several types of diagrams to document the
object-oriented design of a systems.
– Once the high-level design is complete, detailed design is
undertaken.
– The outcome of the detailed design stage is usually
documented in the form of a module specification (MSPEC)
document.
– The data structures and algorithms to be used described using
MSPEC and can be easily grasped by programmers for initiating
coding.
 The design model
Design modeling in software engineering represents the features
of the software that helps engineer to develop it effectively, the
architecture, the user interface, and the component level
detail.
Working of Design Modeling in Software Engineering - Designing a
model is an important phase and is a multi-process that
represent the data structure, program structure, interface
characteristic, and procedural details. It is mainly classified into
four categories
• Data design: It represents the data objects and their
interrelationship in an entity-relationship diagram.
• Architectural design: It defines the relationship between major
structural elements of the software. It is about decomposing
the system into interacting components.
 The design model
• User Interfaces design: It represents how the Software
communicates with the user i.e. the behavior of the system.
• Component level design: It transforms the structural elements
of the software architecture into a procedural description of
software components.
Principles of Design Model
– Design must be traceable to the analysis model
– Always consider architecture of the system to be built
– Focus on the design of the data
– User interfaces should consider the user first
– Components should be loosely coupled
– Interfaces both user and internal must be designed
– Component level design should exhibit Functional
independence
 The design model
Following are the types of design elements:
1. Data design elements
2. Architectural design elements
– The information about the application domain to built the
software.
– Requirement model elements like data flow diagram or analysis
classes, relationship and collaboration between them.
– The architectural style and pattern as per availability.
3. Interface design elements
1. The user interface.
2. The external interface to the other systems, networks etc.
3. The internal interface between various components.
4. Component level diagram elements
5. Deployment level design elements
The design model
 Architectural Design
• The design phase of software development deals with
transforming the customer requirements as described in the SRS
documents into a form implementable using a programming
language. Three levels of phases of design:
• Interface Design
• Architectural Design
• Detailed Design
• The software needs the architectural design to represents the
design of software. IEEE defines architectural design as “the
process of defining a collection of hardware and software
components and their interfaces to establish the framework for
the development of a computer system.”
• Each style will describe a system category that consists of :
– A set of components (eg: a database, computational modules)
that will perform a function required by the system.
Architectural Design
 Architectural Design
– The set of connectors will help in coordination, communication,
and cooperation between the components.
– Conditions that how components can be integrated to form the
system.
– Semantic models that help the designer to understand the
overall properties of the system.
– The use of architectural styles is to establish a structure for all
the components of the system.

• Taxonomy of Architectural styles:

• Data centered architectures:
– A data store will reside at the center of this architecture and is
accessed frequently by the other components that update, add,
delete or modify the data present within the store.
 Architectural Design
– The client software access a central repository.
– This data-centered architecture will promote integrability. This
means that the existing components can be changed and new
client components can be added to the architecture without
the permission or concern of other clients.
• Advantage of Data centered architecture
– Repository of data is independent of clients
– Client work independent of each other
– It may be simple to add additional clients.
– Modification can be very easy

• Data flow architectures:

– This kind of architecture is used when input data to be
transformed into output data through a series of
computational manipulative components.
 Architectural Design

Data centered architectures:

Data flow architectures:

 Architectural Design
– Pipe-and-filter architecture since it uses both pipe and filter
– Pipes are used to transmit data from one component to the
next.
– Filter will work independently and is designed to take data
input of a certain form and produces data output to the next
filter of a specified form.
– This structure accepts the batch of data and then applies a
series of sequential components to transform it.
• Advantage of Data Flow architecture
– It encourages upkeep, repurposing, and modification.
– With this design, concurrent execution is supported.
• Disadvantage of Data Flow architecture
– It frequently degenerates to batch sequential system
– Data flow architecture does not allow applications that require
greater user engagement.
 Architectural Design
– It is not easy to coordinate two different but related streams
• Call and Return architectures:
– It is used to create a program that is easy to scale and modify.
Many sub-styles exist within this category. Two of them are
explained below.
• Remote procedure call architecture
• Main program or Subprogram architectures
• Object Oriented architecture:
– The components of a system encapsulate data and the
operations that must be applied to manipulate the data.
– The coordination and communication between the components
are established via the message passing.
• Characteristics of Object Oriented architecture
– Object protect the system’s integrity.
– An object is unaware of the depiction of other items.
 Architectural Design
–
 Architectural Design
• Advantage of Object Oriented architecture
– It enables the designer to separate a challenge into a collection
of autonomous objects.
– Other objects are aware of the implementation details of the
object, allowing changes to be made without having an impact
on other objects.
• Layered architecture:
• A number of different layers are defined with each layer
performing a well-defined set of operations.
• Each layer will do some operations that becomes closer to
machine instruction set progressively.
– At the outer layer components will receive the user interface
operations.
– At the inner layers, components will perform the operating
system interfacing (communication and coordination with OS).
 Architectural Design
– Intermediate layers to utility services and application software
functions.
User Interface Design: Interface Analysis
• User interface is the front-end application view to which user
interacts in order to use the software.
• User can manipulate and control the software as well as hardware
by means of user interface.
• User interface is part of software and is designed such a way that
it is expected to provide the user insight of the software.
• UI provides fundamental platform for human-computer
interaction. UI can be graphical, text-based, audio-video based,
• The software becomes more popular if its user interface is:
– Attractive
– Simple to use
– Responsive in short time
– Clear to understand
– Consistent on all interfacing screens
•
User Interface Design: Interface Analysis
• UI is broadly divided into two categories:
– Command Line Interface
– Graphical User Interface
• Command Line Interface (CLI) –
– CLI has been a great tool of interaction with computers until
the video display monitors came into existence.
– CLI is first choice of many technical users and programmers. CLI
is minimum interface a software can provide to its users.
– CLI provides a command prompt, the place where the user
types the command and feeds to the system. The user needs to
remember the syntax of command and its use.
– Earlier CLI were not programmed to handle the user errors
effectively.
• CLI Elements - A text-based command line interface can have the
following elements:
User Interface Design: Interface Analysis
• Command Prompt
• Cursor
• Command
User Interface Design: Interface Analysis
• Graphical User Interface –
– Graphical User Interface provides the user graphical means to
interact with the system.
– GUI can be combination of both hardware and software.
– GUI is more resource consuming than that of CLI.

• GUI Elements - GUI provides a set of components to interact with

software or hardware.
– Window
– Tabs
– Menu
– Icon
– Cursor
User Interface Design: Interface Analysis
User Interface Design: Interface Analysis
• The analysis and design process of a user interface is iterative and
can be represented by a spiral model. The analysis and design
process of user interface consists of four framework activities.
• User, task, environmental analysis, and modeling:
– Initially, the focus is based on the profile of users
– From each category requirements are gathered.
– Once all the requirements are gathered a detailed analysis is
conducted. In the analysis part, the tasks that the user
performs to establish the goals of the system are identified,
described and elaborated.
– Among the questions to be asked are:
• Where will the interface be located physically?
• Will the user be sitting, standing, or performing other tasks
unrelated to the interface?
User Interface Design: Interface Analysis
• Does the interface hardware accommodate space, light, or
noise constraints?
• Are there special human factors considerations driven by
environmental factors?
• Interface Design:
– The goal of this phase is to define the set of interface objects
and actions
– Indicate how these control mechanisms affect the system.
Specify the action sequence of tasks and subtasks, also called a
user scenario.
– Design issues such as response time, command and action
structure, error handling, and help facilities are considered as
the design model is refined.
– This phase serves as the foundation for the implementation
phase.
User Interface Design: Interface Analysis
• Interface construction and implementation:
– The implementation activity begins with the creation of
prototype (model) that enables usage scenarios to be
evaluated.
– As iterative design process continues a User Interface toolkit
that allows the creation of windows, menus, device interaction,
and many other elements of an interactive environment can be
used for completing the construction of an interface.
• Interface Validation:
– This phase focuses on testing the interface.
– The interface should be in such a way that it should be able to
perform tasks correctly and it should be able to handle a
variety of tasks.
– It should achieve all the user’s requirements. It should be easy
to use and easy to learn.
 Interface Design Steps
• User Interface Design Activities –
– There are a number of activities performed for designing user
interface.
– The process of GUI design and implementation is alike SDLC.
– A model used for GUI design and development should fulfill
these GUI specific steps.
• GUI Requirement Gathering - The designers may like to have list of
all functional and non-functional requirements of GUI.
• User Analysis - The designer studies who is going to use the
software GUI.
• Task Analysis - Designers have to analyze what task is to be done
by the software solution.
• GUI Design & implementation - Design the GUI and implements
into code and embed the GUI with working or dummy software in
the background. It is then self-tested by the developers.
 Interface Design Steps
• Testing - Organization can have in-house inspection, direct
involvement of users and release of beta version are few of them.
• The following are the golden rules stated by Theo Mandel that
must be followed during the design of the interface.
• Place the user in control:
– Define the interaction modes in such a way that does not force
the user into unnecessary or undesired actions
– Provide for flexible interaction
– Allow user interaction to be interruptible and undoable
– Streamline interaction as skill level advances and allow the
interaction to be customized:
– Hide technical internals from casual users:
– Design for direct interaction with objects that appear on
screen:
 Interface Design Steps
• Reduce the user’s memory load:
– Reduce demand on short-term memory
– Establish meaningful defaults
– Define shortcuts that are intuitive
– The visual layout of the interface should be based on a real-
world metaphor
– Disclose information in a progressive fashion
• Make the interface consistent:
– Allow the user to put the current task into a meaningful context
– Maintain consistency across a family of applications
– If past interactive models have created user expectations do not
make changes unless there is a compelling reason.
 Requirements Modeling
• The analysis model’s goal is to provide a description of the
informational, functional, and behavioural domains
• The model evolves dynamically
• As a result, the analysis model represents a snapshot of
requirements at any given time.
• Elements of the Requirements Model –
– There are numerous approaches to analysing the requirements
– Analyse requirements from many perspectives
– The specific elements of the requirements model are dedicated
to the analysis modeling method that is to be used.
• Scenario-based elements –
– Used to describe the system from the perspective of the user.
– For example, basic use cases and their related use-case
diagrams
 Requirements Modeling
• Class-based element –
– Each usage scenario entails a collection of objects that are
modified as an actor interacts with the system.
– These objects are classified as classes— a collection of things
with similar characteristics and behaviour.
–
• Behavioural elements –
– A significant impact on the design and implementation
techniques used.
– As a result, the requirements model must include modelling
elements that represent behaviour.
– The state diagram is one approach of expressing a system’s
behaviour by illustrating its states and the events that cause the
system to change state.
 Requirements Modeling
• Flow-oriented elements –
– As data moves through a computer-based system, it is
transformed.
– The system accepts input in a variety of formats, transforms it
using functions, and produces output in a variety of forms.
• Requirement modeling strategies
– 1. Flow Oriented Modeling
– 2. Class-based Modeling
• 1. Flow Oriented Modeling - It shows how data objects are
transformed by processing the function. The Flow oriented
elements are:
• i. Data flow model
– It is a graphical technique used to represent information flow.
– The data objects are flowing within the software and
transformed by processing the elements.
 Requirements Modeling
• ii. Control flow model
– Large class applications require a control flow modeling.
– An event is implemented as a boolean value. For example, the
boolean values are true or false, on or off, 1 or 0.
• iii. Control Specification
– A short term for control specification is CSPEC.
– It represents the behaviour of the system.
– The state diagram includes states, transitions, events and
activities.
• iv. Process Specification
– A short term for process specification is PSPEC.
– The process specification is used to describe all flow model
processes.
 Requirements Modeling
• Class-based Modeling
– Class based modeling represents the object. The system
manipulates the operations.
– The elements of the class based model consist of classes and
object, attributes, operations, class – responsibility -
collaborator (CRS) models.
• Classes - Classes are determined using underlining each noun or
noun clause and enter it into the simple table.
• Classes are found in following forms
– External entities
– Things
– Occurrences or events
– Roles
– Organizational units
 Requirements Modeling
– Places
– Structures
• Attributes –
– Attributes are the set of data objects that are defining a
complete class within the context of the problem.
• Operations - The operations define the behaviour of an object.
• The operations are characterized into following types:
– The operations manipulate the data like adding, modifying,
deleting and displaying etc.
– The operations perform a computation.
– The operation monitors the objects for the occurrence of
controlling an event.
• CRS Modeling
– The CRS stands for Class-Responsibility-Collaborator.
 Requirements Modeling
– It provides a simple method for identifying and organizing the
classes that are applicable to the system or product
requirement.
– Class is an object-oriented class name. It consists of information
about sub classes and super class.
– Responsibilities are the attributes and operations that are
related to the class.
– Collaborations are identified and determined when a class can
achieve each responsibility of it. If the class cannot identify
itself, then it needs to interact with another class.
• Behavioral patterns for requirement modeling - Behavioral model
shows the response of software to an external event.
– Evaluate all the use cases to completely understand the
sequence, interaction within the system.
– Identify the event and understand the relation between the
 Requirements Modeling
– Generate a sequence for each use case.
– Construct a state diagram for the system.
– To verify the accuracy and consistency review the behavioral
model.
• Software Requirement Specification (SRS)
– The requirements are specified in specific format known as SRS.
– This document is created before starting the development
work.
– The software requirement specification is an official document.
– It shows the detail about the performance of expected system.
– SRS indicates to a developer and a customer what is
implemented in the software.
– SRS is useful if the software system is developed by the outside
contractor.
 Requirements Modeling
– SRS must include an interface, functional capabilities, quality,
reliability, privacy etc.
• Characteristics of SRS
– The SRS should be complete and consistence.
– The modification like logical and hierarchical must be allowed in
SRS.
– The requirement should be easy to implement.
– Each requirement should be uniquely identified.
– The statement in SRS must be unambiguous means it should
have only one meaning.
– All the requirement must be valid for the specified project.
 Software Testing Fundamentals
• Software testing can be stated as the process of verifying and
validating whether a software or application is bug-free, meets the
technical requirements as guided by its design and development.
• It should meets the user requirements effectively and efficiently by
handling all the exceptional and boundary cases.
• It mainly aims at measuring the specification, functionality, and
performance of a software program or application.
• Software testing can be divided into two steps:
– 1. Verification: “Are we building the product right?”
– 2. Validation: “Are we building the right product?”
• Different types of software testing
– Manual Testing: Manual testing includes testing software
manually, i.e., without using any automation tool or any script.
– There are different stages for manual testing such as unit testing,
integration testing, system testing, and user acceptance testing.
 Software Testing Fundamentals
– Automation Testing: Automation testing, which is also known
as Test Automation, is when the tester writes scripts and uses
another software to test the product.
• Types of Software Testing Techniques –
– Black Box Testing: The technique of testing in which the tester
doesn’t have access to the source code of the software
– Conducted at the software interface without any concern with
the internal logical structure of the software is known as black-
box testing.

– White-Box Testing: The technique of testing in which the tester

is aware of the internal workings of the product.
– Access to its source code, and is conducted by making sure that
all internal operations are performed according to the
specifications is known as white box testing.
 Software Testing Fundamentals
• Different levels of software testing
– Unit Testing
– Integration Testing
– System Testing
– Acceptance Testing
• Why Software Testing Is Necessary?
– An error, defect or a bug can be caused by developers.
– It is not intentional but considering the complexity with which
various software are being developed.
– It is quite possible for a developer to misunderstand and
implement wrong logic and produce wrong code.
– Testing is necessary because it helps us in identifying the faults
in software.
– A quality conscious company will definitely include software
testing in its best practices.
 Software Testing Fundamentals
• Who Does The Software Testing?
– There is often a debate on who should actually test the
software.
– A developer generally checks his code several times before he
submits it for testing and still in most cases it is never error free
because a developer is generally blind to his own mistakes.
– A tester on the other hand looks at software from the point of
view of the client. He is unbiased and his focus is only on the
specifications and the requirements.
– A tester is able to look into areas that a developer may have
ignored. So, the testing should always be carried out by
independent testers.
– Many times developers share their work amongst each other
and test each other’s work. This is known as buddy testing.
 Software Testing Fundamentals
• Software Testing Goals - The three main goals of Software Testing
are:
– Defect Detection
– Defect Prevention
– User Satisfaction
 Black Box Testing
• Black box testing is a type of software testing in which the
functionality of the software is not known.
• The testing is done without the internal knowledge of the
products. Black box testing can be done in the following ways:
– 1. Syntax-Driven Testing
– 2. Equivalence partitioning - The technique involves two steps:
• Identification of equivalence class
• Generating test cases –
• (i) To each valid and invalid class of input assign a unique
identification number.
• (ii) Write a test case covering all valid and invalid test cases
considering that no two invalid inputs mask each other.
• (a) Valid inputs:
– The whole number which is a perfect square- output will
be an integer.
 Black Box Testing
– The whole number which is not a perfect square- output
will be a decimal number.
– Positive decimals
– Negative numbers(integer or decimal).
– Characters other than numbers like “a”,”!”,”;”, etc.
– 3. Boundary value analysis
– 4. Cause effect Graphing
• Identify inputs (causes) and outputs (effect).
• Develop a cause-effect graph.
• Transform the graph into a decision table.
• Convert decision table rules to test cases.
– 5. Requirement-based testing
– 6. Compatibility testing
• Processor (Pentium 3, Pentium 4) and several processors.
Black Box Testing
 Black Box Testing
• Architecture and characteristics of machine (32-bit or 64-
bit).
• Back-end components such as database servers.
• Operating System (Windows, Linux, etc).
• Black Box Testing Type - The following are the several categories of
black box testing:
– Decision Table Technique
– Boundary Value Technique
– State Transition Technique
– All-pair Testing Technique
– Cause-Effect Technique
– Equivalence Partitioning Technique
– Error Guessing Technique
– Use Case Technique
 Black Box Testing
• Generic steps of black box testing
– Step 1 - The black box test is based on the specification of
requirements, so it is examined in the beginning.
– Step 2 - 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.
– Step 3 - The tester develops various test cases such as decision
table, all pairs test, equivalent division, error estimation, cause-
effect graph, etc.
– Step 4 - Phase includes the execution of all test cases.
– Step 5 - The tester compares the expected output against the
actual output.
– Step 6 - Final step, if there is any flaw in the software, then it is
cured and tested again.
 Black Box Testing
• Tools Used for Black Box Testing:
– Appium
– Selenium
– Microsoft Coded UI
– Applitools
– HP QTP.
• Advantages of Black Box Testing:
– The tester does not need to have more functional knowledge or
programming skills to implement the Black Box Testing.
– It is efficient for implementing the tests in the larger system.
– Tests are executed from the user’s or client’s point of view.
– Test cases are easily reproducible.
– It is used in finding the ambiguity and contradictions in the
functional specifications.
 Black Box Testing
• Disadvantages of Black Box Testing:
– There is a possibility of repeating the same tests while
implementing the testing process.
– Without clear functional specifications, test cases are difficult to
implement.
– It is difficult to execute the test cases because of complex inputs
at different stages of testing.
– Sometimes, the reason for the test failure cannot be detected.
– Some programs in the application are not tested.
– It does not reveal the errors in the control structure.
– Working with a large sample space of inputs can be exhaustive
and consumes a lot of time.
 White Box Testing
• White box testing techniques analyze the internal structures the
used data structures, internal design, code structure and the
working of the software rather than just the functionality as in
black box testing.
• It is also called glass box testing or clear box testing or structural
testing.
• Working process of white box testing:
– Input: Requirements, Functional specifications, design
documents, source code.
– Processing: Performing risk analysis for guiding through the
entire process.
– Proper test planning: Designing test cases so as to cover entire
code. Execute rinse-repeat until error-free software is reached.
Also, the results are communicated.
– Output: Preparing final report of the entire testing process.
 White Box Testing
• Testing techniques:
– Statement coverage: Aim is to traverse all statement at least
once. Hence, each line of code is tested.
 White Box Testing
– Condition Coverage: In this technique, all individual conditions
must be covered as shown in the following example:
– READ X, Y
– IF(X == 0 || Y == 0)
– PRINT ‘0’
– Multiple Condition Coverage: All the possible combinations of
the possible outcomes of conditions are tested at least once.
Let’s consider the following example:
#TC1: X = 0, Y = 0
• READ X, Y #TC2: X = 0, Y = 5
• IF(X == 0 || Y == 0) #TC3: X = 55, Y = 0
• PRINT ‘0’ #TC4: X = 55, Y = 5
– Branch Coverage: In this technique, test cases are designed so
that each branch from all decision points are traversed at least
once. In a flowchart, all edges must be traversed at least once.
White Box Testing
 White Box Testing
– Basis Path Testing: Control flow graphs are made from code or
flowchart and then Cyclomatic complexity is calculated which
defines the number of independent paths so that the minimal
number of test cases can be designed for each independent
path. Steps:
» Make the corresponding control flow graph
» Calculate the cyclomatic complexity
» Find the independent paths
» Design test cases corresponding to each independent
path
• Flow graph notation: It is a directed graph consisting of
nodes and edges.
• Cyclomatic Complexity: It is a measure of the logical
complexity of the software and is used to define the number
of independent paths.
White Box Testing
 White Box Testing
• Calculating V(G):
» V(G) = P + 1, where P is the number of predicate
nodes in the flow graph
» V(G) = E – N + 2, where E is the number of edges and
N is the total number of nodes
» V(G) = Number of non-overlapping regions in the
graph

• Example: V(G) = 4 (Using any of the above formulae) No of

independent paths = 4
» #P1: 1 – 2 – 4 – 7 – 8
» #P2: 1 – 2 – 3 – 5 – 7 – 8
» #P3: 1 – 2 – 3 – 6 – 7 – 8
» #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8
 White Box Testing
– Loop Testing: Loops are widely used and these are fundamental
to many algorithms hence, their testing is very important.
Errors often occur at the beginnings and ends of loops.
– Simple loops: For simple loops of size n, test cases are designed
that
» Skip the loop entirely
» Only one pass through the loop
» 2 passes
» m passes, where m < n
» n-1 ans n+1 passes
– 2. Nested loops: For nested loops, all the loops are set to their
minimum count and we start from the innermost loop.
– 3. Concatenated loops: Independent loops, one after another.
Simple loop tests are applied for each. If they’re not
independent, treat them like nesting.
 White Box Testing
• Advantages:
– Very thorough as the entire code and structures are tested.
– It results in the optimization of code removing error and helps
in removing extra lines of code.
– It can start at an earlier stage as it doesn’t require any interface
as in case of black box testing.
– Easy to automate.
• Disadvantages:
– It is very expensive.
– Redesign of code and rewriting code needs test cases to be
written again.
– Testers are required to have in-depth knowledge of the code
– Missing functionalities cannot be detected
– Very complex and at times not realistic.
 Unit Testing
• Unit testing involves the testing of each unit or an individual
component of the software application.
• It is the first level of functional testing. The aim behind unit testing
is to validate unit components with its performance.
• The purpose of unit testing is to test the correctness of isolated
code.
• Test engineer will start checking every component of the module
or module of the application independently or one by one, and this
process is known as Unit testing or components testing.
• Why Unit Testing? –
– First level of testing done before integration and other
remaining levels of the testing.
– It uses modules for the testing process which reduces the
dependency of waiting for Unit testing frameworks, stubs,
drivers and mock objects are used for assistance in unit testing.
 Unit Testing
• Some crucial reasons are listed below:
– Helps tester and developers to understand the base of code
that makes them able to change defect causing code quickly.
– Helps in the documentation.
– Fixes defects very early in the development phase that's why
there is a possibility to occur a smaller number of defects in
upcoming testing levels.
– Helps with code reusability by migrating code and test cases.
 Unit Testing
• Unit Testing Techniques:
– Data flow Testing
– Control Flow Testing
– Branch Coverage Testing
– Statement Coverage Testing
– Decision Coverage Testing
• How to achieve the best result via Unit testing?
– Test cases must be independent because if there is any change
or enhancement in requirement, the test cases will not be
affected.
– Naming conventions for unit test cases must be clear and
consistent.
– During unit testing, the identified bugs must be fixed before
jump on next phase of the SDLC.
– Only one code should be tested at one time.
 Unit Testing
– Adopt test cases with the writing of the code, if not doing so,
the number of execution paths will be increased.
– If there are changes in the code of any module, ensure the
corresponding unit test is available or not for that module.
• Advantages
– Unit testing uses module approach due to that any part can be
tested without waiting for completion of another parts testing.
– The developing team focuses on the provided functionality of
the unit and how functionality should look in unit test suits to
understand the unit API.
– Unit testing allows the developer to refactor code after a
number of days and ensure the module still working without
any defect.
• Disadvantages
– It cannot identify integration or broad level error as it works on
units of the code.
 Unit Testing
– In the unit testing, evaluation of all execution paths is not
possible, so unit testing is not able to catch each and every
error in a program.
– It is best suitable for conjunction with other testing activities.
• Example of Unit testing
 Integration Testing
• Integration testing is the second level of the software testing
process comes after unit testing. In this testing, units or individual
components of the software are tested in a group.
• The focus of the integration testing level is to expose defects at
the time of interaction between integrated components or units.
• The goal of integration testing is to check the correctness of
communication among all the modules.
• Once all the components or modules are working independently,
then we need to check the data flow between the dependent
modules is known as integration testing.
– Let us see one sample example of a banking application, as we
can see in the below image of amount transfer.
• Guidelines for Integration Testing
– Integration testing only after the functional testing is
completed on each module of the application.
 Integration Testing
– Picking module by module so that
a proper sequence is followed, and
also we don't miss out on any
integration scenarios.
– First, determine the test case
strategy through which executable
test cases can be prepared
according to test data.
– Examine the structure and
architecture of the application and
identify the crucial modules to test
them first and also identify all
possible scenarios.
– Design test cases to verify each
interface in detail.
 Integration Testing
– Choose input data for test case execution. Input data plays a
significant role in testing.
– If we find any bugs then communicate the bug reports to
developers and fix defects and retest.
– Perform positive and negative integration testing.
• For example: In the Gmail application
• Scenarios1:
– Login as P users and Compose mail, click on the Send and also
check for Save Drafts. After that, we send a mail to Q and
verify.
• Secanrios2:
– Integration testing on Spam folders. If the particular contact has
been marked as spam, then any mail sent by that user should
go to the spam folder and not in the inbox.
Integration Testing
 Integration Testing
• There are some features, we might be performing only
the functional testing, and there are some features where we are
performing both functional and integration testing based on the
feature's requirements.
• Prioritizing is essential, and we should perform it at all the phases,
• While performing testing, we should test one feature entirely and
then only proceed to another function.
• Among the two features, we must be performing only positive
integrating testing or both positive and negative
integration testing, and this also depends on the features need.
• Reason Behind Integration Testing -
– Each module is designed by individual software developer
whose programming logic may differ from developers
– To check the interaction of software modules with the database
whether it is an erroneous or not.
 Integration Testing
– Requirements can be changed or enhanced at the time of
module development.
– Incompatibility between modules of software could create
errors.
– To test hardware's compatibility with software.
– If exception handling is inadequate between modules, it can
create bugs.
• Integration Testing Techniques
– Black Box Testing
• All-pairs Testing
• State Transition technique • Cause and Effect Graph
• Decision Table Technique • Equivalence Partitioning
• Boundary Value Analysis • Error Guessing
• Types of Integration Testing -
– Incremental integration testing
– Non-incremental integration testing
 Integration Testing

• Incremental Approach –
• Modules are added in ascending order one by one or according
to need. The selected modules must be logically related.
• Generally, two or more than two modules are added and tested
to determine the correctness of functions. The process continues
until the successful testing of all the modules.
 Integration Testing
– For example: Suppose we have a Flipkart application, we will
perform incremental integration testing, and the flow of the
application would like this:
– Flipkart→ Login→ Home → Search→ Add cart→Payment →
Logout
– Incremental integration testing is carried out by further
methods:
• Top-Down approach
• Bottom-Up approach
• Top-Down Approach –
– The top-down testing strategy deals with the process in which
higher level modules are tested with lower level modules until
the successful completion of testing of all the modules.
– Major design flaws can be detected and fixed early because
critical modules tested first.
 Integration Testing
– In the top-down approach, we will be ensuring that the module
we are adding is the child of the previous one like Child C is a
child of Child B and so on as we can see in the below image:
• Advantages:
– Identification of defect is difficult.
– An early prototype is possible.
• Disadvantages:
– Due to the high number of stubs, it gets quite complicated.
– Lower level modules are tested inadequately.
– Critical Modules are tested first so that fewer chances of
defects.
• Bottom-Up Method –
– The bottom to up testing strategy deals with the process in
which lower level modules are tested with higher level modules
until the successful completion of testing of all the modules.
 Integration Testing
– Top level critical modules are tested at last, so it may cause a
defect. Or we can say that we will be adding the modules
from bottom to the top and check the data flow in the same
order.
• Advantages
– Identification of defect is easy.
– Do not need to wait for the development of all the modules as
it saves time.
• Disadvantages
– Critical modules are tested last due to which the defects can
occur.
– There is no possibility of an early prototype.
• Hybrid Testing Method
– In this approach, both Top-Down and Bottom-Up approaches
are combined for testing.
 Integration Testing
– In this process, top-level modules are tested with lower level
modules and lower level modules tested with high-level
modules simultaneously.
– There is less possibility of occurrence of defect because each
module interface is tested.
• Advantages
– The hybrid method provides features of both Bottom Up and
Top Down methods.
– It is most time reducing method.
– It provides complete testing of all modules.
• Disadvantages
– This method needs a higher level of concentration as the
process carried out in both directions simultaneously.
– Complicated method.
 Integration Testing
• Non- incremental integration testing
– When the data flow is very complex and when it is difficult to
find who is a parent and who is a child. And in such case, we
will create the data in any module bang on all other existing
modules and check if the data is present. Hence, it is also
known as the Big bang method.
• Big Bang Method
– In this approach, testing is done via integration of all modules at
once.
– Since this testing can be done after completion of all modules
due to that testing team has less time for execution of this
process so that internally linked interfaces and high-risk critical
modules can be missed easily.
• Advantages:
– It is convenient for small size software systems.
 Integration Testing
• Disadvantages
– Identification of defects is difficult because finding the error
where it came from is a problem, and we don't know the source
of the bug.
– Small modules missed easily.
– Time provided for testing is very less.
– We may miss to test some of the interfaces.
• Example1
– Development team develops the application and sends it to the
CEO of the testing team.
Integration Testing
 Validation testing
• Validation is the process of checking whether the software product
is up to the mark or in other words product has high level
requirements.
• It is the process of checking the validation of product i.e. it checks
what we are developing is the right product. it is validation of
actual and expected product. Validation is the Dynamic Testing.
• This mode of testing is extremely important especially if you want
to be one of the best software testers. The software verification
and validation testing is the process after the validation testing
stage is secondary to verification testing.
• Why is Validation Testing Important? The Advantages of Validation
Testing :
– To ensure customer satisfaction
– To be confident about the product
– To fulfill the client’s requirement until the optimum capacity
 Validation testing
• Software acceptance from the end-user
• Whenever any particular software is tested then the main motive
is to check the quality against the defects being found.

• Putting Further Emphasis –

– The point of programming testing is to quantify the nature of
programming as far as various deformities found in it, the
number of tests run and the framework secured by the tests.
– At the point when bugs or deformities are found with the
assistance of testing, the bugs are logged and the development
group fixes them.
– We have explored the basics and importance of validation
testing along with its emphasis on an industrial and user level,
let us further explore the phases and stages that are involved in
churning out a plan for validation testing.
 Validation testing
• What are the Phases of the Validation Testing Process?
– Define Requirements
– Team Selection
– Maintaining Documentation
– Validation Report
– Incorporation of changes
• What are the Types of Validation Testing? –
– Validation testing types a V-shaped testing pattern, which
includes its variations and all the activities that it consists of
are:
– Unit Testing
– Integration testing
– System testing
– User acceptance testing
 System testing
• System Testing includes testing of a fully integrated software
system.
• The software is developed in units and then interfaced with other
software and hardware to create a complete computer system.
• System testing is a series of different type of tests with the purpose
to exercise and examine the full working of an integrated software
computer system against requirements.
• To check the end-to-end flow of an application or the software as a
user is known as System testing. It is end-to-end testing where the
testing environment is similar to the production environment.
• There are four levels of software testing: unit testing, integration
testing, system testing and acceptance testing, all are used for the
testing purpose.
• Hierarchy of Testing Levels
– Two widely used methods for software testing
 System testing
– White box testing
– Black box testing
• System testing falls under Black
box testing as it includes testing
of the external working of the
software. System Testing
includes the following steps.
• Verification of input functions
of the application to test
whether it is producing the
expected output or not.
• Testing of integrated software by including external peripherals
to check the interaction of various components with each other.
• Testing of the whole system for End to End testing.
• Behavior testing of the application via auser's experience
 System testing
• Example of System testing
• Suppose we open an application, let say www.rediff.com, and
there we can see that an advertisement is displayed on the top of
the homepage, and it remains there for a few seconds before it
disappears. These types of Ads are done by the Advertisement
Management System (AMS). Now, we will perform system testing
for this type of field.
• The various system test scenarios are as follows:
• Scenario1: The test engineer will do the system testing for the
underlying situation where the Amazon manager creates a request
for the Ad and that Ad is used at a particular date and time.
• Scenario2: Suppose the Amazon manager feels that the AD space
is too expensive and cancels the request. At the same time, the
Flipkart requests the Ad space on January 26 at 10:00 AM. Then
the request of Amazon has been canceled. Therefore, Flipkart's
promotion ad must be arranged on January 26 at 10 AM.
 System testing
• Types of System Testing - System testing is divided into more than
50 types, but software testing companies typically uses some of
them. These are listed below:
– Regression Testing
– Load Testing
– Functional Testing
– Recovery Testing
– Migration Testing
– Usability Testing
– Software and Hardware Testing
• Why is System Testing Important?
– System Testing gives hundred percent assurance of system
performance as it covers end to end function of the system.
– It includes testing of System software architecture and business
 System testing
– It helps in mitigating live issues and bugs even after production.
– System testing uses both existing system and a new system to
feed same data in both and then compare the differences in
functionalities of added and existing functions so, the user can
understand benefits of new added functions of the system.
• Testing Any Application –
– Test the Gmail application to understand how functional,
integration, and System testing works.
 Art of debugging
• In the context of software engineering, debugging is the process of
fixing a bug in the software.
• It refers to identifying, analyzing, and removing errors. This activity
begins after the software fails to execute properly and concludes
by solving the problem and successfully testing the software.
• Debugging Process:
– Debugging is not testing but always occurs as a consequence of
testing.
– The debugging process begins with the execution of a test case.
Results are assessed and a lack of correspondence between
expected and actual performance is encountered.
– The debugging process attempts to match symptom with cause,
thereby leading to error correction.
• Steps involved in debugging are:
– Problem identification and report preparation.
 Art of debugging
– Assigning the report to the software engineer to the defect to
verify that it is genuine.
– Defect Analysis using modeling, documentation, finding and
testing candidate flaws, etc.
– Defect Resolution by making required changes to the system.
– Validation of corrections.
• The debugging process will always have one of two outcomes :
– 1. The cause will be found and corrected.
– 2. The cause will not be found.
• During debugging, we encounter errors that range from mildly
annoying to catastrophic. As the consequences of an error
increase, the amount of pressure to find the cause also increases.
• Debugging Approaches/Strategies:
– Brute Force
 Art of debugging
– Backtracking
– Forward analysis
– Using the past experience
– Cause elimination
• Debugging Tools:
– Debugging tool is a computer program that is used to test and
debug other programs.
– A lot of public domain software like gdb and dbx are available
for debugging. They offer console-based command-line
interfaces. Examples of automated debugging tools include
code based tracers, profilers, interpreters, etc. Some of the
widely used debuggers are:
– Radare2
– WinDbg
– Valgrind
 Art of debugging
• Difference Between Debugging and Testing:
– Testing focuses on finding bugs, errors, etc whereas debugging
starts after a bug has been identified in the software.
– Testing is used to ensure that the program is correct and it was
supposed to do with a certain minimum success rate where
During debugging, we encounter errors that range from mildly
annoying to catastrophic.
– Debugging requires a lot of knowledge, skills, and expertise. In
comparison to testing
– Testing can be manual or automated, where Debugging can be
supported by some automated tools available but is more of a
manual process as every bug is different
– There are several different types of testing like unit testing,
integration testing, alpha and beta testing, etc. where
Debugging requires a different technique, unlike a pre-defined
 Project management
• Once a project is found to be possible, computer code project
managers undertake project designing. Project designing is
undertaken and completed even before any development activity
starts. Project designing consists of subsequent essential activities:
Estimating the subsequent attributes of the project:
– Project size: What’s going to be downside quality in terms of the
trouble and time needed to develop the product?
– Cost: What proportion is it reaching to value to develop the
project?
– Duration: However long is it reaching to want complete
development?
– Effort: What proportion effort would be required?
• Need of Software Project Management –
– The most significant is that the underlying technology changes
and advances so generally and rapidly that experience of one
element may not be connected to the other one.
 Project management
– All such business and ecological imperatives bring risk in
software development
• Software Project Manager –
– Software manager is responsible for planning and scheduling
project development. They manage the work to ensure that it
is completed to the required standard. They monitor the
progress to check that the event is on time and within budget.
• To plan a successful software project, we must understand:
– Scope of work to be completed
– Risk analysis
– The resources mandatory
– The project to be accomplished
– Record of being followed
 Project management
• Software Project planning starts before technical work start. The
size is the crucial parameter for the estimation of other activities.
• Resources requirement are required based on cost and
development time.
• The effectiveness of the following designing activities relies on the
accuracy of those estimations.
– Planning force and alternative resources
– Workers organization and staffing plans
– Risk identification, analysis, and abatement designing
– Miscellaneous arranges like quality assurance plan,
configuration, management arrange, etc.
Project management
 Project management
• Precedence ordering among project planning activities: The
different project connected estimates done by a project manager
have already been mentioned. It may be simply discovered that
size estimation is that the 1st activity and all alternative coming up
with activities.
• Sliding Window Planning: Project designing needs utmost care and
a spotlight since commitment to unrealistic time and resource
estimates end in schedule slippage. Schedule delays will cause
client discontent and adversely have an effect on team morale. So
as to beat this drawback, generally project managers undertake
project designing little by little. This method of staggered designing
is thought of as the window technique, beginning with associate
initial set up.
 Project estimation techniques
• Estimation of the size of the software is an essential part of
Software Project Management. It helps the project manager to
further predict the effort and time which will be needed to build
the project. Various measures are used in project size
estimation. Some of these are:
1. Lines of Code (LOC): LOC count the total number of lines of
source code in a project. The units of LOC are:
– KLOC- Thousand lines of code
– NLOC- Non-comment lines of code
– KDSI- Thousands of delivered source instruction
2. Number of entities in ER diagram: ER model provides a static
view of the project. It describes the entities and their
relationships. The number of entities in ER model can be used
to measure the estimation of the size of the project.
 Project estimation techniques
3. Total number of processes in detailed data flow diagram: Data
Flow Diagram(DFD) represents the functional view of software.
The model depicts the main processes/functions involved in
software and the flow of data between them.
4. Function Point Analysis: In this method, the number and type of
functions supported by the software are utilized to find
FPC(function point count). The steps in function point analysis are:
• Count the number of functions of each proposed type.
• External Inputs
• External outputs
• External Inquiries
• Internal Files
• External interface Files
• Compute the Unadjusted Function Points(UFP).
 Project estimation techniques
• Find Total Degree of Influence(TDI).
The 14 general characteristics are: Data Communications,
Distributed Data Processing, Performance, Heavily Used
Configuration, Transaction Rate, On-Line Data Entry, End-user
Efficiency, Online Update, Complex Processing Reusability,
Installation Ease, Operational Ease, Multiple Sites and
Facilitate Change.
• Compute Value Adjustment Factor(VAF).
[ VAF = (TDI * 0.01) + 0.65 ]
• Find the Function Point Count(FPC).
FPC = UFP * VAF
 Project scheduling
A schedule in your project’s time table actually consists of
sequenced activities and milestones that are needed to be
delivered under a given period of time. Effective project
scheduling leads to success of project, reduced cost, and
increased customer satisfaction. Scheduling in project
management means to list out activities, deliverables, and
milestones within a project that are delivered. The most
common and important form of project schedule is Gantt
chart.
 Project scheduling
To schedule the project plan, a software project manager wants to
do the following:
– Identify all the functions required to complete the project.
– Break down large functions into small activities.
– Determine the dependency among various activities.
– Establish the most likely size for the time duration required to complete
the activities.
– Allocate resources to activities.
– Plan the beginning and ending dates for different activities.
– Determine the critical path. A critical way is the group of activities that
decide the duration of the project.
The first method in scheduling a software plan involves
identifying all the functions required to complete the project.
Next, the large functions are broken down into a valid set of
small activities which would be assigned to various engineers.
 Project scheduling
Dependency among the various activities determines the order in
which the various events would be carried out. The
dependency among the activities is defined in the pattern of
an activity network. Resource allocation is usually done using a
Gantt chart. After resource allocation is completed, a PERT
chart representation is developed.
Process : The manager needs to estimate time and resources of
project while scheduling project. All activities in project must
be arranged in a coherent sequence that means activities
should be arranged in a logical and well-organized manner for
easy to understand.
Problems arise during Project Development Stage :
• People may leave or remain absent during particular stage of
development.
• Hardware may get failed while performing.
 Project scheduling
• Software resource that is required may not be available at present,
etc.
Resources required for Development of Project :
• Human effort
• Sufficient disk space on server
• Specialized hardware
• Software technology
• Travel allowance required by project staff, etc.
Advantages of Project Scheduling :
• It simply ensures that everyone remains on same page.
• It helps in identifying issues.
• It also helps to identify relationships and to monitor process.
• It provides effective budget management and risk mitigation.
 Risk analysis and management
Risk Analysis in project management is a sequence of processes to
identify the factors that may affect a project’s success. These
processes include risk identification, analysis of risks, risk
management and control, etc.
How to Manage Risk? - Risk Management in Software Engineering
primarily involves following activities:
– Plan risk management
– Risk Identification
• Project scope statement
• Cost management plan
• Schedule management plan
• Human resource management plan
• Scope baseline
• Risk management plan
 Risk analysis and management
• The Risk Analysis Process in Project Management - The risk
analysis process is what follows the Identification of Risks
procedure and is distinguished by two clear categories
• Qualitative Risk Analysis is the process during which one
prioritizes risks for further action by assessing their probability
of impacting project development.
– Risk probability and impact assessment
– Impact risk rating matrix
– Risk categorization
– Risk urgency assessment
– Expert judgment
• Quantitative Risk Analysis Process aims to numerically analyze
the possibility of every risk and its effect on project objectives,
as well as the degree of overall project risk.
 Risk analysis and management
– Interviewing stakeholders
– Sensitivity analysis
– Expected monetary values analysis (EMV)
– Modeling and simulation
– Cost risk analysis
– Schedule risk analysis
– Expert judgment
• Plan risk responses - To enhance opportunities and to
minimize threats to project objectives plan risk response is
helpful. It addresses the risks by their priority, activities into the
budget, schedule, and project management plan. The inputs for
plan risk responses are
– Risk management plan
– Risk register
 Risk analysis and management
• Control Risks - Control risk is the procedure of tracking
identified risks, identifying new risks, monitoring residual risks
and evaluating risk. The inputs for this stage includes
– Software Project management plan
– Risk register
– Work performance data
– Work performance reports