SOFTWARE TESTING UNIT II

SOFTWARE DEVELOPMENT MODEL AND TESTING

WATERFALL MODEL
Waterfall model

Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration
and system testing, and operation and maintenance. The steps always follow in this order and
do not overlap. The developer must complete every phase before the next phase begins. This
model is named "Waterfall Model", because its diagrammatic representation resembles a
cascade of waterfalls.

Requirements analysis and specification phase:

The aim of this phase is to understand the exact requirements of the customer and to document
them properly. Both the customer and the software developer work together so as to document
all the functions, performance, and interfacing requirement of the software. It describes the
"what" of the system to be produced and not "how."

In this phase, a large document called Software Requirement Specification (SRS) document is
created which contained a detailed description of what the system will do in the common
language.
The Waterfall Model was the first Process Model to be introduced. It is also referred to as a
linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model,
each phase must be completed before the next phase can begin and there is no overlapping in
the phases.
The Waterfall model is the earliest SDLC approach that was used for software development.
The waterfall Model illustrates the software development process in a linear sequential flow.
This means that any phase in the development process begins only if the previous phase is
complete. In this waterfall model, the phases do not overlap.
Waterfall Model - Design
Waterfall approach was first SDLC Model to be used widely in Software Engineering to ensure
success of the project. In "The Waterfall" approach, the whole process of software development
is divided into separate phases. In this Waterfall model, typically, the outcome of one phase
acts as the input for the next phase sequentially.
The following illustration is a representation of the different phases of the Waterfall Model.
The sequential phases in Waterfall model are −
• Requirement Gathering and analysis − All possible requirements of the system
to be developed are captured in this phase and documented in a requirement
specification document.
• System Design − The requirement specifications from first phase are studied in
this phase and the system design is prepared. This system design helps in
specifying hardware and system requirements and helps in defining the overall
system architecture. Implementation − With inputs from the system design,
the system is first developed in small programs called units, which are integrated
in the next phase. Each unit is developed and tested for its functionality, which
is referred to as Unit Testing.
• Integration and Testing − All the units developed in the implementation phase
are integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
• Deployment of system − Once the functional and non-functional testing is done;
the product is deployed in the customer environment or released into the market.
• Maintenance − There are some issues which come up in the client environment.
To fix those issues, patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment.
All these phases are cascaded to each other in which progress is seen as flowing steadily
downwards (like a waterfall) through the phases. The next phase is started only after the defined
set of goals are achieved for previous phase and it is signed off, so the name "Waterfall Model".
In this model, phases do not overlap.

Waterfall Model - Application

Every software developed is different and requires a suitable SDLC approach to be followed
based on the internal and external factors. Some situations where the use of Waterfall model is
most appropriate are −
• Requirements are very well documented, clear and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are available to support the product.
• The project is short.

Waterfall Model - Advantages

The advantages of waterfall development are that it allows for departmentalization and control.
A schedule can be set with deadlines for each stage of development and a product can proceed
through the development process model phases one by one.
Development moves from concept, through design, implementation, testing, installation,
troubleshooting, and ends up at operation and maintenance. Each phase of development
proceeds in strict order.
Some of the major advantages of the Waterfall Model are as follows −
• Simple and easy to understand and use
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.

Waterfall Model - Disadvantages

The disadvantage of waterfall development is that it does not allow much reflection or revision.
Once an application is in the testing stage, it is very difficult to go back and change something
that was not well-documented or thought upon in the concept stage.
The major disadvantages of the Waterfall Model are as follows −
• No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk
of changing. So, risk and uncertainty is high with this process model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early.
 SPIRAL MODEL
The spiral model combines the idea of iterative development with the systematic, controlled
aspects of the waterfall model. This Spiral model is a combination of iterative development
process model and sequential linear development model i.e. the waterfall model with a very
high emphasis on risk analysis. It allows incremental releases of the product or incremental
refinement through each iteration around the spiral.
Spiral Model - Design
The spiral model has four phases. A software project repeatedly passes through these phases in
iterations called Spirals.
Identification
This phase starts with gathering the business requirements in the baseline spiral. In the
subsequent spirals as the product matures, identification of system requirements, subsystem
requirements and unit requirements are all done in this phase.
This phase also includes understanding the system requirements by continuous communication
between the customer and the system analyst. At the end of the spiral, the product is deployed
in the identified market.
Design
The Design phase starts with the conceptual design in the baseline spiral and involves
architectural design, logical design of modules, physical product design and the final design in
the subsequent spirals.
Construct or Build
The Construct phase refers to production of the actual software product at every spiral. In the
baseline spiral, when the product is just thought of and the design is being developed a POC
(Proof of Concept) is developed in this phase to get customer feedback.
Then in the subsequent spirals with higher clarity on requirements and design details a working
model of the software called build is produced with a version number. These builds are sent to
the customer for feedback.
Evaluation and Risk Analysis
Risk Analysis includes identifying, estimating and monitoring the technical feasibility and
management risks, such as schedule slippage and cost overrun. After testing the build, at the
end of first iteration, the customer evaluates the software and provides feedback.
The following illustration is a representation of the Spiral Model, listing the activities in each
phase.
Based on the customer evaluation, the software development process enters the next iteration
and subsequently follows the linear approach to implement the feedback suggested by the
customer. The process of iterations along the spiral continues throughout the life of the
software.
Spiral Model Application
The Spiral Model is widely used in the software industry as it is in sync with the natural
development process of any product, i.e. learning with maturity which involves minimum risk
for the customer as well as the development firms.
The following pointers explain the typical uses of a Spiral Model −
• When there is a budget constraint and risk evaluation is important.
• For medium to high-risk projects.
• Long-term project commitment because of potential changes to economic
priorities as the requirements change with time.
• Customer is not sure of their requirements which is usually the case.
• Requirements are complex and need evaluation to get clarity.
• New product line which should be released in phases to get enough customer
feedback.
• Significant changes are expected in the product during the development cycle.
Spiral Model - Pros and Cons
The advantage of spiral lifecycle model is that it allows elements of the product to be added in,
when they become available or known. This assures that there is no conflict with previous
requirements and design.
This method is consistent with approaches that have multiple software builds and releases
which allows making an orderly transition to a maintenance activity. Another positive aspect
of this method is that the spiral model forces an early user involvement in the system
development effort.
On the other side, it takes a very strict management to complete such products and there is a
risk of running the spiral in an indefinite loop. So, the discipline of change and the extent of
taking change requests is very important to develop and deploy the product successfully.
The advantages of the Spiral SDLC Model are as follows −
• Changing requirements can be accommodated.
• Allows extensive use of prototypes.
• Requirements can be captured more accurately.
• Users see the system early.
• Development can be divided into smaller parts and the risky parts can be
developed earlier which helps in better risk management.
The disadvantages of the Spiral SDLC Model are as follows −
• Management is more complex.
• End of the project may not be known early.
• Not suitable for small or low risk projects and could be expensive for small
projects.
• Process is complex
• Spiral may go on indefinitely.
• Large number of intermediate stages requires excessive documentation.

V MODEL
The V-model is an SDLC model where execution of processes happens in a sequential manner
in a V-shape. It is also known as Verification and Validation model.
The V-Model is an extension of the waterfall model and is based on the association of a testing
phase for each corresponding development stage. This means that for every single phase in the
development cycle, there is a directly associated testing phase. This is a highly-disciplined
model and the next phase starts only after completion of the previous phase.
V-Model – Design
Under the V-Model, the corresponding testing phase of the development phase is planned in
parallel. So, there are Verification phases on one side of the ‘V’ and Validation phases on the
other side. The Coding Phase joins the two sides of the VModel.
The following illustration depicts the different phases in a V-Model of the SDLC.
V-Model – Verification Phases
There are several Verification phases in the V-Model, each of these are explained in detail
below.
Business Requirement Analysis
This is the first phase in the development cycle where the product requirements are understood
from the customer’s perspective. This phase involves detailed communication with the
customer to understand his expectations and exact requirement. This is a very important activity
and needs to be managed well, as most of the customers are not sure about what exactly they
need. The acceptance test design planning is done at this stage as business requirements can be
used as an input for acceptance testing.
System Design
Once you have the clear and detailed product requirements, it is time to design the complete
system. The system design will have the understanding and detailing the complete hardware
and communication setup for the product under development. The system test plan is developed
based on the system design. Doing this at an earlier stage leaves more time for the actual test
execution later.
Architectural Design
Architectural specifications are understood and designed in this phase. Usually more than one
technical approach is proposed and based on the technical and financial feasibility the final
decision is taken. The system design is broken down further into modules taking up different
functionality. This is also referred to as High Level Design (HLD).
The data transfer and communication between the internal modules and with the outside world
(other systems) is clearly understood and defined in this stage. With this information,
integration tests can be designed and documented during this stage.
Module Design
In this phase, the detailed internal design for all the system modules is specified, referred to as
Low Level Design (LLD). It is important that the design is compatible with the other modules
in the system architecture and the other external systems. The unit tests are an essential part of
any development process and helps eliminate the maximum faults and errors at a very early
stage. These unit tests can be designed at this stage based on the internal module designs.
Coding Phase
The actual coding of the system modules designed in the design phase is taken up in the Coding
phase. The best suitable programming language is decided based on the system and
architectural requirements.
The coding is performed based on the coding guidelines and standards. The code goes through
numerous code reviews and is optimized for best performance before the final build is checked
into the repository.
Validation Phases
The different Validation Phases in a V-Model are explained in detail below.
Unit Testing
Unit tests designed in the module design phase are executed on the code during this validation
phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though
all defects cannot be uncovered by unit testing.
Integration Testing
Integration testing is associated with the architectural design phase. Integration tests are
performed to test the coexistence and communication of the internal modules within the system.
System Testing
System testing is directly associated with the system design phase. System tests check the entire
system functionality and the communication of the system under development with external
systems. Most of the software and hardware compatibility issues can be uncovered during this
system test execution.
Acceptance Testing
Acceptance testing is associated with the business requirement analysis phase and involves
testing the product in user environment. Acceptance tests uncover the compatibility issues with
the other systems available in the user environment. It also discovers the non-functional issues
such as load and performance defects in the actual user environment.
V- Model ─ Application
V- Model application is almost the same as the waterfall model, as both the models are of
sequential type. Requirements have to be very clear before the project starts, because it is
usually expensive to go back and make changes. This model is used in the medical development
field, as it is strictly a disciplined domain.
The following pointers are some of the most suitable scenarios to use the V-Model application.
• Requirements are well defined, clearly documented and fixed.
• Product definition is stable.
• Technology is not dynamic and is well understood by the project team.
• There are no ambiguous or undefined requirements.
• The project is short.
V-Model – Pros and Cons
The advantage of the V-Model method is that it is very easy to understand and apply. The
simplicity of this model also makes it easier to manage. The disadvantage is that the model is
not flexible to changes and just in case there is a requirement change, which is very common
in today’s dynamic world, it becomes very expensive to make the change.
The dventages of the V-Model method are as follows –
• This is a highly-disciplined model and Phases are completed one at a time.
• Works well for smaller projects where requirements are very well understood.
• Simple and easy to understand and use.
• Easy to manage due to the rigidity of the model. Each phase has specific
deliverables and a review process.
The disadvantages of the V-Model method are as follows –
• High risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to high risk
of changing.
• Once an application is in the testing stage, it is difficult to go back and change a
functionality.
• No working software is produced until late during the life cycle.

AGILE MODEL
Agile SDLC model is a combination of iterative and incremental process models with focus on
process adaptability and customer satisfaction by rapid delivery of working software product.
Agile Methods break the product into small incremental builds. These builds are provided in
iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves
cross functional teams working simultaneously on various areas like −

• Planning

• Requirements Analysis

• Design

• Coding

• Unit Testing and

• Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and important
stakeholders.
What is Agile?
Agile model believes that every project needs to be handled differently and the existing
methods need to be tailored to best suit the project requirements. In Agile, the tasks are divided
to time boxes (small time frames) to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each
build is incremental in terms of features; the final build holds all the features required by the
customer.
Here is a graphical illustration of the Agile Model −

The Agile thought process had started early in the software development and started becoming
popular with time due to its flexibility and adaptability.
The most popular Agile methods include Rational Unified Process (1994), Scrum (1995),
Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven
Development, and Dynamic Systems Development Method (DSDM) (1995). These are now
collectively referred to as Agile Methodologies, after the Agile Manifesto was published in
2001.
Following are the Agile Manifesto principles −
• Individuals and interactions − In Agile development, self-organization and
motivation are important, as are interactions like co-location and pair
programming.
 • Working software − Demo working software is considered the best means of
communication with the customers to understand their requirements, instead of
just depending on documentation.
• Customer collaboration − As the requirements cannot be gathered completely in
the beginning of the project due to various factors, continuous customer
interaction is very important to get proper product requirements.
• Responding to change − Agile Development is focused on quick responses to
change and continuous development.
Agile Vs Traditional SDLC Models
Agile is based on the adaptive software development methods, whereas the traditional SDLC
models like the waterfall model is based on a predictive approach.
Predictive teams in the traditional SDLC models usually work with detailed planning and have
a complete forecast of the exact tasks and features to be delivered in the next few months or
during the product life cycle.
Predictive methods entirely depend on the requirement analysis and planning done in the
beginning of cycle. Any changes to be incorporated go through a strict change control
management and prioritization.
Agile uses an adaptive approach where there is no detailed planning and there is clarity on
future tasks only in respect of what features need to be developed. There is feature driven
development and the team adapts to the changing product requirements dynamically. The
product is tested very frequently, through the release iterations, minimizing the risk of any
major failures in future.
Customer Interaction is the backbone of this Agile methodology, and open communication with
minimum documentation are the typical features of Agile development environment. The agile
teams work in close collaboration with each other and are most often located in the same
geographical location.
Agile Model - Pros and Cons
Agile methods are being widely accepted in the software world recently. However, this method
may not always be suitable for all products. Here are some pros and cons of the Agile model.
The advantages of the Agile Model are as follows −
• Is a very realistic approach to software development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly and demonstrated.
• Resource requirements are minimum. Suitable for fixed or changing
requirements Delivers early partial working solutions.
• Good model for environments that change steadily.
• Minimal rules, documentation easily employed.
• Enables concurrent development and delivery within an overall planned context.
• Little or no planning required.
• Easy to manage.
• Gives flexibility to developers.
The disadvantages of the Agile Model are as follows −
• Not suitable for handling complex dependencies.
 • More risk of sustainability, maintainability and extensibility.
• An overall plan, an agile leader and agile PM practice is a must without which it
will not work.
• Strict delivery management dictates the scope, functionality to be delivered, and
adjustments to meet the deadlines.
• Depends heavily on customer interaction, so if customer is not clear, team can
be driven in the wrong direction.
• There is a very high individual dependency, since there is minimum
documentation generated.
• Transfer of technology to new team members may be quite challenging due to
lack of documentation.

LIFE CYCLE OF SOFTWARE TESTING

Software Testing Life Cycle (STLC) is a sequence of different activities performed during
the software testing process.
Characteristics of STLC:
• STLC is a fundamental part of Software Development Life Cycle (SDLC) but
STLC consists of only the testing phases.
• STLC starts as soon as requirements are defined or software requirement
document is shared by stakeholders.
• STLC yields a step-by-step process to ensure quality software. In the initial
stages of STLC, while the software product or the application is being
developed, the testing team analyzes and defines the scope of testing, entry and
exit criteria and also the test cases. It helps to reduce the test cycle time and also
enhance the product quality.
As soon as the development phase is over, testing team is ready with test cases and start the
execution. This helps in finding bugs in the early phase.
Phases of STLC:

1. Requirement Analysis:
Requirement Analysis is the first step of Software Testing Life Cycle (STLC). In
this phase quality assurance team understands the requirements like what is to be
 tested. If anything is missing or not understandable then quality assurance team
meets with the stakeholders to better understand the detail knowledge of
requirement.
2. Test Planning:
Test Planning is most efficient phase of software testing life cycle where all
testing plans are defined. In this phase manager of the testing team calculates
estimated effort and cost for the testing work. This phase gets started once the
requirement gathering phase is completed.
3. Test Case Development:
The test case development phase gets started once the test planning phase is
completed. In this phase testing team note down the detailed test cases. Testing
team also prepare the required test data for the testing. When the test cases are
prepared then they are reviewed by quality assurance team.
4. Test Environment Setup:
Test environment setup is the vital part of the STLC. Basically test environment
decides the conditions on which software is tested. This is independent activity
and can be started along with test case development. In this process the testing
team is not involved. either the developer or the customer creates the testing
environment.
5. Test Execution:
After the test case development and test environment setup test execution phase
gets started. In this phase testing team start executing test cases based on prepared
test cases in the earlier step.
6. Test Closure:
This is the last stage of STLC in which the process of testing is analyzed.

STATIC TESTING

Static Testing is a type of a Software Testing method which is performed to check the defects
in software without actually executing the code of the software application. Whereas in
Dynamic Testing checks the code is executed to detect the defects.
Static testing is performed in early stage of development to avoid errors as it is easier to find
sources of failures and it can be fixed easily. The errors that can’t not be found using
Dynamic Testing, can be easily found by Static Testing.
Static Testing Techniques:
There are mainly two type techniques used in Static Testing:

1. Review:
In static testing review is a process or technique that is performed to find the potential defects
in the design of the software. It is process to detect and remove errors and defects in the
different supporting documents like software requirements specifications. People examine the
documents and sorted out errors, redundancies and ambiguities.
Review is of four types:
• Informal:
In informal review the creator of the documents put the contents in front of
audience and everyone gives their opinion and thus defects are identified in the
early stage.
• Walkthrough:
It is basically performed by experienced person or expert to check the defects so
that there might not be problem further in the development or testing phase.
• Peer review:
Peer review means checking documents of one-another to detect and fix the
defects. It is basically done in a team of colleagues.
• Inspection:
Inspection is basically the verification of document the higher authority like the
verification of software requirement specifications (SRS).
2. Static Analysis:
Static Analysis includes the evaluation of the code quality that is written by developers.
Different tools are used to do the analysis of the code and comparison of the same with the
standard.
It also helps in following identification of following defects:
(a) Unused variables
(b) Dead code
(c) Infinite loops
(d) Variable with undefined value
(e) Wrong syntax
Static Analysis is of three types:
• Data Flow:
Data flow is related to the stream processing.
• Control Flow:
Control flow is basically how the statements or instructions are executed.
• Cyclomatic Complexity:
Cyclomatic complexity is the measurement of the complexity of the program that
is basically related to the number of independent paths in the control flow graph
of the program.

DYNAMIC TESTING

Dynamic Testing is a type of Software Testing which is performed to analyze the dynamic
behavior of the code. It includes the testing of the software for the input values and output
values that are analyzed.
Dynamic Testing is basically performed to describe the dynamic behavior of code. It refers to
the observation of the physical response from the system to variables that are not constant
and change with time. To perform dynamic testing the software should be compiled and run.
It includes working with the software by giving input values and checking if the output is as
expected by executing particular test cases which can be done with either manually or with
automation process.
In 2 V’s i.e., Verification and Validation, Validation is Dynamic Testing.
Levels of Dynamic Testing:
There are various levels of Dynamic Testing. They are:
• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing

Dynamic Testing Process Phase:

Advantages of Dynamic Testing:

 • It discloses very difficult and complex defects.
• Dynamic testing detects the defects that can’t be detected by static testing.
• It increases the quality of the software product or application being tested.
• Dynamic testing detects security threats and ensure the better secure application.
Disadvantages of Dynamic Testing:
• It is a time consuming process as in dynamic testing whole code is executed.
• It increases the budget of the software as dynamic testing is costly.

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.
Testing techniques:
• Statement coverage: In this technique, the aim is to traverse all statement at least
once. Hence, each line of code is tested. In case of a flowchart, every node must
be traversed at least once. Since all lines of code are covered, helps in pointing out
faulty code.

Statement Coverage Example

• 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.
 4 test cases required such that all branches of all decisions are covered,

i.e, all edges of flowchart are covered

• Condition Coverage: In this technique, all individual conditions must

be covered as shown in the following example:
1. READ X, Y
2. IF(X == 0 || Y == 0)
3. PRINT ‘0’
In this example, there are 2 conditions: X == 0 and Y == 0. Now, test these
conditions get TRUE and FALSE as their values. One possible example would be:
• #TC1 – X = 0, Y = 55
• #TC2 – X = 5, Y = 0
• Multiple Condition Coverage: In this technique, all the possible
combinations of the possible outcomes of conditions are tested at least
once. Let’s consider the following example:
0. READ X, Y
1. IF(X == 0 || Y == 0) 2. PRINT ‘0’
• #TC1: X = 0, Y = 0
• #TC2: X = 0, Y = 5
• #TC3: X = 55, Y = 0
• #TC4: X = 55, Y = 5
Hence, four test cases required for two individual conditions.
Similarly, if there are n conditions then 2n test cases would be required.
• Basis Path Testing: In this technique, control flow graphs are made
from code or flowchart and then Cyclomatic complexity is calculated
 which defines the number of independent paths so that the minimal
number of test cases can be designed for each independent path.
Steps:
0. Make the corresponding control flow graph
1. Calculate the cyclomatic complexity
2. Find the independent paths
3. Design test cases corresponding to each independent path
Flow graph notation: It is a directed graph consisting of nodes and edges. Each node
represents a sequence of statements, or a decision point. A predicate node is the one
that represents a decision point that contains a condition after which the graph splits.
Regions are bounded by nodes and edges.

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

and is used to define the number of independent paths. For a graph G, V(G) is its
cyclomatic complexity.
Calculating V(G):
4. V(G) = P + 1, where P is the number of predicate nodes in the flow
graph
5. V(G) = E – N + 2, where E is the number of edges and N is the total
number of nodes
6. 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
• 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.
0. 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
1. Nested loops: For nested loops, all the loops are set to their minimum
count and we start from the innermost loop. Simple loop tests are
conducted for the innermost loop and this is worked outwards till all
the loops have been tested.
2. Concatenated loops: Independent loops, one after another. Simple loop
tests are applied for each.
If they’re not independent, treat them like nesting.
Advantages:
1. White box testing is very thorough as the entire code and structures are tested.
2. It results in the optimization of code removing error and helps in removing extra
lines of code.
3. It can start at an earlier stage as it doesn’t require any interface as in case of black
box testing.
4. Easy to automate.
Disadvantages:
1. Main disadvantage is that it is very expensive.
2. Redesign of code and rewriting code needs test cases to be written again.
3. Testers are required to have in-depth knowledge of the code and programming
language as opposed to black box testing.
4. Missing functionalities cannot be detected as the code that exists is tested.
5. Very complex and at times not realistic.

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.
Prerequisite - Software Testing | Basics
Black box testing can be done in the following ways:
1. Syntax Driven Testing – This type of testing is applied to systems that can be
syntactically represented by some language. For example- compilers, language that can be
represented by context-free grammar. In this, the test cases are generated so that each
grammar rule is used at least once.
2. Equivalence partitioning – It is often seen that many types of inputs work similarly so
instead of giving all of them separately we can group them and test only one input of each
group. The idea is to partition the input domain of the system into several equivalence classes
such that each member of the class works similarly, i.e., if a test case in one class results in
some error, other members of the class would also result in the same error. The technique
involves two steps:
1. Identification of equivalence class – Partition any input domain into a minimum of
two sets: valid values and invalid values. For example, if the valid range is 0 to
100 then select one valid input like 49 and one invalids like 104.
2. Generating test cases – (i) To each valid and invalid class of input assigns 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. To calculate the square
root of a number, the equivalence classes will be: (a) Valid inputs:
• The whole number which is a perfect square- output will be an integer.
• The whole number which is not a perfect square- output will be a
decimal number.
• Positive decimals
• Negative numbers(integer or decimal).
• Characters other that numbers like “a”,”!”,”;”,etc.
3. Boundary value analysis – Boundaries are very good places for errors to occur. Hence
if test cases are designed for boundary values of the input domain then the efficiency of
testing improves and the probability of finding errors also increases. For example – If the
valid range is 10 to 100 then test for 10,100 also apart from valid and invalid inputs.
4. Cause effect Graphing – This technique establishes a relationship between logical
input called causes with corresponding actions called the effect. The causes and effects are
represented using Boolean graphs. The following steps are followed:
1. Identify inputs (causes) and outputs (effect).
2. Develop a cause-effect graph.
3. Transform the graph into a decision table.
4. Convert decision table rules to test cases. For example, in the following cause-
effect graph:

It can be converted into a decision table like:

Each column corresponds to a rule which will become a test case for testing. So there will be
4 test cases.
5. Requirement-based testing – It includes validating the requirements given in the SRS
of a software system.
6. Compatibility testing – The test case result not only depends on the product but is also
on the infrastructure for delivering functionality. When the infrastructure parameters are
changed it is still expected to work properly. Some parameters that generally affect the
compatibility of software are:
1. Processor (Pentium 3, Pentium 4) and several processors.
2. Architecture and characteristics of machine (32 bit or 64 bit).
3. Back-end components such as database servers.
4. Operating System (Windows, Linux, etc).
Black Box Testing Type
The following are the several categories of black box testing:
1. Functional Testing
2. Regression Testing
3. Nonfunctional Testing (NFT)
Functional Testing: It determines the system’s software functional requirements. Regression
Testing: It ensures that the newly added code is compatible with the existing code. In other
words, a new software update has no impact on the functionality of the software. This is
carried out after a system maintenance operation and upgrades.
Nonfunctional Testing: Nonfunctional testing is also known as NFT. This testing is not
functional testing of software. It focuses on the software’s performance, usability, and
scalability.
Tools Used for Black Box Testing:
1. Appium
2. Selenium
3. Microsoft Coded UI
4. Applitools 5. 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.
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.

REGRESSION TESTING

Regression Testing is the process of testing the modified parts of the code and the parts that
might get affected due to the modifications to ensure that no new errors have been introduced
in the software after the modifications have been made. Regression means return of
something and in the software field, it refers to the return of a bug.
When to do regression testing?
• When a new functionality is added to the system and the code has been modified
to absorb and integrate that functionality with the existing code.
• When some defect has been identified in the software and the code is debugged to
fix it.
• When the code is modified to optimize its working.
Process of Regression testing:
Firstly, whenever we make some changes to the source code for any reasons like adding new
functionality, optimization, etc. then our program when executed fails in the previously
designed test suite for obvious reasons. After the failure, the source code is debugged in order
to identify the bugs in the program. After identification of the bugs in the source code,
appropriate modifications are made. Then appropriate test cases are selected from the already
existing test suite which covers all the modified and affected parts of the source code. We can
add new test cases if required. In the end regression testing is performed using the selected
test cases.
Techniques for the selection of Test cases for Regression Testing:
• Select all test cases: In this technique, all the test cases are selected from the
already existing test suite. It is the most simple and safest technique but not much
efficient.
• Select test cases randomly: In this technique, test cases are selected randomly from
the existing test-suite but it is only useful if all the test cases are equally good in
their fault detection capability which is very rare. Hence, it is not used in most of
the cases.
• Select modification traversing test cases: In this technique, only those test cases
are selected which covers and tests the modified portions of the source code the
parts which are affected by these modifications.
• Select higher priority test cases: In this technique, priority codes are assigned to
each test case of the test suite based upon their bug detection capability, customer
requirements, etc. After assigning the priority codes, test cases with highest
priorities are selected for the process of regression testing.
Test case with highest priority has highest rank. For example, test case with
priority code 2 is less important than test case with priority code 1.
Tools for regression testing: In regression testing, we generally select the test cases form the
existing test suite itself and hence, we need not to compute their expected output and it can be
easily automated due to this reason. Automating the process of regression testing will be very
much effective and time saving.
Most commonly used tools for regression testing are:
• Selenium
• WATIR (Web Application Testing In Ruby)
• QTP (Quick Test Professional)
• RFT (Rational Functional Tester)
• Winrunner Silktest
Advantages of Regression Testing:
• It ensures that no new bugs has been introduced after adding new functionalities to
the system.
• As most of the test cases used in Regression Testing are selected from the existing
test suite and we already know their expected outputs.
Hence, it can be easily automated by the automated tools.
• It helps to maintain the quality of the source code.
Disadvantages of Regression Testing:
• It can be time and resource consuming if automated tools are not used.
• It is required even after very small changes in the code.

INTEGRATION TESTING

Integration testing is the process of testing the interface between two software units or
modules. It focuses on determining the correctness of the interface. The purpose of
integration testing is to expose faults in the interaction between integrated units. Once all the
modules have been unit tested, integration testing is performed.
Integration test approaches – There are four types of integration testing approaches. Those
approaches are the following:
1. Big-Bang Integration Testing – It is the simplest integration testing approach, where
all the modules are combined and the functionality is verified after the completion of
individual module testing. In simple words, all the modules of the system are simply put
together and tested. This approach is practicable only for very small systems. If an error is
found during the integration testing, it is very difficult to localize the error as the error may
potentially belong to any of the modules being integrated. So, debugging errors reported
during big bang integration testing is very expensive to fix.
Advantages:
• It is convenient for small systems.
Disadvantages:
• There will be quite a lot of delay because you would have to wait for all the
modules to be integrated.
• High risk critical modules are not isolated and tested on priority since all modules
are tested at once.
2. Bottom-Up Integration Testing – In bottom-up testing, each module at lower levels is
tested with higher modules until all modules are tested. The primary purpose of this
integration testing is that each subsystem tests the interfaces among various modules making
up the subsystem. This integration testing uses test drivers to drive and pass appropriate data
to the lower level modules.
Advantages:
• In bottom-up testing, no stubs are required.
• A principle advantage of this integration testing is that several disjoint subsystems
can be tested simultaneously.
Disadvantages:
• Driver modules must be produced.
• In this testing, the complexity that occurs when the system is made up of a large
number of small subsystems.
3. Top-Down Integration Testing – Top-down integration testing technique is used in
order to simulate the behaviour of the lower-level modules that are not yet integrated. In this
integration testing, testing takes place from top to bottom. First, high-level modules are tested
and then low-level modules and finally integrating the low-level modules to a high level to
ensure the system is working as intended.
Advantages:
• Separately debugged module.
• Few or no drivers needed.
• It is more stable and accurate at the aggregate level.
Disadvantages:
• Needs many Stubs.
• Modules at lower level are tested inadequately.
4. Mixed Integration Testing – A mixed integration testing is also called sandwiched
integration testing. A mixed integration testing follows a combination of top down and
bottom-up testing approaches. In top-down approach, testing can start only after the top-level
module have been coded and unit tested. In bottom-up approach, testing can start only after
the bottom level modules are ready. This sandwich or mixed approach overcomes this
shortcoming of the top-down and bottom-up approaches.
Advantages:
• Mixed approach is useful for very large projects having several sub projects.
• This Sandwich approach overcomes this shortcoming of the top-down and bottom-
up approaches.
Disadvantages:
• For mixed integration testing, it requires very high cost because one part has Top-
down approach while another part has bottom-up approach.
• This integration testing cannot be used for smaller systems with huge
interdependence between different modules.

SYSTEM AND PERFORMANCE TESTING

Performance Testing is a type of software testing that ensures software applications to

perform properly under their expected workload. It is a testing technique carried out to
determine system performance in terms of sensitivity, reactivity and stability under a
particular workload.
Performance Testing is the process of analyzing the quality and capability of a product. It is a
testing method performed to determine the system performance in terms of speed, reliability
and stability under varying workload. Performance testing is also known as Perf Testing.
Performance Testing Attributes:
• Speed:
It determines whether the software product responds rapidly.
• Scalability:
It determines amount of load the software product can handle at a time.
• Stability:
It determines whether the software product is stable in case of varying workloads.
• Reliability:
It determines whether the software product is secure or not.
Objective of Performance Testing:
1. The objective of performance testing is to eliminate performance congestion.
2. It uncovers what is needed to be improved before the product is launched in
market.
3. The objective of performance testing is to make software rapid.
4. The objective of performance testing is to make software stable and reliable.
Types of Performance Testing:
1. Load testing:
It checks the product’s ability to perform under anticipated user loads. The
objective is to identify performance congestion before the software product is
launched in market.
2. Stress testing:
It involves testing a product under extreme workloads to see whether it handles
high traffic or not. The objective is to identify the breaking point of a software
product.
3. Endurance testing:
It is performed to ensure the software can handle the expected load over a long
period of time.
4. Spike testing:
It tests the product’s reaction to sudden large spikes in the load generated by
users.
5. Volume testing:
 In volume testing large number of data is saved in a database and the overall
software system’s behavior is observed. The objective is to check product’s
performance under varying database volumes.
6. Scalability testing:
In scalability testing, software application’s effectiveness is determined in scaling
up to support an increase in user load. It helps in planning capacity addition to your software
system. Performance Testing Process:

Performance Testing Tools:

1. Jmeter
2. Open STA
3. Load Runner
4. Web Load
Advantages of Performance Testing :
• Performance testing ensures the speed, load capability, accuracy and other
performances of the system.
• It identifies, monitors and resolves the issues if anything occurs.
• It ensures the great optimization of the software and also allows large number of
users to use it on same time.
• It ensures the client as well as end-customers satisfaction.
Disadvantages of Performance Testing :
• Sometimes, users may find performance issues in the real time environment.
• Team members who are writing test scripts or test cases in the automation tool
should have high-level of knowledge.
• Team members should have high proficiency to debug the test cases or test scripts.
• Low performances in the real environment may lead to lose large number of users.

USABILITY TESTING

You design a product (say a refrigerator) and when it becomes completely ready, you need a
potential customer to test it so as to check its working. To understand whether or not the
machine is ready to come on the market, the machines are tested by potential customers.
Likewise, the best example of usability testing is when the software also undergoes various
testing process which is performed by potential users before launching into the market. It is a
part of the software development lifecycle (SDLC).
Without much ado, let’s focus on what is usability testing, why it should be performed, and
the phases involved in it.
Here are some major pointers which are covered in this article:
1. What is Usability Testing?
2. Phases of Usability Testing
3. Techniques/Methods of Usability Testing 4. Need for Usability Testing
5. Why Usability Testing?
6. Pros and Cons of Usability Testing What is Usability
Testing?
Several tests are performed on a product before deploying it. You need to collect qualitative
and quantitative data and satisfy customers’ needs with the product. A proper final report is
made mentioning the changes required in the product (software). Usability Testing in software
testing is a type of testing, that is done from an end user’s perspective to determine if the system
is easily usable. Usability testing is generally the practice of testing how to easy a design is to
use on a group of representative users. A very common mistake in usability testing is
conducting a study too late in the design process If you wait until right before your product is
released, you won’t have the time or money to fix any issues – and you’ll have wasted a lot of
effort developing your product the wrong way.
This testing has a cycle wherein when –
1. the product is ready,
2. customers are asked to test it,
3. if found any further changes,
4. product (software) is returned to the development team with feedback to update
the changes,
5. again the software had to run usability testing,
6. if there’re no more changes required,
7. the software is launched in the market.
This whole process from 1 to 5 is repeated unless the software is completely ready and there
are no further changes required. This process helps you to meet customers’ needs and identify
the problems faced by customers during the usage of the software. Usability Testing is also
referred to as User Experience.
Phases of Usability Testing
There are five phases in usability testing which are followed by the system when usability
testing is performed. These are given below:

1. Prepare your product or design to test: The first phase of usability testing is choosing
a product and then making it ready for usability testing. For usability testing, more
functions and operations are required than this phase provided that type of
requirement. Hence this is one of the most important phases in usability testing.
2. Find your participants: The second phase of usability testing is finding an employee
who is helping you with performing usability testing. Generally, the number of
participants that you need is based on a number of case studies. Generally, five
participants are able to find almost as many usability problems as you’d find using
many more test participants.
3. Write a test plan: This is the third phase of usability testing. The plan is one of the
first steps in each round of usability testing is to develop a plan for the test. The
main purpose of the plan is to document what you are going to do, how you are
going to conduct the test, what metrics you are going to find, the number of
participants you are going to test, and what scenarios you will use.
4. Take on the role of the moderator: This is the fourth phase of usability testing and
here the moderator plays a vital role that involves building a partnership with the
participant. Most of the research findings are derived by observing the participant’s
actions and gathering verbal feedback to be an effective moderator, you need to be
able to make instant decisions while simultaneously overseeing various aspects of
the research session.
5. Present your findings/ final report: This phase generally involves combining your
results into an overall score and presenting it meaningfully to your audience. An
easy method to do this is to compare each data point to a target goal and represent
this as one single metric based on a percentage of users who achieved this goal.
Techniques/Methods of Usability Testing
There are various types of usability testing that when performed lead to efficient software. But
few of them which are the most widely used have been discussed here.

1. Guerilla Testing

It is a type of testing where testers wander to public places and ask random users about the
prototype. Also, a thank gift is offered to the users as a gesture of token. It is the best way to
perform usability testing during the early phases of the product development process. Users
generally spare 5-10 minutes and give instant feedback on the product. Also, the cost is
comparatively low as you don’t need to hire participants. It is also known as corridor or hallway
testing.
2. Usability Lab

Usability lab testing is conducted in a lab environment where moderators (who ask for feedback
on the product) hire participants and ask them to take a survey on the product. This test is
performed on a tablet/desktop. The participant count can be 810 which is a bit costlier than
Guerilla testing as you need to hire participants, arrange a place, and conduct testing.

3. Screen or Video Recording

Screen or video recording kind of testing is in which a screen is recorded as per the user’s action
(navigation and usage of the product). This testing describes how the user’s mind runs while
using a product. This kind of testing involves the participation of almost 10 users for 15
minutes. It helps in describing the issues users may face while interacting with the product.
Generally, there are two studies in usability testing –
1. Moderated – Moderator guides the participant for the changes required in the product
(software)
2. Unmoderated – There’s no moderator (no human guidance),
participants gets a set of questions on which he/she has to work. While performing
usability testing, all kinds of biases (be it friendly bias, social bias, etc.) by the
participants are avoided to have honest feedback on the product so as to improve its
durability.
Need for Usability Testing
Usability testing provides some benefits and the main benefit and purpose of usability testing
are to identify usability problems with a design as early as possible, so they can be fixed before
the design is implemented or mass produced and then such, usability testing is often conducted
on prototypes rather than finished products, with different levels of fidelity depending on the
development phase.
Why Usability Testing?
When software is made-ready, it is important to make sure that the user experience with the
product should be seamless. It should be easy to navigate and all the functions would be
working properly, else the competitor’s website will win the race.
Therefore, usability testing is performed. The objective of usability testing is to understand
customers’ needs and requirements and also how users interact with the product (software).
With the test, all the features, functions, and purposes of the software are checked.
The primary goals of usability testing are – discovering problems (hidden issues) and
opportunities, comparing benchmarks, and comparison against other websites. The parameters
tested during usability testing are efficiency, effectiveness, and satisfaction. It should be
performed before any new design is made. This test should be iterated unless all the necessary
changes have been made. Improving the site consistently by performing usability testing
enhances its performance which in return makes it the best website.
Pros and Cons of Usability Testing
As every coin has two sides, usability testing has pros and cons. Some of the pros it has are:
• Gives excellent features and functionalities to the product
• Improves user satisfaction and fulfills requirements based on user’s feedback
• The product becomes more efficient and effective
The biggest cons of usability testing are the cost and time. The more usability testing is
performed, the more cost and time is being used.