This document provides an overview of software development life cycle (SDLC) models, including the waterfall model, V-shaped model, and prototype model. It describes the key phases of each model - requirement gathering, design, implementation, testing, deployment, and maintenance. The waterfall model is a linear sequential process where each phase must be completed before the next begins. The V-shaped model adds testing phases that run parallel to the development phases. The prototype model involves building prototypes to get early customer feedback before developing the actual software. Adhering to an SDLC process helps ensure a high-quality product is delivered systematically.

1. DEPARTMENT OF COMPUTER SCIENCE
SOFTWARE TESTING
E-CONTENT
Prepared By
K.SANDYA M.Sc., M.phil.,SET

2. UNIT-1
Software Development Life cycle Models
SDLC is a process that defines the various stages involved in the development of software for
delivering a high-quality product. SDLC stages cover the complete life cycle of a software
i.e. from inception to retirement of the product.
Adhering to the SDLC process leads to the development of the software in a systematic and
disciplined manner.
Purpose:
Purpose of SDLC is to deliver a high-quality product which is as per the customer’s
requirement.
SDLC has defined its phases as, Requirement gathering, Designing, Coding, Testing, and
Maintenance. It is important to adhere to the phases to provide the Product in a systematic
manner.
For Example, A software has to be developed and a team is divided to work on a feature of
the product and is allowed to work as they want. One of the developers decides to design first
whereas the other decides to code first and the other on the documentation part.
This will lead to project failure because of which it is necessary to have a good knowledge
and understanding among the team members to deliver an expected product.
SDLC Cycle
SDLC Cycle represents the process of developing software.
Below is the diagrammatic representation of the SDLC cycle:

3. SDLC Phases
Given below are the various phases:
• Requirement gathering and analysis
• Design
• Implementation or coding
• Testing
• Deployment
• Maintenance
#1) Requirement Gathering and Analysis
During this phase, all the relevant information is collected from the customer to develop a
product as per their expectation. Any ambiguities must be resolved in this phase only.
Business analyst and Project Manager set up a meeting with the customer to gather all the
information like what the customer wants to build, who will be the end-user, what is the
purpose of the product. Before building a product a core understanding or knowledge of the
product is very important.
For Example, A customer wants to have an application which involves money transactions.
In this case, the requirement has to be clear like what kind of transactions will be done, how it
will be done, in which currency it will be done, etc.
Once the requirement gathering is done, an analysis is done to check the feasibility of the
development of a product. In case of any ambiguity, a call is set up for further discussion.
Once the requirement is clearly understood, the SRS (Software Requirement Specification)
document is created. This document should be thoroughly understood by the developers and
also should be reviewed by the customer for future reference.
#2) Design
In this phase, the requirement gathered in the SRS document is used as an input and software
architecture that is used for implementing system development is derived.
#3) Implementation or Coding
Implementation/Coding starts once the developer gets the Design document. The Software
design is translated into source code. All the components of the software are implemented in
this phase.
#4) Testing
Testing starts once the coding is complete and the modules are released for testing. In this
phase, the developed software is tested thoroughly and any defects found are assigned to
developers to get them fixed.
Retesting, regression testing is done until the point at which the software is as per the
customer’s expectation. Testers refer SRS document to make sure that the software is as per
the customer’s standard.
#5) Deployment
Once the product is tested, it is deployed in the production environment or first UAT (User
Acceptance testing) is done depending on the customer expectation.

4. In the case of UAT, a replica of the production environment is created and the customer
along with the developers does the testing. If the customer finds the application as expected,
then sign off is provided by the customer to go live.
#6) Maintenance
After the deployment of a product on the production environment, maintenance of the
product i.e. if any issue comes up and needs to be fixed or any enhancement is to be done is
taken care by the developers.
Software Development Life Cycle Models
A software life cycle model is a descriptive representation of the software development cycle.
SDLC models might have a different approach but the basic phases and activity remain the
same for all the models.
#1) Waterfall Model
Waterfall model is the very first model that is used in SDLC. It is also known as the linear
sequential model.
In this model, the outcome of one phase is the input for the next phase. Development of the
next phase starts only when the previous phase is complete.
• First, Requirement gathering and analysis is done. Once the requirement is
freeze then only the System Design can start. Herein, the SRS document
created is the output for the Requirement phase and it acts as an input for the
System Design.
• In System Design Software architecture and Design, documents which act as
an input for the next phase are created i.e. Implementation and coding.
• In the Implementation phase, coding is done and the software developed is the
input for the next phase i.e. testing.
• In the testing phase, the developed code is tested thoroughly to detect the
defects in the software. Defects are logged into the defect tracking tool and are
retested once fixed. Bug logging, Retest, Regression testing goes on until the
time the software is in go-live state.
• In the Deployment phase, the developed code is moved into production after
the sign off is given by the customer.
• Any issues in the production environment are resolved by the developers
which come under maintenance.

5. Advantages of the Waterfall Model:
• Waterfall model is the simple model which can be easily understood and is the
one in which all the phases are done step by step.
• Deliverables of each phase are well defined, and this leads to no complexity
and makes the project easily manageable.
Disadvantages of Waterfall model:
• Waterfall model is time-consuming & cannot be used in the short duration
projects as in this model a new phase cannot be started until the ongoing phase
is completed.
• Waterfall model cannot be used for the projects which have uncertain
requirement or wherein the requirement keeps on changing as this model
expects the requirement to be clear in the requirement gathering and analysis
phase itself and any change in the later stages would lead to cost higher as the
changes would be required in all the phases.
#2) V-Shaped Model
V- Model is also known as Verification and Validation Model. In this model Verification &
Validation goes hand in hand i.e. development and testing goes parallel. V model and
waterfall model are the same except that the test planning and testing start at an early stage in
V-Model.
a) Verification Phase:
(i) Requirement Analysis:
In this phase, all the required information is gathered & analyzed. Verification activities
include reviewing the requirements.
(ii) System Design:
Once the requirement is clear, a system is designed i.e. architecture, components of the
product are created and documented in a design document.
(iii) High-Level Design:
High-level design defines the architecture/design of modules. It defines the functionality
between the two modules.
(iv) Low-Level Design:
Low-level Design defines the architecture/design of individual components.

6. (v) Coding:
Code development is done in this phase.
b) Validation Phase:
(i) Unit Testing:
Unit testing is performed using the unit test cases that are designed and is done in the Low-
level design phase. Unit testing is performed by the developer itself. It is performed on
individual components which lead to early defect detection.
(ii) Integration Testing:
Integration testing is performed using integration test cases in High-level Design phase.
Integration testing is the testing that is done on integrated modules. It is performed by testers.
(iii) System Testing:
System testing is performed in the System Design phase. In this phase, the complete system
is tested i.e. the entire system functionality is tested.
(iv) Acceptance Testing:
Acceptance testing is associated with the Requirement Analysis phase and is done in the
customer’s environment.
Advantages of V – Model:
• It is a simple and easily understandable model.
• V –model approach is good for smaller projects wherein the requirement is
defined and it freezes in the early stage.
• It is a systematic and disciplined model which results in a high-quality
product.
Disadvantages of V-Model:
• V-shaped model is not good for ongoing projects.
• Requirement change at the later stage would cost too high.
#3) Prototype Model
The prototype model is a model in which the prototype is developed prior to the actual
software.
Prototype models have limited functional capabilities and inefficient performance when
compared to the actual software. Dummy functions are used to create prototypes. This is a
valuable mechanism for understanding the customers’ needs.
Software prototypes are built prior to the actual software to get valuable feedback from the
customer. Feedbacks are implemented and the prototype is again reviewed by the customer
for any change. This process goes on until the model is accepted by the customer.

7. Once the requirement gathering is done, the quick design is created and the prototype which
is presented to the customer for evaluation is built.
Customer feedback and the refined requirement is used to modify the prototype and is again
presented to the customer for evaluation. Once the customer approves the prototype, it is used
as a requirement for building the actual software. The actual software is build using the
Waterfall model approach.
Advantages of Prototype Model:
• Prototype model reduces the cost and time of development as the defects are
found much earlier.
• Missing feature or functionality or a change in requirement can be identified in
the evaluation phase and can be implemented in the refined prototype.
• Involvement of a customer from the initial stage reduces any confusion in the
requirement or understanding of any functionality.
Disadvantages of Prototype Model:
• Since the customer is involved in every phase, the customer can change the
requirement of the end product which increases the complexity of the scope
and may increase the delivery time of the product.
#4) Spiral Model
The Spiral Model includes iterative and prototype approach.
Spiral model phases are followed in the iterations. The loops in the model represent the phase
of the SDLC process i.e. the innermost loop is of requirement gathering & analysis which
follows the Planning, Risk analysis, development, and evaluation. Next loop is Designing
followed by Implementation & then testing.
Spiral Model has four phases:
• Planning
• Risk Analysis
• Engineering
• Evaluation

8. (i) Planning:
The planning phase includes requirement gathering wherein all the required information is
gathered from the customer and is documented. Software requirement specification document
is created for the next phase.
(ii) Risk Analysis:
In this phase, the best solution is selected for the risks involved and analysis is done by
building the prototype.
For Example, the risk involved in accessing the data from a remote database can be that the
data access rate might be too slow. The risk can be resolved by building a prototype of the
data access subsystem.
(iii) Engineering:
Once the risk analysis is done, coding and testing are done.
(iv) Evaluation:
Customer evaluates the developed system and plans for the next iteration.
Advantages of Spiral Model:
• Risk Analysis is done extensively using the prototype models.
• Any enhancement or change in the functionality can be done in the next
iteration.
Disadvantages of Spiral Model:
• The spiral model is best suited for large projects only.
• The cost can be high as it might take a large number of iterations which can
lead to high time to reach the final product.
#5) Iterative Incremental Model
The iterative incremental model divides the product into small chunks.
For Example, Feature to be developed in the iteration is decided and implemented. Each
iteration goes through the phases namely Requirement Analysis, Designing, Coding, and
Testing. Detailed planning is not required in iterations.

9. Once the iteration is completed, a product is verified and is delivered to the customer for their
evaluation and feedback. Customer’s feedback is implemented in the next iteration along
with the newly added feature.
Hence, the product increments in terms of features and once the iterations are completed the
final build holds all the features of the product.
Phases of Iterative & Incremental Development Model:
• Inception phase
• Elaboration Phase
• Construction Phase
• Transition Phase
(i) Inception Phase:
Inception phase includes the requirement and scope of the Project.
(ii) Elaboration Phase:
In the elaboration phase, the working architecture of a product is delivered which covers the
risk identified in the inception phase and also fulfills the non-functional requirements.
(iii) Construction Phase:
In the Construction phase, the architecture is filled in with the code which is ready to be
deployed and is created through analysis, designing, implementation, and testing of the
functional requirement.
(iv) Transition Phase:
In the Transition Phase, the product is deployed in the Production environment.
Advantages of Iterative & Incremental Model:
• Any change in the requirement can be easily done and would not cost as there
is a scope of incorporating the new requirement in the next iteration.
• Risk is analyzed & identified in the iterations.
• Defects are detected at an early stage.
• As the product is divided into smaller chunks it is easy to manage the product.
Disadvantages of Iterative & Incremental Model:
• Complete requirement and understanding of a product are required to break
down and build incrementally.
#6) Big Bang Model
Big Bang Model does not have any defined process. Money and efforts are put together as the
input and output come as a developed product which might be or might not be the same as
what the customer needs.
Big Bang Model does not require much planning and scheduling. The developer does the
requirement analysis & coding and develops the product as per his understanding. This model
is used for small projects only. There is no testing team and no formal testing is done, and
this could be a cause for the failure of the project.
Advantages of Big Bang Model:
• It’s a very simple Model.
• Less Planning and scheduling is required.
• The developer has the flexibility to build the software of their own.
Disadvantages of the Big Bang Model:

10. • Big Bang models cannot be used for large, ongoing & complex projects.
• High risk and uncertainty.
#7) Agile Model
Agile Model is a combination of the Iterative and incremental model. This model focuses
more on flexibility while developing a product rather than on the requirement.
In Agile, a product is broken into small incremental builds. It is not developed as a complete
product in one go. Each build increments in terms of features. The next build is built on
previous functionality.
In agile iterations are termed as sprints. Each sprint lasts for2-4 weeks. At the end of each
sprint, the product owner verifies the product and after his approval, it is delivered to the
customer.
Customer feedback is taken for improvement and his suggestions and enhancement are
worked on in the next sprint. Testing is done in each sprint to minimize the risk of any
failures.
Advantages of Agile Model:
• It allows more flexibility to adapt to the changes.
• The new feature can be added easily.
• Customer satisfaction as the feedback and suggestions are taken at every stage.
Disadvantages:
• Lack of documentation.
• Agile needs experienced and highly skilled resources.
• If a customer is not clear about how exactly they want the product to be, then
the project would fail.

11. Phases of Software Project
There are seven primary stages of the modern system development life cycle. Here’s a brief
breakdown:
• Planning Stage
• Feasibility or Requirements of Analysis Stage
• Design and Prototyping Stage
• Software Development Stage
• Software Testing Stage
• Implementation and Integration
• Operations and Maintenance Stage
Now let’s take a closer look at each stage individually.
Planning Stage
Before we even begin with the planning stage, the best tip we can give you is to take time and
acquire proper understanding of app development life cycle.
The planning stage (also called the feasibility stage) is exactly what it sounds like: the phase
in which developers will plan for the upcoming project.
It helps to define the problem and scope of any existing systems, as well as determine the
objectives for their new systems.
By developing an effective outline for the upcoming development cycle, they'll theoretically
catch problems before they affect development.
And help to secure the funding and resources they need to make their plan happen.
Perhaps most importantly, the planning stage sets the project schedule, which can be of key
importance if development is for a commercial product that must be sent to market by a
certain time.

12. Analysis Stage
The analysis stage includes gathering all the specific details required for a new system as well
as determining the first ideas for prototypes.
Developers may:
• Define any prototype system requirements
• Evaluate alternatives to existing prototypes
• Perform research and analysis to determine the needs of end-users
Furthermore, developers will often create a software requirement specification or SRS
document.
This includes all the specifications for software, hardware, and network requirements for the
system they plan to build. This will prevent them from overdrawing funding or resources
when working at the same place as other development teams.
Design Stage
The design stage is a necessary precursor to the main developer stage.
Developers will first outline the details for the overall application, alongside specific aspects,
such as its:
• User interfaces
• System interfaces
• Network and network requirements
• Databases
They’ll typically turn the SRS document they created into a more logical structure that can
later be implemented in a programming language. Operation, training, and maintenance plans
will all be drawn up so that developers know what they need to do throughout every stage of
the cycle moving forward.
Once complete, development managers will prepare a design document to be referenced
throughout the next phases of the SDLC.

13. Development Stage
The development stage is the part where developers actually write code and build the
application according to the earlier design documents and outlined specifications.
This is where Static Application Security Testing or SAST tools come into play.
Product program code is built per the design document specifications. In theory, all of the
prior planning and outlined should make the actual development phase relatively
straightforward.
Developers will follow any coding guidelines as defined by the organization and utilize
different tools such as compilers, debuggers, and interpreters.
Programming languages can include staples such as C++, PHP, and more. Developers will
choose the right programming code to use based on the project specifications and
requirements.
Testing Stage
Building software is not the end.
Now it must be tested to make sure that there aren’t any bugs and that the end-user
experience will not negatively be affected at any point.
During the testing stage, developers will go over their software with a fine-tooth comb,
noting any bugs or defects that need to be tracked, fixed, and later retested.
t’s important that the software overall ends up meeting the quality standards that were
previously defined in the SRS document.
Depending on the skill of the developers, the complexity of the software, and the
requirements for the end-user, testing can either be an extremely short phase or take a very
long time. Take a look at our top 10 best practices for software testing projects for more
information.

14. Implementation and Integration Stage
After testing, the overall design for the software will come together. Different modules or
designs will be integrated into the primary source code through developer efforts, usually by
leveraging training environments to detect further errors or defects.
The information system will be integrated into its environment and eventually installed. After
passing this stage, the software is theoretically ready for market and may be provided to any
end-users.
Maintenance Stage
The SDLC doesn’t end when software reaches the market. Developers must now move into a
maintenance mode and begin practicing any activities required to handle issues reported by
end-users.
Furthermore, developers are responsible for implementing any changes that the software
might need after deployment.
This can include handling residual bugs that were not able to be patched before launch or
resolving new issues that crop up due to user reports. Larger systems may require longer
maintenance stages compared to smaller systems.
Quality
Quality is meeting the requirement, expectation, and needs of the customer is free from
the defects, lacks and substantial variants. There are standards needs to follow to satisfy the
customer requirements.
Assurance
Assurance is provided by organization management, it means giving a positive declaration on
a product which obtains confidence for the outcome. It gives a security that the product will
work without any glitches as per the expectations or requests.

15. Quality Assurance
Quality Assurance is known as QA and focuses on preventing defect. Quality Assurance
ensures that the approaches, techniques, methods and processes are designed for the projects
are implemented correctly.
Quality assurance activities monitor and verify that the processes used to manage and create
the deliverables have been followed and are operative.
Quality Assurance is a proactive process and is Prevention in nature. It recognizes flaws in
the process. Quality Assurance has to complete before Quality Control
Control is to test or verify actual results by comparing it with the defined standards.
Quality Control
Quality Control is known as QC and focuses on identifying a defect. QC ensures that the
approaches, techniques, methods and processes are designed in the project are following
correctly. QC activities monitor and verify that the project deliverables meet the defined
quality standards.
Quality Control is a reactive process and is detection in nature. It recognizes the defects.
Quality Control has to complete after Quality Assurance.
Difference in QA/QC?
Many people think QA and QC are the same and interchangeable but this is not true. Both are
tightly linked and sometimes it is very difficult to identify the differences. Fact is both are
related to each other but they are different in origins.
QA and QC both are part of Quality Management however QA is focusing on preventing
defect while QC is focusing on identifying the defect.
QA vs QC
Here is the exact difference between Quality Control and Quality Assurance that one
needs to know:
Quality Assurance Quality Control
It is a process which deliberates on providing
assurance that quality request will be achieved.
QC is a process which deliberates on
fulfilling the quality request.
A QA aim is to prevent the defect. A QC aim is to identify and improve the
defects.
QA is the technique of managing quality. QC is a method to verify quality.

16. Quality Assurance Quality Control
QA does not involve executing the program. QC always involves executing the program.
All team members are responsible for QA. Testing team is responsible for QC.
QA Example: Verification QC Example: Validation.
QA means Planning for doing a process. QC Means Action for executing the planned
process.
Statistical Technique used on QA is known as
Statistical Process Control (SPC.)
Statistical Technique used on QC is known as
Statistical Quality Control (SPC.)
QA makes sure you are doing the right things. QC makes sure the results of what you've
done are what you expected.
QA Defines standards and methodologies to followed
in order to meet the customer requirements.
QC ensures that the standards are followed
while working on the product.
QA is the process to create the deliverables. QC is the process to verify that deliverables.
QA is responsible for full software development life
cycle.
QC is responsible for software testing life
cycle.
In my opinion, QC is required after QA is done.
While doing ‘QA’, we define the processes, policies & strategies, establish standards,
develop checklists etc. that needs to be used and followed throughout the life cycle of a
project.
And while doing QC we follow all those defined processes, standards and policies that we
laid down in QA to make sure that the project is maintaining high quality and the final
outcome of the project at least meets the customer’s expectations.
Verification and Validation
Verification testing
Verification testing includes different activities such as business requirements, system
requirements, design review, and code walkthrough while developing a product.
It is also known as static testing, where we are ensuring that "we are developing the right
product or not". And it also checks that the developed application fulfilling all the
requirements given by the client.

17. Validation testing
Validation testing is testing where tester performed functional and non-functional testing.
Here functional testing includes Unit Testing
(UT), Integration Testing
(IT) and System Testing (ST), and non-functional testing includes User acceptance testing
(UAT).
Validation testing is also known as dynamic testing, where we are ensuring that "we have
developed the product right." And it also checks that the software meets the business needs
of the client.

18. Note: Verification and Validation process are done under the V model of the software
development life cycle.
Difference between verification and validation testing
Verification Validation
We check whether we are developing the right
product or not.
We check whether the developed product is right.
Verification is also known as static testing. Validation is also known as dynamic testing.
Verification includes different methods like
Inspections, Reviews, and Walkthroughs.
Validation includes testing like functional testing
, system testing, integration
, and User acceptance testing.
It is a process of checking the work-products (not
the final product) of a development cycle to
decide whether the product meets the specified
requirements.
It is a process of checking the software during or at
the end of the development cycle to decide whether
the software follow the specified business
requirements.
Quality assurance comes under verification
testing.
Quality control comes under validation testing.
The execution of code does not happen in the
verification testing.
In validation testing, the execution of code
happens.

19. In verification testing, we can find the bugs early
in the development phase of the product.
In the validation testing, we can find those bugs,
which are not caught in the verification process.
Verification testing is executed by the Quality
assurance team to make sure that the product is
developed according to customers' requirements.
Validation testing is executed by the testing team
to test the application.
Verification is done before the validation testing. After verification testing, validation testing takes
place.
In this type of testing, we can verify that the
inputs follow the outputs or not.
In this type of testing, we can validate that the user
accepts the product or not.
UNIT-2

20. White Box Testing
The box testing approach of software testing consists of black box testing and white box testing.
We are discussing here white box testing which also known as glass box is testing, structural
testing, clear box testing, open box testing and transparent box testing. It tests internal
coding and infrastructure of a software focus on checking of predefined inputs against expected
and desired outputs. It is based on inner workings of an application and revolves around internal
structure testing. In this type of testing programming skills are required to design test cases.
The primary goal of white box testing is to focus on the flow of inputs and outputs through the
software and strengthening the security of the software.
The term 'white box' is used because of the internal perspective of the system. The clear box or
white box or transparent box name denote the ability to see through the software's outer shell
into its inner workings.
Developers do white box testing. In this, the developer will test every line of the code of the
program. The developers perform the White-box testing and then send the application or the
software to the testing team, where they will perform the black box testing
and verify the application along with the requirements and identify the bugs and sends it to
the developer.
The developer fixes the bugs and does one round of white box testing and sends it to the testing
team. Here, fixing the bugs implies that the bug is deleted, and the particular feature is working
fine on the application.20
C++ vs Java
Here, the test engineers will not include in fixing the defects for the following reasons:
o Fixing the bug might interrupt the other features. Therefore, the test engineer should
always find the bugs, and developers should still be doing the bug fixes.
o If the test engineers spend most of the time fixing the defects, then they may be unable
to find the other bugs in the application.
The white box testing contains various tests, which are as follows:
o Path testing
o Loop testing
o Condition testing
o Testing based on the memory perspective
o Test performance of the program
Path testing

21. In the path testing, we will write the flow graphs and test all independent paths. Here writing
the flow graph implies that flow graphs are representing the flow of the program and also show
how every program is added with one another as we can see in the below image:
And test all the independent paths implies that suppose a path from main() to function G, first
set the parameters and test if the program is correct in that particular path, and in the same way
test all other paths and fix the bugs.
Loop testing
In the loop testing, we will test the loops such as while, for, and do-while, etc. and also check
for ending condition if working correctly and if the size of the conditions is enough.
For example: we have one program where the developers have given about 50,000 loops.
1. {
2. while(50,000)
3. ……
4. ……
5. }
We cannot test this program manually for all the 50,000 loops cycle. So we write a small
program that helps for all 50,000 cycles, as we can see in the below program, that test P is
written in the similar language as the source code program, and this is known as a Unit test.
And it is written by the developers only.
1. Test P
2. {

22. 3. ……
4. …… }
As we can see in the below image that, we have various requirements such as 1, 2, 3, 4. And
then, the developer writes the programs such as program 1,2,3,4 for the parallel conditions.
Here the application contains the 100s line of codes.
The developer will do the white box testing, and they will test all the five programs line by line
of code to find the bug. If they found any bug in any of the programs, they will correct it. And
they again have to test the system then this process contains lots of time and effort and slows
down the product release time.
Now, suppose we have another case, where the clients want to modify the requirements, then
the developer will do the required changes and test all four program again, which take lots of
time and efforts.
These issues can be resolved in the following ways:
In this, we will write test for a similar program where the developer writes these test code in
the related language as the source code. Then they execute these test code, which is also known
as unit test programs. These test programs linked to the main program and implemented as
programs.

23. Therefore, if there is any requirement of modification or bug in the code, then the developer
makes the adjustment both in the main program and the test program and then executes the test
program.
Condition testing
In this, we will test all logical conditions for both true and false values; that is, we will verify
for both if and else condition.
For example:
1. if(condition) - true
2. {
3. …..
4. ……
5. ……
6. }
7. else - false
8. {
9. …..
10. ……
11. ……
12. }
The above program will work fine for both the conditions, which means that if the condition is
accurate, and then else should be false and conversely.
Testing based on the memory (size) perspective
The size of the code is increasing for the following reasons:
o The reuse of code is not there: let us take one example, where we have four programs
of the same application, and the first ten lines of the program are similar. We can write
these ten lines as a discrete function, and it should be accessible by the above four
programs as well. And also, if any bug is there, we can modify the line of code in the
function rather than the entire code.
o The developers use the logic that might be modified. If one programmer writes code
and the file size is up to 250kb, then another programmer could write a similar code
using the different logic, and the file size is up to 100kb.
o The developer declares so many functions and variables that might never be used in
any portion of the code. Therefore, the size of the program will increase.
For example,

24. 1. Int a=15;
2. Int b=20;
3. String S= "Welcome";
4. ….
5. …..
6. …..
7. ….
8. …..
9. Int p=b;
10. Create user()
11. {
12. ……
13. ……
14. ….. 200's line of code
15. }
In the above code, we can see that the integer a has never been called anywhere in the program,
and also the function Create user has never been called anywhere in the code. Therefore, it
leads us to memory consumption.
We cannot remember this type of mistake manually by verifying the code because of the large
code. So, we have a built-in tool, which helps us to test the needless variables and functions.
And, here we have the tool called Rational purify.
Suppose we have three programs such as Program P, Q, and R, which provides the input to S.
And S goes into the programs and verifies the unused variables and then gives the outcome.

25. After that, the developers will click on several results and call or remove the unnecessary
function and the variables.
This tool is only used for the C programming language
and C++ programming language
; for another language, we have other related tools available in the market.
o The developer does not use the available in-built functions; instead they write the full
features using their logic. Therefore, it leads us to waste of time and also postpone the
product releases.
Test the performance (Speed, response time) of the program
The application could be slow for the following reasons:
o When logic is used.
o For the conditional cases, we will use or & and adequately.
o Switch case, which means we cannot use nested if, instead of using a switch case.
As we know that the developer is performing white box testing, they understand that the code
is running slow, or the performance of the program is also getting deliberate. And the developer
cannot go manually over the program and verify which line of the code is slowing the program.
To recover with this condition, we have a tool called Rational Quantify, which resolves these
kinds of issues automatically. Once the entire code is ready, the rational quantify tool will go
through the code and execute it. And we can see the outcome in the result sheet in the form of
thick and thin lines.
Here, the thick line specifies which section of code is time-consuming. When we double-click
on the thick line, the tool will take us to that line or piece of code automatically, which is also
displayed in a different color. We can change that code and again and use this tool. When the

26. order of lines is all thin, we know that the presentation of the program has enhanced. And the
developers will perform the white box testing automatically because it saves time rather than
performing manually.
Test cases for white box testing are derived from the design phase of the software development
lifecycle. Data flow testing, control flow testing, path testing, branch testing, statement and
decision coverage all these techniques used by white box testing as a guideline to create an
error-free software.
White box testing follows some working steps to make testing manageable and easy to
understand what the next task to do. There are some basic steps to perform white box testing.
Generic steps of white box testing
o Design all test scenarios, test cases and prioritize them according to high priority
number.
o This step involves the study of code at runtime to examine the resource utilization, not
accessed areas of the code, time taken by various methods and operations and so on.
o In this step testing of internal subroutines takes place. Internal subroutines such as
nonpublic methods, interfaces are able to handle all types of data appropriately or not.
o This step focuses on testing of control statements like loops and conditional statements
to check the efficiency and accuracy for different data inputs.
o In the last step white box testing includes security testing to check all possible security
loopholes by looking at how the code handles security.
Reasons for white box testing
o It identifies internal security holes.
o To check the way of input inside the code.
o Check the functionality of conditional loops.
o To test function, object, and statement at an individual level.
Advantages of White box testing
o White box testing optimizes code so hidden errors can be identified.
o Test cases of white box testing can be easily automated.
o This testing is more thorough than other testing approaches as it covers all code paths.
o It can be started in the SDLC phase even without GUI.
Disadvantages of White box testing

27. o White box testing is too much time consuming when it comes to large-scale
programming applications.
o White box testing is much expensive and complex.
o It can lead to production error because it is not detailed by the developers.
o White box testing needs professional programmers who have a detailed knowledge and
understanding of programming language and implementation.
Techniques Used in White Box Testing
Data Flow
Testing
Data flow testing is a group of testing strategies that examines the control flow of
programs in order to explore the sequence of variables according to the sequence of
events.
Control
Flow
Testing
Control flow testing determines the execution order of statements or instructions of the
program through a control structure. The control structure of a program is used to
develop a test case for the program. In this technique, a particular part of a large program
is selected by the tester to set the testing path. Test cases represented by the control graph
of the program.
Branch
Testing
Branch coverage technique is used to cover all branches of the control flow graph. It
covers all the possible outcomes (true and false) of each condition of decision point at
least once.
Statement
Testing
Statement coverage technique is used to design white box test cases. This technique
involves execution of all statements of the source code at least once. It is used to calculate
the total number of executed statements in the source code, out of total statements present
in the source code.
Decision
Testing
This technique reports true and false outcomes of Boolean expressions. Whenever there
is a possibility of two or more outcomes from the statements like do while statement, if
statement and case statement (Control flow statements), it is considered as decision point
because there are two outcomes either true or false.
Difference between white-box testing and black-box testing
Following are the significant differences between white box testing and black box testing:
White-box testing Black box testing
The developers can perform white box testing. The test engineers perform the black box testing.

28. To perform WBT, we should have an
understanding of the programming languages.
To perform BBT, there is no need to have an
understanding of the programming languages.
In this, we will look into the source code and
test the logic of the code.
In this, we will verify the functionality of the
application based on the requirement specification.
In this, the developer should know about the
internal design of the code.
In this, there is no need to know about the internal
design of the code.
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

29. 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.
Structural testing
Structural testing is a type of software testing which uses the internal design
of the software for testing or in other words the software testing which is performed by the
team which knows the development phase of the software, is known as structural testing.
Structural testing is basically related to the internal design and implementation of the
software i.e. it involves the development team members in the testing team. It basically
tests different aspects of the software according to its types. Structural testing is just the
opposite of behavioral testing.
Types of Structural Testing:
There are 4 types of Structural Testing:

30. Control Flow Testing:
Control flow testing is a type of structural testing that uses the programs’s control flow as a
model. The entire code, design and structure of the software have to be known for this type
of testing. Often this type of testing is used by the developers to test their own code and
implementation. This method is used to test the logic of the code so that required result can
be obtained.
Data Flow Testing:
It uses the control flow graph to explore the unreasonable things that can happen to data.
The detection of data flow anomalies are based on the associations between values and
variables. Without being initialized usage of variables. Initialized variables are not used
once.
Slice Based Testing:
It was originally proposed by Weiser and Gallagher for the software maintenance. It is
useful for software debugging, software maintenance, program understanding and
quantification of functional cohesion. It divides the program into different slices and tests
that slice which can majorly affect the entire software.
Mutation Testing:
Mutation Testing is a type of Software Testing that is performed to design new software
tests and also evaluate the quality of already existing software tests. Mutation testing is
related to modification a program in small ways. It focuses to help the tester develop
effective tests or locate weaknesses in the test data used for the program.
Advantages of Structural Testing:
• It provides thorough testing of the software.
• It helps in finding out defects at an early stage.
• It helps in elimination of dead code.
• It is not time consuming as it is mostly automated.
Disadvantages of Structural Testing:
• It requires knowledge of the code to perform test.
• It requires training in the tool used for testing.
• Sometimes it is expensive.

31. Black Box Testing
Black Box Testing is also known as behavioral, opaque-box, closed-box, specification-based
or eye-to-eye testing.
It is a Software Testing method that analyzes the functionality of a software/application
without knowing much about the internal structure/design of the item that is being tested and
compares the input value with the output value.
The main focus of Black Box Testing is on the functionality of the system as a
whole. The term ‘Behavioral Testing’ is also used for Black Box Testing.
Behavioral test design is slightly different from the black-box test design because the use of
internal knowledge isn’t strictly forbidden, but it’s still discouraged. Each testing method has
its own advantages and disadvantages. There are some bugs that cannot be found using black
box or white box technique alone.
A majority of the applications are tested using the Black Box method. We need to cover the
majority of test cases so that most of the bugs will get discovered by the Black-Box method.
This testing occurs throughout the Software Development and Testing Life Cycle i.e in Unit,
Integration, System, Acceptance, and Regression Testing stages.
This can be either Functional or Non-Functional.
Types of Black Box Testing
Practically, there are several types of Black Box Testing that are possible, but if we consider
a major variant of it then only the below mentioned are the two fundamental ones.
#1) Functional Testing
This testing type deals with the functional requirements or specifications of an application.
Here, different actions or functions of the system are being tested by providing the input and
comparing the actual output with the expected output.
For example, when we test a Dropdown list, we click on it and verify if it expands and all
the expected values are showing in the list.
Few major types of Functional Testing are:
• Smoke Testing
• Sanity Testing
• Integration Testing
• System Testing
• Regression Testing
• User Acceptance Testing
#2) Non-Functional Testing
Apart from the functionalities of the requirements, there are even several non-functional
aspects that are required to be tested to improve the quality and performance of the
application.
Few major types of Non-Functional Testing include:
• Usability Testing
• Load Testing

32. • Performance Testing
• Compatibility Testing
• Stress Testing
• Scalability Testing
Black Box Testing tools are mainly record and playback tools. These tools are used for
Regression Testing to check whether a new build has created any bugs in the previous
working application functionality.
These record and playback tools record test cases in the form of scripts like TSL, VB script,
Javascript, Perl, etc.
Black Box Testing Techniques
In order to systematically test a set of functions, it is necessary to design test cases. Testers
can create test cases from the requirement specification document using the following Black
Box Testing techniques:
• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing
• Error Guessing
• Graph-Based Testing Methods
• Comparison Testing
Let’s understand each technique in detail.
#1) Equivalence Partitioning
This technique is also known as Equivalence Class Partitioning (ECP). In this technique,
input values to the system or application are divided into different classes or groups based on
its similarity in the outcome.
Hence, instead of using each and every input value, we can now use any one value from the
group/class to test the outcome. This way, we can maintain test coverage while we can reduce
the amount of rework and most importantly the time spent.
For Example:
As present in the above image, the “AGE” text field accepts only numbers from 18 to 60.
There will be three sets of classes or groups.
Two invalid classes will be:
a) Less than or equal to 17.

33. b) Greater than or equal to 61.
A valid class will be anything between 18 and 60.
We have thus reduced the test cases to only 3 test cases based on the formed classes thereby
covering all the possibilities. So, testing with any one value from each set of the class is
sufficient to test the above scenario.
#2) Boundary Value Analysis
The name itself defines that in this technique, we focus on the values at boundaries as it is
found that many applications have a high amount of issues on the boundaries.
Boundary refers to values near the limit where the behavior of the system changes. In
boundary value analysis, both valid and invalid inputs are being tested to verify the issues.
For Example:
If we want to test a field where values from 1 to 100 should be accepted, then we choose the
boundary values: 1-1, 1, 1+1, 100-1, 100, and 100+1. Instead of using all the values from 1 to
100, we just use 0, 1, 2, 99, 100, and 101.
#3) Decision Table Testing
As the name itself suggests, wherever there are logical relationships like:
If
{
(Condition = True)
then action1 ;
}
else action2; /*(condition = False)*/
Then a tester will identify two outputs (action1 and action2) for two conditions (True and
False). So based on the probable scenarios a Decision table is carved to prepare a set of test
cases.
For Example:
Take an example of XYZ bank that provides an interest rate for the Male senior citizen as
10% and 9% for the rest of the people.

34. In this example condition, C1 has two values as true and false, C2 also has two values as true
and false. The total number of possible combinations would then be four. This way we can
derive test cases using a decision table.
#4) State Transition Testing
State Transition Testing is a technique that is used to test the different states of the system
under test. The state of the system changes depending upon the conditions or events. The
events trigger states which become scenarios and a tester needs to test them.
A systematic state transition diagram gives a clear view of the state changes but it is effective
for simpler applications. More complex projects may lead to more complex transition
diagrams thereby making it less effective.
For Example:
#5) Error Guessing
This is a classic example of Experience-Based Testing.
In this technique, the tester can use his/her experience about the application behavior and
functionalities to guess the error-prone areas. Many defects can be found using error guessing
where most of the developers usually make mistakes.

35. Few common mistakes that developers usually forget to handle:
• Divide by zero.
• Handling null values in text fields.
• Accepting the Submit button without any value.
• File upload without attachment.
• File upload with less than or more than the limit size.
#6) Graph-Based Testing Methods
Each and every application is a build-up of some objects. All such objects are identified and
the graph is prepared. From this object graph, each object relationship is identified and test
cases are written accordingly to discover the errors.
#7) Comparison Testing
In this method, different independent versions of the same software are used to compare to
each other for testing.
How do I do Step-wise?
In general, when a systematic process is followed to test a project/application then quality is
maintained and is useful in the long run for further rounds of testing.
• The foremost step is to understand the requirement specification of an
application. Properly documented SRS (Software Requirement Specification)
should be in place.
• Using the above mentioned Black Box Testing techniques such as Boundary
Value Analysis, Equivalence partitioning etc, sets of valid and invalid inputs
are identified with their desired outputs and test cases are designed based on
that.
• The designed test cases are executed to check if they Pass or Fail by verifying
the actual results with the expected results.
• Failed test cases are raised as Defects/Bugs and addressed to the development
team to get it Fixed.
• Further, based on the defects being fixed, the tester retests the defects to verify
if they are recurring or not.
Advantages and Disadvantages
Advantages
• The tester does not need to have a technical background. It is important to test
by being in the user’s shoes and think from the user’s point of view.
• Testing can start once the development of the project/application is done. Both
the testers and developers work independently without interfering in each
other’s space.
• It is more effective for large and complex applications.
• Defects and inconsistencies can be identified in the early stages of testing.
Disadvantages
• Without any technical or programming knowledge, there are chances of
ignoring possible conditions of the scenario to be tested.
• In a stipulated time there is a possibility of testing less and skipping all
possible inputs and their output testing.
• Complete Test Coverage is not possible for large and complex projects.