So ware tes ng tutorial provides basic and advanced concepts of so ware tes ng.

Our
so ware tes ng tutorial is designed for beginners and professionals.
So ware tes ng is widely used technology because it is compulsory to test each and
every so ware before deployment.
Our So ware tes ng tutorial includes all topics of So ware tes ng such as Methods
such as Black Box Tes ng, White Box Tes ng, Visual Box Tes ng and Gray Box Tes ng.
Levels such as Unit Tes ng, Integra on Tes ng, Regression Tes ng, Func onal Tes ng.
System Tes ng, Acceptance Tes ng, Alpha Tes ng, Beta Tes ng, Non-Func onal tes ng,
Security Tes ng, Portability Tes ng.
What is So ware Tes ng
So ware tes ng is a process of iden fying the correctness of so ware by considering
its all a ributes (Reliability, Scalability, Portability, Re-usability, Usability) and
evalua ng the execu on of so ware components to find the so ware bugs or errors
or defects.
So ware tes ng provides an independent view and objec ve of the so ware and gives
surety of fitness of the so ware. It involves tes ng of all components under the
required services to confirm that whether it is sa sfying the specified requirements or
not. The process is also providing the client with informa on about the quality of the
so ware.
Tes ng is mandatory because it will be a dangerous situa on if the so ware fails any of
me due to lack of tes ng. So, without tes ng so ware cannot be deployed to the end
user.
What is Tes ng
Tes ng is a group of techniques to determine the correctness of the applica on under
the predefined script but, tes ng cannot find all the defect of applica on. The main
intent of tes ng is to detect failures of the applica on so that failures can be discovered
and corrected. It does not demonstrate that a product func ons properly under all
condi ons but only that it is not working in some specific condi ons.
Tes ng furnishes comparison that compares the behavior and state of so ware against
mechanisms because the problem can be recognized by the mechanism. The
mechanism may include past versions of the same specified product, comparable
products, and interfaces of expected purpose, relevant standards, or other criteria but
not limited up to these.
Tes ng includes an examina on of code and also the execu on of code in various
environments, condi ons as well as all the examining aspects of the code. In the current
scenario of so ware development, a tes ng team may be separate from the
development team so that Informa on derived from tes ng can be used to correct the
process of so ware development.
The success of so ware depends upon acceptance of its targeted audience, easy
graphical user interface, strong func onality load test, etc. For example, the audience
of banking is totally different from the audience of a video game. Therefore, when an
organiza on develops a so ware product, it can assess whether the so ware product
will be beneficial to its purchasers and other audience.
Type of So ware tes ng
We have various types of tes ng available in the market, which are used to test the
applica on or the so ware.
With the help of below image, we can easily understand the type of so ware tes ng:
Manual tes ng
The process of checking the func onality of an applica on as per the customer needs
without taking any help of automa on tools is known as manual tes ng. While
performing the manual tes ng on any applica on, we do not need any specific
knowledge of any tes ng tool, rather than have a proper understanding of the product
so we can easily prepare the test document.
Manual tes ng can be further divided into three types of tes ng, which are as follows:
o White box tes ng
o Black box tes ng
o Gray box tes ng

So ware Tes ng Principles

So ware tes ng is a procedure of implemen ng so ware or the applica on to iden fy
the defects or bugs. For tes ng an applica on or so ware, we need to follow some
principles to make our product defects free, and that also helps the test engineers to
test the so ware with their effort and me. Here, in this sec on, we are going to learn
about the seven essen al principles of so ware tes ng.
Let us see the seven different tes ng principles, one by one:
o Tes ng shows the presence of defects
o Exhaus ve Tes ng is not possible
o Early Tes ng
o Defect Clustering
o Pes cide Paradox
o Tes ng is context-dependent
o Absence of errors fallacy
Tes ng shows the presence of defects
The test engineer will test the applica on to make sure that the applica on is bug or
defects free. While doing tes ng, we can only iden fy that the applica on or so ware
has any errors. The primary purpose of doing tes ng is to iden fy the numbers of
unknown bugs with the help of various methods and tes ng techniques because the
en re test should be traceable to the customer requirement, which means that to find
any defects that might cause the product failure to meet the client's needs.
By doing tes ng on any applica on, we can decrease the number of bugs, which does
not mean that the applica on is defect-free because some mes the so ware seems to
be bug-free while performing mul ple types of tes ng on it. But at the me of
deployment in the produc on server, if the end-user encounters those bugs which are
not found in the tes ng process.
Exhaus ve Tes ng is not possible
Some mes it seems to be very hard to test all the modules and their features with
effec ve and non- effec ve combina ons of the inputs data throughout the actual
tes ng process.
Hence, instead of performing the exhaus ve tes ng as it takes boundless
determina ons and most of the hard work is unsuccessful. So we can complete this
type of varia ons according to the importance of the modules because the product
melines will not permit us to perform such type of tes ng scenarios.
Early Tes ng
Here early tes ng means that all the tes ng ac vi es should start in the early stages of
the so ware development life cycle's requirement analysis stage to iden fy the
defects because if we find the bugs at an early stage, it will be fixed in the ini al stage
itself, which may cost us very less as compared to those which are iden fied in the
future phase of the tes ng process.
To perform tes ng, we will require the requirement specifica on documents; therefore,
if the requirements are defined incorrectly, then it can be fixed directly rather than
fixing them in another stage, which could be the development phase.
Defect clustering
The defect clustering defined that throughout the tes ng process, we can detect the
numbers of bugs which are correlated to a small number of modules. We have various
reasons for this, such as the modules could be complicated; the coding part may be
complex, and so on.
These types of so ware or the applica on will follow the Pareto Principle, which states
that we can iden fy that approx. Eighty percent of the complica on is present in 20
percent of the modules. With the help of this, we can find the uncertain modules, but
this method has its difficul es if the same tests are performing regularly, hence the
same test will not able to iden fy the new defects.
Pes cide paradox
This principle defined that if we are execu ng the same set of test cases again and again
over a par cular me, then these kinds of the test will not be able to find the new bugs
in the so ware or the applica on. To get over these pes cide paradoxes, it is very
significant to review all the test cases frequently. And the new and different tests are
necessary to be wri en for the implementa on of mul ple parts of the applica on or
the so ware, which helps us to find more bugs.
Tes ng is context-dependent
Tes ng is a context-dependent principle states that we have mul ple fields such as e-
commerce websites, commercial websites, and so on are available in the market. There
is a definite way to test the commercial site as well as the e-commerce websites
because every applica on has its own needs, features, and func onality. To check this
type of applica on, we will take the help of various kinds of tes ng, different technique,
approaches, and mul ple methods. Therefore, the tes ng depends on the context of
the applica on.
Absence of errors fallacy
Once the applica on is completely tested and there are no bugs iden fied before the
release, so we can say that the applica on is 99 percent bug-free. But there is the
chance when the applica on is tested beside the incorrect requirements, iden fied the
flaws, and fixed them on a given period would not help as tes ng is done on the wrong
specifica on, which does not apply to the client's requirements. The absence of error
fallacy means iden fying and fixing the bugs would not help if the applica on is
imprac cal and not able to accomplish the client's requirements and needs.

So ware Development Life Cycle (SDLC)

SDLC is a process that creates a structure of development of so ware. There are
different phases within SDLC, and each phase has its various ac vi es. It makes the
development team able to design, create, and deliver a high-quality product.
SDLC describes various phases of so ware development and the order of execu on of
phases. Each phase requires deliverable from the previous phase in a life cycle of
so ware development. Requirements are translated into design, design into
development and development into tes ng; a er tes ng, it is given to the client.
Let's see all the phases in detail:
Different phases of the so ware development cycle

o Requirement Phase
o Design Phase
o Build /Development Phase
o Tes ng Phase
o Deployment/ Deliver Phase
o Maintenance
1. Requirement Phase
This is the most crucial phase of the so ware development life cycle for the developing
team as well as for the project manager. During this phase, the client states
requirements, specifica ons, expecta ons, and any other special requirement related
to the product or so ware. All these are gathered by the business manager or project
manager or analyst of the service providing company.
The requirement includes how the product will be used and who will use the product
to determine the load of opera ons. All informa on gathered from this phase is cri cal
to developing the product as per the customer requirements.
2. Design Phase
The design phase includes a detailed analysis of new so ware according to the
requirement phase. This is the high priority phase in the development life cycle of a
system because the logical designing of the system is converted into physical designing.
The output of the requirement phase is a collec on of things that are required, and the
design phase gives the way to accomplish these requirements. The decision of all
required essen al tools such as programming language like Java, .NET, PHP,
a database like Oracle, MySQL, a combina on of hardware and so ware to provide a
pla orm on which so ware can run without any problem is taken in this phase.
There are several techniques and tools, such as data flow diagrams, flowcharts, decision
tables, and decision trees, Data dic onary, and the structured dic onary are used for
describing the system design.
3. Build /Development Phase
A er the successful comple on of the requirement and design phase, the next step is
to implement the design into the development of a so ware system. In this phase, work
is divided into small units, and coding starts by the team of developers according to the
design discussed in the previous phase and according to the requirements of the client
discussed in requirement phase to produce the desired result.
Front-end developers develop easy and a rac ve GUI and necessary interfaces to
interact with back-end opera ons and back-end developers do back-end coding
according to the required opera ons. All is done according to the procedure and
guidelines demonstrated by the project manager.
Since this is the coding phase, it takes the longest me and more focused approach for
the developer in the so ware development life cycle.
4. Tes ng Phase
Tes ng is the last step of comple ng a so ware system. In this phase, a er ge ng the
developed GUI and back-end combina on, it is tested against the requirements stated
in the requirement phase. Tes ng determines whether the so ware is actually giving
the result as per the requirements addressed in the requirement phase or not. The
Development team makes a test plan to start the test. This test plan includes all types
of essen al tes ng such as integra on tes ng, unit tes ng, acceptance tes ng, and
system tes ng. Non-func onal tes ng is also done in this phase.
If there are any defects in the so ware or it is not working as per expecta ons, then
the tes ng team gives informa on to the development team in detail about the issue.
If it is a valid defect or worth to sort out, it will be fixed, and the development team
replaces it with the new one, and it also needs to be verified.
5. Deployment/ Deliver Phase
When so ware tes ng is completed with a sa sfying result, and there are no remaining
issues in the working of the so ware, it is delivered to the customer for their use.
As soon as customers receive the product, they are recommended first to do the beta
tes ng. In beta tes ng, customer can require any changes which are not present in the
so ware but men oned in the requirement document or any other GUI changes to
make it more user-friendly. Besides this, if any type of defect is encountered while a
customer using the so ware; it will be informed to the development team of that
par cular so ware to sort out the problem. If it is a severe issue, then the development
team solves it in a short me; otherwise, if it is less severe, then it will wait for the next
version.
A er the solu on of all types of bugs and changes, the so ware finally deployed to the
end-user.
6. Maintenance
The maintenance phase is the last and long-las ng phase of SDLC because it is the
process which con nues un l the so ware's life cycle comes to an end. When a
customer starts using so ware, then actual problems start to occur, and at that me
there's a need to solve these problems. This phase also includes making changes in
hardware and so ware to maintain its opera onal effec veness like to improve its
performance, enhance security features and according to customer's requirements
with upcoming me. This process to take care of product me to me is called
maintenance.
"So, all these are six phases of so ware development life cycle (SDLC) under which the
process of development of so ware takes place. All are compulsory phases without any
one of the development cannot be possible because development con nues for the
life me of so ware with maintenance phase".

So ware Development Life Cycle (SDLC) Models

The so ware development models are those several process or approaches which are
being selected for the development of project based on the project's objec ves. To
accomplish various purposes, we have many development life cycle models. And these
models iden fy the mul ple phases of the process. Picking up the correct model for
developing the so ware applica on is very important because it will explain the what,
where, and when of our planned tes ng.
Here, are various so ware development models or methodologies:
o Waterfall model
o Spiral model
o Verifica on and valida on model
o Prototype model
o Hybrid model
Waterfall Model
It is the first sequen al-linear model because the output of the one stage is the input
of the next stage. It is simple and easy to understand, which is used for a small project.
The various phases of the waterfall model are as follows:
o Requirement analysis
o Feasibility study
o Design
o Coding
o Tes ng
o Installa on
o Maintenance
For informa on about the waterfall model, refers to the below link:
Spiral Model
It is the best suites model for a medium level project. It is also called the Cyclic and
Itera on model. Whenever the modules are dependent on each other, we go for this
model. And here, we develop applica on model wise and then handed over to the
customer. The different stages of the spiral model are as follows:
o Requirement collec on
o Design
o Coding
o Tes ng
For informa on about the spiral model, refers to the below link:
Prototype Model
From the me when customer rejec on was more in the earlier model, we go for this
model as customer rejec on is less. And also, it allows us to prepare a sample
(prototype) in the early stage of the process, which we can show to the client and get
their approval and start working on the original project. This model refers to the ac on
of crea ng the prototype of the applica on.
For informa on about the prototype model, refers to the below link:
Verifica on & Valida on Model
It is an extended version of the waterfall model. It will implement in two phases wherein
the first phase, we will perform the verifica on process, and when the applica on is
ready, we will perform the valida on process. In this model, the implementa on
happens in the V shape, which means that the verifica on process done under
downward flow and the valida on process complete in the upward flow.
For informa on about the Verifica on and valida on model, refers to the below link:
Hybrid Model
The hybrid model is used when we need to acquire the proper es of two models in the
single model. This model is suitable for small, medium, and large projects because it is
easy to apply, understand.
The combina on of the two models could be as follows:
 o V and prototype
o Spiral and Prototype

So ware Tes ng Life Cycle (STLC)

The procedure of so ware tes ng is also known as STLC (So ware Tes ng Life Cycle)
which includes phases of the tes ng process.The tes ng process is executed in a well-
planned and systema c manner. All ac vi es are done to improve the quality of the
so ware product.
Let's see, the different steps of STLC.
So ware tes ng life cycle contains the following steps:
1. Requirement Analysis
2. Test Plan Crea on
3. Environment setup
4. Test case Execu on
5. Defect Logging
6. Test Cycle Closure

Requirement Analysis:
The first step of the manual tes ng procedure is
requirement analysis. In this phase, tester
analyses requirement document of SDLC
(So ware Development Life Cycle) to examine requirements stated by the client. A er
examining the requirements, the tester makes a test plan to check whether the
so ware is mee ng the requirements or not.

Entry Criteria Ac vi es Deliverable

 For the planning of Prepare the list of all requirements and List of all the
test plan queries, and get resolved from Technical necessary
requirement Manager/Lead, System Architecture, tests for the
specifica on, Business Analyst and Client. testable
applica on Make a list of all types of tests requirements
architecture (Performance, Func onal and security) to andTest
document and well- be performed. environment
defined acceptance Make a list of test environment details, details
criteria should be which should contain all the necessary
available. tools to execute test cases.

Test Plan Crea on:

Test plan crea on is the crucial phase of STLC where all the tes ng strategies are
defined. Tester determines the es mated effort and cost of the en re project. This
phase takes place a er the successful comple on of the Requirement Analysis Phase.
Tes ng strategy and effort es ma on documents provided by this phase. Test case
execu on can be started a er the successful comple on of Test Plan Crea on.

Entry Criteria Ac vi es Deliverable

Requirement Define Objec ve as well as the scope of the Test strategy

Document so ware. document.
List down methods involved in tes ng. Tes ng Effort
Overview of the tes ng process. es ma on
Se lement of tes ng environment. documents
Prepara on of the test schedules and control are the
procedures. deliverables
Determina on of roles and responsibili es. of this
List down tes ng deliverables, define risk if phase.
any.
Environment setup:
Setup of the test environment is an independent ac vity and can be started along
with Test Case Development. This is an essen al part of the manual tes ng procedure
as without environment tes ng is not possible. Environment setup requires a group of
essen al so ware and hardware to create a test environment. The tes ng team is not
involved in se ng up the tes ng environment, its senior developers who create it.

Entry Criteria Ac vi es Deliverable

Test strategy and Prepare the list of so ware and Execu on

test plan hardware by analyzing requirement report.
document. specifica on. Defect report.
Test case A er the setup of the test
document. environment, execute the smoke test
Tes ng data. cases to check the readiness of the
test environment.

Test case Execu on:

Test case Execu on takes place a er the successful comple on of test planning. In this
phase, the tes ng team starts case development and execu on ac vity. The tes ng
team writes down the detailed test cases, also prepares the test data if required. The
prepared test cases are reviewed by peer members of the team or Quality Assurance
leader.
RTM (Requirement Traceability Matrix) is also prepared in this phase. Requirement
Traceability Matrix is industry level format, used for tracking requirements. Each test
case is mapped with the requirement specifica on. Backward & forward traceability
can be done via RTM.
 Entry Criteria Ac vi es Deliverable

Requirement Crea on of test cases. Test execu on result.

Document Execu on of test cases. List of func ons with
Mapping of test cases according the detailed explana on
to requirements. of defects.

Defect Logging:
Testers and developers evaluate the comple on criteria of the so ware based on test
coverage, quality, me consump on, cost, and cri cal business objec ves. This phase
determines the characteris cs and drawbacks of the so ware. Test cases and bug
reports are analyzed in depth to detect the type of defect and its severity.
Defect logging analysis mainly works to find out defect distribu on depending upon
severity and types.If any defect is detected, then the so ware is returned to the
development team to fix the defect, then the so ware is re-tested on all aspects of the
tes ng.
Once the test cycle is fully completed then test closure report, and test metrics are
prepared.

Entry Criteria Ac vi es Deliverable

Test case It evaluates the comple on criteria of the Closure

execu on so ware based on test coverage, quality, me report
report. consump on, cost, and cri cal business Test metrics
Defect report objec ves.
Defect logging analysis finds out defect
distribu on by categorizing in types and
severity.
Test Cycle Closure:
The test cycle closure report includes all the documenta on related to so ware design,
development, tes ng results, and defect reports.
This phase evaluates the strategy of development, tes ng procedure, possible defects
in order to use these prac ces in the future if there is a so ware with the same
specifica on.

Entry Criteria Ac vi es Deliverable

All document and Evaluates the strategy of development, Test closure

reports related to tes ng procedure, possible defects to use report
so ware. these prac ces in the future if there is a
so ware with the same specifica on

Types of So ware Tes ng

In this sec on, we are going to understand the various types of so ware tes ng, which
can be used at the me of the So ware Development Life Cycle.
As we know, so ware tes ng is a process of analyzing an applica on's func onality as
per the customer prerequisite.
If we want to ensure that our so ware is bug-free or stable, we must perform the
various types of so ware tes ng because tes ng is the only method that makes our
applica on bug-free.
The different types of So ware Tes ng
The categoriza on of so ware tes ng is a part of diverse tes ng ac vi es, such as test
strategy, test deliverables, a defined test objec ve, etc. And so ware tes ng is the
execu on of the so ware to find defects.
The purpose of having a tes ng type is to confirm the AUT (Applica on Under Test).
To start tes ng, we should have a requirement, applica on-ready, necessary resources
available. To maintain accountability, we should assign a respec ve module to different
test engineers.
The so ware tes ng mainly divided into two parts, which are as follows:

o Manual Tes ng
o Automa on Tes ng
What is Manual Tes ng?
Tes ng any so ware or an applica on according to the client's needs without using any
automa on tool is known as manual tes ng.
In other words, we can say that it is a procedure of verifica on and valida on. Manual
tes ng is used to verify the behavior of an applica on or so ware in contradic on of
requirements specifica on.
We do not require any precise knowledge of any tes ng tool to execute the manual test
cases. We can easily prepare the test document while performing manual tes ng on
any applica on.
To get in-detail informa on about manual tes ng, click on the following link: manual-
tes ng.
Classifica on of Manual Tes ng
In so ware tes ng, manual tes ng can be further classified into three different types
of tes ng, which are as follows:
o White Box Tes ng
o Black Box Tes ng
o Grey Box Tes ng

For our be er understanding let's see them one by one:

White Box Tes ng
In white-box tes ng, the developer will inspect every line of code before handing it over
to the tes ng team or the concerned test engineers.
Subsequently, the code is no ceable for developers throughout tes ng; that's why this
process is known as WBT (White Box Tes ng).
In other words, we can say that the developer will execute the complete white-box
tes ng for the par cular so ware and send the specific applica on to the tes ng team.
The purpose of implemen ng the white box tes ng is to emphasize the flow of inputs
and outputs over the so ware and enhance the security of an applica on.

White box tes ng is also known as open box tes ng, glass box tes ng, structural
tes ng, clear box tes ng, and transparent box tes ng.
To get the in-depth knowledge about white box tes ng refers to the below link: white-
box-tes ng.
Black Box Tes ng
Another type of manual tes ng is black-box tes ng. In this tes ng, the test engineer
will analyze the so ware against requirements, iden fy the defects or bug, and sends
it back to the development team.

Then, the developers will fix those defects, do one round of White box tes ng, and send
it to the tes ng team.
Here, fixing the bugs means the defect is resolved, and the par cular feature is working
according to the given requirement.
The main objec ve of implemen ng the black box tes ng is to specify the business
needs or the customer's requirements.
In other words, we can say that black box tes ng is a process of checking the
func onality of an applica on as per the customer requirement. The source code is not
visible in this tes ng; that's why it is known as black-box tes ng.

For more informa on about Black box tes ng, refers to the below link: black-box-
tes ng.
Types of Black Box Tes ng
Black box tes ng further categorizes into two parts, which are as discussed below:
o Func onal Tes ng
o Non-func on Tes ng

Func onal Tes ng

The test engineer will check all the components systema cally against requirement
specifica ons is known as func onal tes ng. Func onal tes ng is also known
as Component tes ng.
In func onal tes ng, all the components are tested by giving the value, defining the
output, and valida ng the actual output with the expected value.
Func onal tes ng is a part of black-box tes ng as its emphases on applica on
requirement rather than actual code. The test engineer has to test only the program
instead of the system.
To get the detailed informa on about func onal tes ng refers to the below
link: func onal-tes ng.
Types of Func onal Tes ng
Just like another type of tes ng is divided into several parts, func onal tes ng is also
classified into various categories.
The diverse types of Func onal Tes ng contain the following:
o Unit Tes ng
o Integra on Tes ng
o System Tes ng

Now, Let's understand them one by one:

1. Unit Tes ng
Unit tes ng is the first level of func onal tes ng in order to test any so ware. In this,
the test engineer will test the module of an applica on independently or test all the
module func onality is called unit tes ng.
The primary objec ve of execu ng the unit tes ng is to confirm the unit components
with their performance. Here, a unit is defined as a single testable func on of a
so ware or an applica on. And it is verified throughout the specified applica on
development phase.
Click on the below link to get the complete informa on about unit tes ng: unit-tes ng.
2. Integra on Tes ng
Once we are successfully implemen ng the unit tes ng, we will go integra on tes ng.
It is the second level of func onal tes ng, where we test the data flow between
dependent modules or interface between two features is called integra on tes ng.
The purpose of execu ng the integra on tes ng is to test the statement's accuracy
between each module.
Types of Integra on Tes ng
Integra on tes ng is also further divided into the following parts:
o Incremental Tes ng
o Non-Incremental Tes ng

Incremental Integra on Tes ng

Whenever there is a clear rela onship between modules, we go for incremental
integra on tes ng. Suppose, we take two modules and analysis the data flow between
them if they are working fine or not.
If these modules are working fine, then we can add one more module and test again.
And we can con nue with the same process to get be er results.
In other words, we can say that incrementally adding up the modules and test the data
flow between the modules is known as Incremental integra on tes ng.
Types of Incremental Integra on Tes ng
Incremental integra on tes ng can further classify into two parts, which are as follows:
1. Top-down Incremental Integra on Tes ng
 2. Bo om-up Incremental Integra on Tes ng

Let's see a brief introduc on of these types of integra on tes ng:

1. Top-down Incremental Integra on Tes ng
In this approach, we will add the modules step by step or incrementally and test the
data flow between them. We have to ensure that the modules we are adding are
the child of the earlier ones.
2. Bo om-up Incremental Integra on Tes ng
In the bo om-up approach, we will add the modules incrementally and check the data
flow between modules. And also, ensure that the module we are adding is the parent
of the earlier ones.
Non-Incremental Integra on Tes ng/ Big Bang Method
Whenever the data flow is complex and very difficult to classify a parent and a child, we
will go for the non-incremental integra on approach. The non-incremental method is
also known as the Big Bang method.
To get the complete informa on about integra on tes ng and its type refers to the
following link: integra on-tes ng.
3. System Tes ng
Whenever we are done with the unit and integra on tes ng, we can proceed with the
system tes ng.
In system tes ng, the test environment is parallel to the produc on environment. It is
also known as end-to-end tes ng.
In this type of tes ng, we will undergo each a ribute of the so ware and test if the end
feature works according to the business requirement. And analysis the so ware
product as a complete system.
Click on the below link to get the complete informa on about system tes ng: system-
tes ng.
Non-func onal Tes ng
The next part of black-box tes ng is non-func onal tes ng. It provides detailed
informa on on so ware product performance and used technologies.
Non-func onal tes ng will help us minimize the risk of produc on and related costs of
the so ware.
Non-func onal tes ng is a combina on of performance, load, stress, usability and,
compa bility tes ng.
For more informa on about Non-func onal tes ng, refer to the following link: non-
func onal-tes ng.
Types of Non-func onal Tes ng
Non-func onal tes ng categorized into different parts of tes ng, which we are going to
discuss further:
o Performance Tes ng
o Usability Tes ng
o Compa bility Tes ng
1. Performance Tes ng
In performance tes ng, the test engineer will test the working of an applica on by
applying some load.
In this type of non-func onal tes ng, the test engineer will only focus on several
aspects, such as Response me, Load, scalability, and Stability of the so ware or an
applica on.
Classifica on of Performance Tes ng
Performance tes ng includes the various types of tes ng, which are as follows:
o Load Tes ng
o Stress Tes ng
o Scalability Tes ng
o Stability Tes ng
 o Load Tes ng
While execu ng the performance tes ng, we will apply some load on the par cular
applica on to check the applica on's performance, known as load tes ng. Here, the
load could be less than or equal to the desired load.
It will help us to detect the highest opera ng volume of the so ware and bo lenecks.
To get the complete informa on related to the load tes ng refers to the below link:
load-tes ng.
o Stress Tes ng
It is used to analyze the user-friendliness and robustness of the so ware beyond the
common func onal limits.
Primarily, stress tes ng is used for cri cal so ware, but it can also be used for all types
of so ware applica ons.
Refers to the below link for in-depth knowledge of stress tes ng: stress-tes ng.
o Scalability Tes ng
To analysis, the applica on's performance by enhancing or reducing the load in
par cular balances is known as scalability tes ng.
In scalability tes ng, we can also check the system, processes, or database's ability to
meet an upward need. And in this, the Test Cases are designed and implemented
efficiently.
Click on the following link to get the detailed informa on related to the scalability
tes ng:
scalability-tes ng.
o Stability Tes ng
Stability tes ng is a procedure where we evaluate the applica on's performance by
applying the load for a precise me.
It mainly checks the constancy problems of the applica on and the efficiency of a
developed product. In this type of tes ng, we can rapidly find the system's defect even
in a stressful situa on.
To get detailed informa on about the stability tes ng refers to the below link:
stability-tes ng.
2. Usability Tes ng
Another type of non-func onal tes ng is usability tes ng. In usability tes ng, we will
analyze the user-friendliness of an applica on and detect the bugs in the so ware's
end-user interface.
Here, the term user-friendliness defines the following aspects of an applica on:
o The applica on should be easy to understand, which means that all the features
must be visible to end-users.
o The applica on's look and feel should be good that means the applica on should
be pleasant looking and make a feel to the end-user to use it.
For more informa on about usability tes ng, we can refer to the following link:
usability-tes ng.
3. Compa bility Tes ng
In compa bility tes ng, we will check the func onality of an applica on in specific
hardware and so ware environments. Once the applica on is func onally stable then
only, we go for compa bility tes ng.
Here, so ware means we can test the applica on on the different opera ng systems
and other browsers, and hardware means we can test the applica on on different sizes.
Grey Box Tes ng
Another part of manual tes ng is Grey box tes ng. It is a collabora on of black box
and white box tes ng.
Since, the grey box tes ng includes access to internal coding for designing test cases.
Grey box tes ng is performed by a person who knows coding as well as tes ng.

In other words, we can say that if a single-person team done both white box and black-
box tes ng, it is considered grey box tes ng.
To get the in-details informa on about Grey box tes ng, we can refer to the below link:
grey-box-tes ng.

Automa on Tes ng
The most significant part of So ware tes ng is Automa on tes ng. It uses specific tools
to automate manual design test cases without any human interference.
Automa on tes ng is the best way to enhance the efficiency, produc vity, and coverage
of So ware tes ng.
It is used to re-run the test scenarios, which were executed manually, quickly, and
repeatedly.
In other words, we can say that whenever we are tes ng an applica on by using some
tools is known as automa on tes ng.
We will go for automa on tes ng when various releases or several regression cycles
goes on the applica on or so ware. We cannot write the test script or perform the
automa on tes ng without understanding the programming language.
For more informa on about automa on tes ng, we can refer to the below link:
automa on-tes ng.
Some other types of So ware Tes ng
In so ware tes ng, we also have some other types of tes ng that are not part of any
above discussed tes ng, but those tes ng are required while tes ng any so ware or an
applica on.
o Smoke Tes ng
o Sanity Tes ng
o Regression Tes ng
o User Acceptance Tes ng
o Exploratory Tes ng
 o Adhoc Tes ng
o Security Tes ng
o Globaliza on Tes ng
Let's understand those types of tes ng one by one:

In smoke tes ng, we will test an applica on's basic and cri cal features before doing
one round of deep and rigorous tes ng.
Or before checking all possible posi ve and nega ve values is known as smoke tes ng.
Analyzing the workflow of the applica on's core and main func ons is the main
objec ve of performing the smoke tes ng.
For more informa on about smoke tes ng, refers to the following link:
smoke-tes ng.
Sanity Tes ng
It is used to ensure that all the bugs have been fixed and no added issues come into
existence due to these changes. Sanity tes ng is unscripted, which means we cannot
documented it. It checks the correctness of the newly added features and components.
To get the in-detail informa on about sanity tes ng, we can refer to the below link:
sanity-tes ng.
Regression Tes ng
Regression tes ng is the most commonly used type of so ware tes ng. Here, the
term regression implies that we have to re-test those parts of an unaffected
applica on.
Regression tes ng is the most suitable tes ng for automa on tools. As per the project
type and accessibility of resources, regression tes ng can be similar to Retes ng.
Whenever a bug is fixed by the developers and then tes ng the other features of the
applica ons that might be simulated because of the bug fixing is known as regression
tes ng.
In other words, we can say that whenever there is a new release for some project, then
we can perform Regression Tes ng, and due to a new feature may affect the old
features in the earlier releases.
To get thorough knowledge related to regression tes ng, refer to the below link:
regression-tes ng.
User Acceptance Tes ng
The User acceptance tes ng (UAT) is done by the individual team known as domain
expert/customer or the client. And knowing the applica on before accep ng the final
product is called as user acceptance tes ng.
In user acceptance tes ng, we analyze the business scenarios, and real- me scenarios
on the dis nct environment called the UAT environment. In this tes ng, we will test the
applica on before UAI for customer approval.
For more informa on about the User acceptance tes ng, click on the below link:
acceptance-tes ng.
Exploratory Tes ng
Whenever the requirement is missing, early itera on is required, and the tes ng team
has experienced testers when we have a cri cal applica on. New test engineer entered
into the team then we go for the exploratory tes ng.
To execute the exploratory tes ng, we will first go through the applica on in all possible
ways, make a test document, understand the flow of the applica on, and then test the
applica on.
Click on the following link to get the complete informa on about exploratory tes ng:
exploratory-tes ng.
Adhoc Tes ng
Tes ng the applica on randomly as soon as the build is in the checked sequence is
known as Adhoc tes ng.
It is also called Monkey tes ng and Gorilla tes ng. In Adhoc tes ng, we will check the
applica on in contradic on of the client's requirements; that's why it is also known
as nega ve tes ng.
When the end-user using the applica on casually, and he/she may detect a bug. S ll,
the specialized test engineer uses the so ware thoroughly, so he/she may not iden fy
a similar detec on.
Refers to the following to get the in-detail informa on about Adhoc tes ng:
adhoc-tes ng.
Security Tes ng
It is an essen al part of so ware tes ng, used to determine the weakness, risks, or
threats in the so ware applica on.
The execu on of security tes ng will help us to avoid the nasty a ack from outsiders
and ensure our so ware applica ons' security.
In other words, we can say that security tes ng is mainly used to define that the data
will be safe and endure the so ware's working process.
To get the complete detail about security tes ng, refer to the below link: security-
tes ng.
Globaliza on Tes ng
Another type of so ware tes ng is Globaliza on tes ng. Globaliza on tes ng is used
to check the developed so ware for mul ple languages or not. Here, the
words globaliza on means enlightening the applica on or so ware for various
languages.
Globaliza on tes ng is used to make sure that the applica on will support mul ple
languages and mul ple features.
In present scenarios, we can see the enhancement in several technologies as the
applica ons are prepared to be used globally.

Levels of Tes ng
In this sec on, we are going to understand the various levels of so ware tes ng.
As we learned in the earlier sec on of the so ware tes ng tutorial that tes ng any
applica on or so ware, the test engineer needs to follow mul ple tes ng techniques.
In order to detect an error, we will implement so ware tes ng; therefore, all the errors
can be removed to find a product with more excellent quality.
What are the levels of So ware Tes ng?
Tes ng levels are the procedure for finding the missing areas and avoiding overlapping
and repe on between the development life cycle stages. We have already seen the
various phases such as Requirement collec on, designing, coding tes ng,
deployment, and maintenance of SDLC (So ware Development Life Cycle).
In order to test any applica on, we need to go through all the above phases of SDLC.
Like SDLC, we have mul ple levels of tes ng, which help us maintain the quality of the
so ware.
Different Levels of Tes ng
The levels of so ware tes ng involve the different methodologies, which can be used
while we are performing the so ware tes ng.
In so ware tes ng, we have four different levels of tes ng, which are as discussed
below:
1. Unit Tes ng
2. Integra on Tes ng
3. System Tes ng
4. Acceptance Tes ng

As we can see in the above image that all of these tes ng levels have a specific objec ve
which specifies the value to the so ware development lifecycle.
For our be er understanding, let's see them one by one:
Level1: Unit Tes ng
Unit tes ng is the first level of so ware tes ng, which is used to test if so ware
modules are sa sfying the given requirement or not.
The first level of tes ng involves analyzing each unit or an individual component of the
so ware applica on.
Unit tes ng is also the first level of func onal tes ng. The primary purpose of execu ng
unit tes ng is to validate unit components with their performance.
A unit component is an individual func on or regula on of the applica on, or we can
say that it is the smallest testable part of the so ware. The reason of performing the
unit tes ng is to test the correctness of inaccessible code.
Unit tes ng will help the test engineer and developers in order to understand the base
of code that makes them able to change defect causing code quickly. The developers
implement the unit.
For more informa on on unit tes ng, refers to the following link:
unit-tes ng.
Level2: Integra on Tes ng
The second level of so ware tes ng is the integra on tes ng. The integra on tes ng
process comes a er unit tes ng.
It is mainly used to test the data flow from one module or component to other
modules.
In integra on tes ng, the test engineer tests the units or separate components or
modules of the so ware in a group.
The primary purpose of execu ng the integra on tes ng is to iden fy the defects at the
interac on between integrated components or units.
When each component or module works separately, we need to check the data flow
between the dependent modules, and this process is known as integra on tes ng.
We only go for the integra on tes ng when the func onal tes ng has been completed
successfully on each applica on module.
In simple words, we can say that integra on tes ng aims to evaluate the accuracy of
communica on among all the modules.
For more informa on on integra on tes ng, refers to the following link:
integra on-tes ng.
Level3: System Tes ng
The third level of so ware tes ng is system tes ng, which is used to test the so ware's
func onal and non-func onal requirements.
It is end-to-end tes ng where the tes ng environment is parallel to the produc on
environment. In the third level of so ware tes ng, we will test the applica on as a
whole system.
To check the end-to-end flow of an applica on or the so ware as a user is known
as System tes ng.
In system tes ng, we will go through all the necessary modules of an applica on and
test if the end features or the end business works fine, and test the product as a
complete system.
In simple words, we can say that System tes ng is a sequence of different types of tests
to implement and examine the en re working of an integrated so ware computer
system against requirements.
For more informa on on System tes ng, refers to the following link:
system-tes ng.
Level4: Acceptance Tes ng
The last and fourth level of so ware tes ng is acceptance tes ng, which is used to
evaluate whether a specifica on or the requirements are met as per its delivery.
The so ware has passed through three tes ng levels (Unit Tes ng, Integra on Tes ng,
System Tes ng). Some minor errors can s ll be iden fied when the end-user uses the
system in the actual scenario.
In simple words, we can say that Acceptance tes ng is the squeezing of all the tes ng
processes that are previously done.
The acceptance tes ng is also known as User acceptance tes ng (UAT) and is done by
the customer before accep ng the final product.
Usually, UAT is done by the domain expert (customer) for their sa sfac on and checks
whether the applica on is working according to given business scenarios and real- me
scenarios.
For more informa on on System tes ng, refers to the following link:
acceptance-tes ng.