Unit

3
How Developers Test Their Own Code?
 Black Box testers don’t care about Unit Testing. Their main goal is
to validate the application against the requirements without going
into the implementation details.
 But as a curious or out of the box thinking, have you ever wondered
how developers test their code? What method do they use to test
before releasing the code for testing? How is dev-testing important
in an agile process?
 The answer to all this is Unit Testing. the importance of Unit
Testing so that development and testing teams can work more
collaboratively to design, test and release an excellent
application.

What Is Unit Testing?

 Usually, developers and sometimes white box testers write Unit
tests to improve code quality by verifying every unit of the code
used to implement functional requirements
 Unit Testing is the method of verifying the smallest piece of
testable code against its purpose.” If the purpose or requirement
fails then the unit test has failed.
 Unit testing is a type of software testing that focuses on individual
units or components of a software system.
 The purpose of unit testing is to validate that each unit of the
software works as intended and meets the requirements.
 Unit testing is typically performed by developers, and it is
performed early in the development process before the code is
integrated and tested as a whole system.

Unit Testing in SDLC

 For Unit testing, developers use manual or automated tests to

ensure that each unit in the software meets the customer’s
requirement.
 This unit can be an individual function, object, method, procedure,
or module in the software under test.. During software
development, it is done as the first level of testing.
 It uses both black box and white box testing.

Unit Testing Techniques:

Unit testing uses all white box testing techniques as it uses the code of
software

application:
o Data flow Testing
 o Control Flow Testing
o Branch Coverage Testing
o Statement Coverage Testing
o Decision Coverage Testing
Advantages
o Unit testing uses module approach due to that any part can
be tested without waiting for completion of another parts
testing.
o The developing team focuses on the provided functionality
of the unit and how functionality should look in unit test suits
to understand the unit API.
o Unit testing allows the developer to refactor code after a
number of days and ensure the module still working without
any defect.
o Early Detection of Issues: Unit testing allows developers to
detect and fix issues early in the development process
before they become larger and more difficult to fix

Disadvantages
o It cannot identify integration or broad level error as it works on units of
the code.
o In the unit testing, evaluation of all execution paths is not
possible, so unit testing is not able to catch each and every
error in a program.
o It is best suitable for conjunction with other testing activities.

What Is Integration Testing

o Integration testing is done to test the modules/components

when integrated to verify that they work as expected i.e. to
test the modules which are working fine individually does not
have issues when integrated.
o Integration testing is the process of testing the interface
between two software units or modules.
o It focuses on determining the correctness of the interface.
o The purpose of integration testing is to expose faults in the
interaction between integrated units
o When talking in terms of testing large application using black
box testing technique, involves the combination of many
modules which are tightly coupled with each other.
o We can apply the Integration testing technique concepts for
testing these types of scenarios.

o The meaning of Integration testing is quite straightforward-

Integrate/combine the unit tested module one by one and test
the behavior as a combined unit
  The main function or goal of this testing is to test the interfaces between the
units/module.
o We normally do Integration testing after “Unit testing”.
o Once all the individual units are created and tested, we
start combining those “Unit Tested” modules and start
doing the integrated testing.

o The individual modules are first tested in isolation.

o Once the modules are unit tested, they are integrated one by
one, till all the modules are integrated, to check the
combinational behavior, and validate whether the
requirements are implemented correctly or not.

WHY INTEGRATION
TEST WORKS?
1. In the real world, when applications are developed, it is
broken down into smaller modules and individual developers
are assigned 1 module. The logic implemented by one
developer is quite different than another developer, so it
becomes important to check whether the logic implemented
by a developer is as per the expectations and rendering the
correct value in accordance with the prescribed standards.
2. Many a time the face or the structure of data changes when
it travels from one module to another. Some values are
appended or removed, which causes issues in the later
modules.
3. Modules also interact with some third party tools or APIs
which also need to be tested that the data accepted by
that API / tool is correct and that the response generated
is also as expected.
4. A very common problem in testing – Frequent
requirement change! :) Many a time developer deploys
the changes without unit testing it. Integration testing
becomes important at that time.
Advantages
There are several advantages of this testing and few of them are
listed below.
● This testing makes sure that the integrated modules/components work
properly.
● Integration testing can be started once the modules to be
tested are available. It does not require the other module to
be completed for testing to be done, as Stubs and Drivers
can be used for the same.
● It detects the errors related to the interface.
Challenges
Listed below are few challenges that are involved in Integration
Test.
#1) Integration testing means testing two or more integrated
systems in order to ensure that the system works properly. Not
only the integration links should be tested but an exhaustive
testing considering the environment should be done to ensure
that the integrated system works properly. There might be
different paths and permutations which can be applied to test
the integrated system.
#2) Managing Integration testing becomes complex because
of few factors involved in it like the database, Platform,
environment etc.
#3) While integrating any new system with the legacy system, it
requires a lot of changes and testing efforts. Same applies while
integrating any two legacy systems.
#4) Integrating two different systems developed by two different
companies is a big challenge as for how one of the systems will
impact the other system if any changes are done in any one of
the systems is not sure.
Types of Integration Testing
Given below is a type of Test Integration along with its advantages
and disadvantages.
Big Bang Approach:
o Big bang approach integrates all the modules in one go i.e. it
does not go for integrating the modules one by one.
o It verifies if the system works as expected or not once
integrated.
o If any issue is detected in the completely integrated module,
then it becomes difficult to find out which module has caused
the issue.

o Big bang approach is a time-consuming process of finding a

module which has a defect itself as that would take time and
once the defect is detected, fixing the same would cost high
as the defect is detected at the later stage.

Advantages of Big Bang approach:

● It is a good approach for small systems.
Disadvantages of Big Bang Approach:
● It is difficult to detect the module which is causing an issue.
 ●Big Bang approach requires all the modules all together
for testing, which in turn, leads to less time for testing as
designing, development, Integration would take most of
the time.
● Testing takes place at once only which thereby leaves
no time for critical module testing in isolation.
Test Integration Approaches
There are fundamentally 2 approaches for doing test integration:

1. Bottom-up approach
2. Top-down approach.
Let’s consider the below figure to test the approaches:

Bottom-up approach:
Bottom-up testing, as the name suggests starts from the lowest
or the innermost unit of the application, and gradually moves up.
The Integration testing starts from the lowest module and
gradually progresses towards the upper modules of the
application.
This integration continues till all the modules are integrated and
the entire application is tested as a single unit.
Example:
In this case, modules B1C1, B1C2 & B2C1, B2C2 are the lowest
module which is unit tested. Module B1 & B2 are not yet
developed.
The functionality of Module B1 and B2 is that it calls the modules
B1C1, B1C2 & B2C1, B2C2. Since B1 and B2 are not yet
developed, we would need some program or a “stimulator” which
will call the B1C1, B1C2 & B2C1, B2C2 modules. These stimulator
programs are called DRIVERS.

In simple words, DRIVERS are the dummy programs which are

used to call the functions of the lowest module in a case when the
calling function does not exist.
The bottom-up technique requires module driver to feed test case
input to the interface of the module being tested.
The advantage of this approach is that, if a major fault exists at
the lowest unit of the program, it is easier to detect it, and
corrective measures can be taken.
 The disadvantage is that the main program actually does not
exist until the last module is integrated and tested. As a result,
the higher level design flaws will be detected only at the end.

Top-down approach
This technique starts from the topmost module and gradually
progress towards the lower modules. Only the top module is unit
tested in isolation. After this, the lower modules are integrated
one by one. The process is repeated until all the modules are
integrated and tested.

In the context of our figure, testing starts from Module A, and

lower modules B1 and B2 are integrated one by one. Now here
the lower modules B1 and B2 are not actually available for
integration. So in order to test the topmost modules A, we
develop “STUBS”.
“Stubs” can be referred to as code a snippet which accepts the
inputs/requests from the top module and returns the results/
response. This way, in spite of the lower modules, do not exist,
we are able to test the top module.

In practical scenarios, the behavior of stubs is not that simple as

it seems. In this era of complex modules and architecture, the
called module, most of the time involves complex business logic
like connecting to a database. As a result, creating Stubs
becomes as complex and time taking as the real module. In some
cases, Stub module may turn out to be bigger than the
stimulated module.

Both Stubs and drivers are dummy piece of code which is used
for testing the “non- existing” modules. They trigger the
functions/method and return the response, which is compared to
the expected behavior.

Unit Testing Integration Testing

Unit Testing vs Integration Testing

Tests the single component of the Tests the system components

whole system i.e. tests a unit in working together i.e. test the
isolation. collaboration of multiple units.
 Faster to execute Can run slow

No external dependency. Any external Requires interaction with external

dependency is mocked or stubbed dependencies (e.g. Database,
out. hardware, etc.)

Simple Complex

Conducted by developer Conducted by tester

It is a type of white box testing It is a type of black box testing

Carried out at the initial phase of Must be carried out

testing and then can be performed after unit testing and
anytime before system testing

Cheap maintenance Expensive maintenance

Begins from the module specification Begins from the interface specification
Unit testing has a narrow scope as it just checks if each small It has a wider scope as it covers the
piece of code is doing what it is intended to do. whole application

The outcome of unit testing is detailed visibility of the code The outcome of
integration testing is
the detailed visibility of
the integration
structure

Uncover the issues within the Uncover the bugs arise when
functionality of individual modules different modules interact with each
only. Does not exposes integration other to form the overall system
errors or system-wide issues.

Let’s conclude some difference between Stubs and Driver:

STUBS
DRIVER

Used in Top down approach Used in Bottom up approach

Top most module is tested first Lowest modules are tested first.
Stimulates the lower level of components Stimulates the higher level of
components
Dummy program of lower level components Dummy program for Higher level component

The only change is Constant in this world, so we have another

approach called “Sandwich testing” which combines the
features of both Top-down and bottom-up approach. When we
test huge programs like Operating systems, we have to have
some more techniques which are efficient and boosts more
confidence. Sandwich testing plays a very important role here,
where both, the Top down and bottom up testing are started
simultaneously.
Integration starts with the middle layer and moves
simultaneously towards up and down. In case of our figure, our
testing will start from B1 and B2, where one arm will test the
upper module A and another arm will test the lower modules
B1C1, B1C2 & B2C1, B2C2.

Example:
Let us understand these three types of testing with an oversimplified
example.

E.g. For a functional mobile phone, the main parts required are “battery”
and “sim card”.
Unit testing Example – The battery is checked for its life,
capacity and other parameters. Sim card is checked for its
activation.
Integration Testing Example – Battery and sim card are
integrated i.e. assembled in order to start the mobile phone.
Functional Testing Example – The functionality of a mobile
phone is checked in terms of its features and battery usage as
well as sim card facilities.

let us now take a technical example of a login page:

 Almost every web application requires its users/customers to
log in. For that, every application has to have a “Login” page
which has these elements:
● Account/Username
● Password
● Login/Sign in Button
For Unit Testing, the following may be the test cases:
● Field length – username and password fields.
● Input field values should be valid.
● The login button is enabled only after valid values (Format
and lengthwise) are entered in both the fields.
For Integration Testing, the following may be the test cases:
● The user sees the welcome message after entering valid values and
pushing the login button.
● The user should be navigated to the welcome page or home
page after valid entry and clicking the Login button.
Now, after unit and integration testing are done, let us see the
additional test cases that are considered for functional
testing:
1. The expected behavior is checked, i.e. is the user able to
log in by clicking the login button after entering a valid
username and password values.
2. Is there a welcome message that is to appear after a successful login

Is there an error message that should appear on an invalid login?

3. Are there any stored site cookies for login fields?
4. Can an inactivated user log in?
5. Is there any ‘forgot password’ link for the users who have forgotten
their passwords?

System testing: System Testing means testing the system as a

whole. All the modules/components are integrated in order to
verify if the system works as expected or not.
System Testing is done after Integration Testing. This plays an
important role in delivering a high-quality product.
The process of testing an integrated hardware and software
system to verify that the system meets its specified
requirements.
Verification: Confirmation by examination and provisions of
objective evidence that specified requirements have been
fulfilled.
If an application has three modules A, B, and C, then testing done
by combining the modules A & B or module B & C or module A& C
is known as Integration testing. Integrating all the three modules
and testing it as a complete system is termed as System testing.
 Is This A White-box Or Black-box
Testing?
System testing can be
considered as a black-
box test technique.

Black box Testing technique

does not require internal
knowledge of the code
whereas the
white box technique requires internal knowledge of the code.
While performing System testing functional & non-functional,
security, Performance and many other testing types are covered
and they are tested using a black-box technique wherein the
input is provided to the system and the output is verified. System
internal knowledge is not required.

Black Box Technique:

Types Of System Testing
ST is called a superset of all types of testing as all the major
types of testing are covered in it. Although a focus on types of
testing may vary on the basis of product, organization processes,
timeline, and requirements.

The overall it can be defined as below

Functionality Testing: To make sure that functionality of the product
is working as per the requirements defined, within the capabilities of the
system.
Recoverability Testing: To make sure how well the system
recovers from various input errors and other failure situations.
Interoperability Testing: To make sure whether the system
can operate well with third-party products or not.
Performance Testing: To make sure the system’s performance
under the various condition, in terms of performance
characteristics.
Scalability Testing: To make sure the system’s scaling abilities
in various terms like user scaling, geographic scaling, and
resource scaling.
Reliability Testing: To make sure the system can be operated
for a longer duration without developing failures.
Regression Testing: To make sure the system’s stability as it
passes through an integration of different subsystems and
maintenance tasks.
Documentation Testing: To make sure that the system’s user
guide and other help topics documents are correct and usable.
Security Testing: To make sure that the system does not allow
unauthorized access to data and resources.
Usability Testing: To make sure that the system is easy to use, learn and
operate.
More System Testing Types

#1) Graphical User Interface Testing (GUI):

GUI testing is done to verify if the GUI of a system works as
expected or not. GUI is basically what is visible to a user while
he uses the application. GUI testing involves testing buttons,
icons, checkboxes, List box, Textbox, menus, toolbars, dialog
boxes, etc.

#2) Compatibility Testing:

Compatibility testing is done to ensure that the developed
product is compatible with different browsers, Hardware
Platforms, Operating System and databases as per the
requirement document.
#3) Exception Handling:
Exception Handling Testing is performed to verify that even if an
unexpected error occurs in the product, it should show the
correct error message and does not let the application stop. It
handles the exception in a way that the error is shown meanwhile
the product recovers and allows the system to process the
incorrect transaction.

#4) Volume Testing:

Volume Testing is a type of non-functional testing wherein
testing is done using a huge amount of data. For Example,
the Volume of data is increased in the database to verify the
system performance. #5) Stress Testing:
Stress Testing is done by increasing the number of users (at the
same time) on an application to an extent that the application
breaks down. This is done to verify the point at which the
application will break down.
#6) Sanity Testing:
Sanity Testing is performed when the build is released with a
change in the code or functionality or if any bug has been fixed. It
verifies that the changes done have not affected the code and no
other issue has occurred because of that and the system works
as previously.
If in case any issue occurs, then the build is not accepted for further testing.
Basically, thorough testing is not done for the build in order to
save time & cost as it rejects the build for an issue found. Sanity
testing is done for the change done or for the fixed issue and not
for the complete system.
#7) Smoke Testing:
Smoke Testing is a testing that is performed on the build to
verify if the build is further testable or not. It verifies that the
build is stable to test and all the critical functionalities are
working fine. Smoke testing is done for the complete system i.e.
end to end testing is done.
#8) Exploratory Testing:
Exploratory Testing as the name itself suggests it is all about
exploring the application. No scripted testing is performed in
exploratory testing. Test cases are written along with the testing.
It focuses more on execution than planning.
Tester has the freedom to test on his own using his intuition,
experience, and intellect. A tester can choose any feature to test
first i.e. randomly he can pick the feature to test, unlike the other
techniques where the structural way is used to perform testing.
#9) Adhoc Testing:
Adhoc Testing is informal testing where no documentation or
planning is done to test the application. Tester tests the
application without any test cases. The aim of a tester is to
break the application. The tester uses his experience, guess
and intuition to find the critical issues in the application.
#10) Installation Testing:
Installation Testing is to verify if the software gets installed without any
issues.
This is the most important part of testing as the installation of
the software is the very first interaction between the user and
the product. The type of installation testing depends on
various factors like operating system, Platform, distribution of
software, etc.
#11) Maintenance Testing:
Once the product goes live, the issue can occur in a live
environment or some enhancement might be required in the
product.
The product needs maintenance once it goes live and that is
taken care by the maintenance team. The testing done for any
issues or enhancement or migration to the hardware falls under
maintenance testing.
What Is System Integration Testing?
It is a type of testing in which the system’s ability to maintain
data integrity and operation in coordination with other systems in
the same environment, is being checked.
Example of System Integration Testing:
Let’s take the example of a well-known online ticket booking site –
http://irctc.co.in.

This is a ticket booking facility; an online shopping facility

interacts with PayPal. Overall you can consider it as A*B*C=R.

Now on the system level, online ticket booking facility, online

shopping facility, and online payment option facility can be
system tested independently, followed by check perform
Integration tests for each of them. And then the whole system
needs to be systematically tested.

So where does System Integration testing come into the picture?

The web portal http://Irctc.co.in is a combination of systems. You
may perform tests at the same level (single system, the system
of systems), but at each level, you may want to focus on different
risks (integration problems, independent functionality).

● While testing the Online Ticket booking facility, you may

verify if you are able to book tickets online. You may also
consider integration problems For Example, Ticket booking
facility integrates back-end with front-end (UI). For
Example, how front-end behaves when the database server
is slow to respond?
● Testing of Online ticket booking facility with online shopping
facility. You may verify that the online shopping facility is
available for the users logged into the system to book
tickets online. You may also consider verification of
integration in the online shopping facility. For Example, if
the user is able to select and buy a product without a
hassle.
● Testing of online ticket booking facility’s integration with
PayPal. You may verify whether, after booking tickets,
money was transferred from your PayPal account to the
Online Ticket Booking
 account. You may also consider the verification of
integration in PayPal. For Example, what if the system
puts two entries in a database after debiting money for
once only?
Difference between System Testing and System Integration
Testing:
The main difference is:

● System Testing looks after a single system’s integrity with relevant

environment
● System Integration Testing looks after multiple systems’
integrity with each other, being in the same environment.
Thus, the system test is the beginning of real testing where you
test a product as a whole and not a module/feature.

Regression Testing

Regression Testing is defined as a type of software testing to

confirm that a recent program or code change has not adversely
affected existing features. Regression Testing is nothing but a full
or partial selection of already executed test cases which are re-
executed to ensure existing functionalities work fine. This testing
is done to make sure that new code changes should not have side
effects on the existing functionalities. It ensures that the old code
still works once the latest code changes are done.
Need of Regression Testing:The Need of Regression
Testing mainly arises whenever there is requirement to
change the code and we need to test whether the modified
code affects the other part of software application or not.
Moreover, regression testing is needed, when a new feature is
added to the software application and for defect fixing as well
as performance issue fixing.

Why and when can we perform regression testing?We do

regression testing whenever code is modified.The following are
the scenario for performing regression testing:

● New features are added.

● Changes to the existing requirements made.
● There is a defect that needs a fix.
● There are performance issues that need to be solved.
● 1. When new functionalities added.The website or
application has login functionality, which allows users to
login with the only Email. Now, providing a new feature to
log in with a Phone Number.
● 2. When there is any change requirement.Removed
the "Remember Password" button, which was present
before.
● 3. When there is a defect that needs a fix.In case the
sign-up button does not work, then a bug generated by the
tester. The developers fix it, and once the bug gets fixed,
the tester verifies the Sign-Up button is working fine.
Similarly, the tester also tests other functionality, which is
related to the Sign-Up.
● 4. When performance issue is solved. Reducing the loading time of
any page.

Types of Regression Testing

● Corrective Regression Testing: Corrective performance

testing is appreciated for its simplicity as it requires fewer
efforts. It reuses the existing test cases, given that no
major changes in the product specifications have been
made (no need to change a testing scenario).
● Retest-all Regression Testing:As the name suggests,
this is a complex testing approach that needs all the
system’s components tested again from scratch. This test
checks retrospectively every small change that’s been
made since the very start. Sometimes, this approach is
used when suspicions arise that something was missed (or
wasn’t done right) during the previous testing stages. Under
such circumstances, it can be more effective to retest
everything from scratch than attempting to identify what
went wrong previously.
● Selective Regression Testing:This type of testing can be
viewed as a middle ground between corrective regression
testing and retest-all regression testing: it’s not as basic as
the first one, but not as comprehensive as the latter one.
Selective regression testing picks certain test cases from a
set to inspect the affected parts of the code.
 ● Progressive Regression Testing:When the established
test cases are no longer useful, the newer ones get created.
This is often a case when the product specifications are
modified, so new test cases must be created to address the
changing requirements. Progressive regression testing
involves using new testing scenarios when the product
vision is affected.
● Complete Regression Testing:Many companies adopt
the Agile methodology that encourages doing fewer but
frequent updates. In real life, that’s not always possible:
companies need to react quickly to the ever-changing client
demands. Thus, large-scale system updates are possible
(but not likely). But when they do happen, complete
regression testing is performed: it’s a must when the root
code has been changed.
● Partial Regression Testing:You can view software
development as building a LEGO house: you create separate
blocks first, then you combine them, and you end up with an
entire house.
● Unit Regression Testing:That is a straightforward
approach that is focused on testing code as a single unit
with all the dependencies, integrations, and interactions
left outside the scope.
How to do Regression Testing
In order to do Regression Testing process, we need to first
debug the code to identify the bugs. Once the bugs are identified,
required changes are made to fix it, then the regression testing is
done by selecting relevant test cases from the test suite that
covers both modified and affected parts of the code.
Software maintenance is an activity which includes
enhancements, error corrections, optimization and deletion of
existing features. These modifications may cause the system to
work incorrectly. Therefore, Regression Testing becomes
necessary. Regression Testing can be carried out using the
following techniques:

Retest All

● This is one of the methods for Regression Testing in which

all the tests in the existing test bucket or suite should be re-
executed. This is very expensive as it requires huge time
 and resources.
Regression Test Selection:Regression Test Selection is a
technique in which some selected test cases from test suite are
executed to test whether the modified code affects the software
application or not. Test cases are categorized into two parts,
reusable test cases which can be used in further regression cycles
and obsolete test cases which can not be used in succeeding
cycles.
Prioritization of Test Cases
● Prioritize the test cases depending on business impact,
critical & frequently used functionalities. Selection of test
cases based on priority will greatly reduce the regression
test suite.

Web Application Testing:

An organization is needed to develop a website that is

informative, accessible and user-friendly. To maintain all these
qualities, the website should be well tested, and this process of
testing a website is known as web testing.
Web testing is a software testing practice to test websites or web
applications for potential bugs. It’s a complete testing of web-
based applications before making live.
A web-based system needs to be checked completely from end-to-end
before it goes live for end users.

By performing website testing, an organization can make sure

that the web-based system is functioning properly and can be
accepted by real-time users.
The UI design and functionality are the captains of website testing.
Web Testing Checklists
1) Functionality Testing
2) Usability testing
3) Interface testing
4) Compatibility testing
5) Performance testing
6) Security testing
#1) Functionality Testing
Test for – all the links in web pages, database connection,
forms used for submitting or getting information from the user
in the web pages, Cookie testing, etc.
Check out all the links:
● Test the outgoing links from all the pages to the specific domain under
test.
● Test all internal links.
● Test links jumping on the same page.
● Test links are used to send emails to admin or other users from web
pages.
● Test to see if there are any orphan pages.
● Finally, link checking includes, check for broken links in all the above-
mentioned links.
Test forms on all pages:
Forms are an integral part of any website. Forms are used for
receiving information from users and to interact with them. So
what should be checked in these forms?
● First, check all the validations on each field.
● Check for default values in the fields.
● Wrong inputs in the forms to the fields in the forms.
● Options to create forms, if any, form delete, view or modify the forms.
So the sign up flow should be executed correctly. There are
different field validations like email Ids, User financial info
validations, etc. All these validations should get checked in
manual or automated web testing.

Cookie Testing:
Cookies are small files stored on the user machine. These are
basically used to maintain the session – mainly the login sessions.
Test the application by enabling or disabling the cookies in your
browser options.
Test if the cookies are encrypted before writing to the user
machine. If you are testing session cookies (i.e. cookies that
expire after the session ends) check for login sessions and user
stats after the session ends.
Check the effect on application security by deleting the cookies. (I
will soon write a separate article on cookie testing as well)
Validate your HTML/CSS:
If you are optimizing your site for Search engines then HTML/CSS
validation is the most important one. Mainly validate the site for
HTML syntax errors. Check if the site is crawlable to different
search engines. Database Testing:
Data consistency is also very important in a web application.
Check for data integrity and errors while you edit, delete, modify
the forms or do any DB related functionality.
Check if all the database queries are executed correctly, data is
retrieved and also updated correctly. More on database testing
could be a load on DB, we will address this in web load or
performance testing below. In testing the functionality of the
websites the following should be tested:
Links
i. Internal Links
ii. External Links
iii. Mail Links
iv. Broken Links
Forms
i. Field validation
ii. Error message for wrong input
iii. Optional and Mandatory fields
Database
Testing will be done on database integrity.
#2) Usability Testing
Usability testing is the process by which the human-computer
interaction characteristics of a system are measured, and
weaknesses are identified for correction.
• Ease of learning
• Navigation
• Subjective user satisfaction
• General appearance
Test for Navigation:
Navigation means how a user surfs the web pages, different
controls like buttons, boxes or how the user uses the links on the
pages to surf different pages.
Usability Testing includes the following:
● The website should be easy to use.
● The instructions provided should be very clear.
● Check if the instructions provided are perfect to satisfy its purpose.
● The main menu should be provided on each page.
● It should be consistent enough.
Content Checking:
Content should be logical and easy to understand. Check for
spelling errors. The usage of dark colors annoys the users and
should not be used in the site theme.
You can follow some standard colors that are used for web pages
and content building. These are the commonly accepted
standards like what I mentioned above about annoying colors,
fonts, frames, etc. Content should be meaningful. All the anchor
text links should be working properly. Images should be placed
properly with proper sizes.
These are some of the basic important standards that should be
followed in web development. Your task is to validate everything
for UI testing.
Other user information for user help:
Like the search option, the sitemap also helps with files, etc. The
sitemap should be available with all the links on websites with a
proper tree view of navigation. Check for all links on the sitemap.
“Search in the site” option will help users to find content pages
that they are looking for easily and quickly. These are all
optional items and if present they should be validated.
#3) Interface Testing
In web testing, the server-side interface should be tested. This
can be done by verifying that the communication is done
properly. Compatibility of the server with software, hardware,
network, and the database should be tested.
The main interfaces are:
● Web server and application server interface
● Application server and Database server interface.
Check if all the interactions between these servers are executed
and errors are handled properly. If the database or web server
returns an error message for any query by the application server
then the application server should catch and display these error
messages appropriately to the users.
Check what happens if the user interrupts any transaction in-
between? Check what happens if the connection to the webserver
is reset in between?
#4) Compatibility Testing
The compatibility of your website is a very important testing aspect.
See which compatibility test to be executed:
● Browser compatibility
● Operating system compatibility
● Mobile browsing
● Printing options

Browser Compatibility:
Some applications are very dependent on browsers. Different
browsers have different configurations and settings that your
web page should be compatible with.
Your website coding should be a cross-browser platform
compatible. If you are using java scripts or AJAX calls for UI
functionality, performing security checks or validations then
give more stress on browser compatibility testing of your web
application.
Test web applications on different browsers like Internet Explorer,
Firefox, Netscape Navigator, AOL, Safari, Opera browsers with
different versions.
OS Compatibility:
Some functionality in your web application is that it may not be
compatible with all operating systems. All new technologies used
in web development like graphic designs and interface calls like
different API’s may not be available in all Operating Systems.
Hence test your web application on different operating systems
like Windows, Unix, MAC, Linux, Solaris with different OS flavors.
Mobile Browsing:
We are in the new technology era. So in the future Mobile
browsing will rock. Test your web pages on mobile browsers.
Compatibility issues may be there on mobile devices as well.
Printing Options:
If you are giving page-printing options then make sure fonts,
page alignment, page graphics, etc., are getting printed properly.
Pages should fit the paper size or as per the size mentioned in
the printing option.

#5) Performance Testing

The web application should sustain a heavy load. Web performance testing
should include:

● Web Load Testing

● Web Stress Testing
Test application performance at different internet connection speeds.

Web Load Testing: You need to test if many users are

accessing or requesting the same page. Can the system sustain
peak load time? The site should handle many simultaneous user
requests, large input data from users, simultaneous connection to
DB, heavy load on specific pages, etc.
Web Stress Testing: Generally stress means stretching the
system beyond its specified limits. Web stress testing is
performed to break the site by giving stress and it’s checked as to
how the system reacts to stress and how it recovers from crashes.
Stress is generally given on input fields, login and sign up areas.
In web performance, testing website functionality on different
operating systems and different hardware platforms is checked
for software and hardware memory leakage errors.

Performance testing can be applied to understand the web site’s

scalability or to benchmark the performance in the environment
of third-party products such as servers and middleware for
potential purchase.

Connection Speed
Tested on various networks like Dial-Up, ISDN, etc.
Load
i. What is the no. of users per time?
ii. Check for peak loads and how the system behaves
iii. A large amount of data accessed by the user
Stress
i. Continuous Load
ii. Performance of memory, CPU, file handling, etc..
#6) Security Testing
The following are some of the test cases for web security testing:
● Test by pasting the internal URL directly into the browser
address bar without login. Internal pages should not
open.
 ● If you are logged in using username and password and
browsing internal pages, then try changing URL options
directly. I.e. If you are checking some publisher site statistics
with publisher site ID= 123. Try directly changing the URL
site ID parameter to a different site ID which is not related to
the logged-in user. Access should be denied for this user to
view other people’s stats.
● Try some invalid inputs in input fields like login
username, password, input text boxes, etc. Check the
system’s reaction to all invalid inputs.
● Web directories and files should not be accessible directly
unless they are given the download option.
● Test the CAPTCHA to automate script logins.
● Test if SSL is used for security measures. If used, the proper
message should get displayed when users switch from non-
secure HTTP:// pages to secure HTTPS:// pages and vice
versa.
● All transactions, error messages, and security breach
attempts should be logged in log files somewhere on
the webserver.
The primary reason for testing the security of a web is to
identify potential vulnerabilities and subsequently repair them.

● Network Scanning
● Vulnerability Scanning
● Password Cracking
● Log Review
● Integrity Checkers
 ● Virus Detection

Testing for S/W Security

Need for Security Testing

The software industry has achieved solid recognition in this age. In recent
decades, however, the
cyber-world seems to be an even more dominating and driving
force which is shaping up the new forms of almost every
business.

Web-based ERP systems used today are the best evidence that IT
has revolutionized our beloved global village. These days,
websites are not only meant for publicity or marketing but they
have evolved into stronger tools to cater to complete business
needs.
Web-based Payroll systems, Shopping Malls, Banking, and Stock
Trade applications are not only being used by organizations but
are also being sold as products today.

This means that online applications have gained the trust of

customers and users regarding their vital feature named
SECURITY. No doubt, that security factor is of primary value for
desktop applications too.

However, when we talk about the web, the importance of security

increases exponentially. If an online system cannot protect the
transaction data, then no one will ever think of using it. Security
is neither a word in search of its definition yet, nor a subtle
concept. However, we would like to list some compliments on
security.

Examples of Security flaws in an application

● A Student Management System is insecure if the
Admission branch can edit the data of the ‘Exam’
branch.
● An ERP system is not secure if a DEO (data entry operator) can
generate ‘Reports’.
● An online Shopping Mall has no security if the customer’s Credit Card
Details are not encrypted.
● A custom software possesses inadequate security if an SQL
query retrieves actual passwords of its users.
Security – Meaning
“Security means that authorized access is granted to
protected data and unauthorized access is restricted”.
So, it has two major aspects – first is the protection of data and
the second one is access to that data. Moreover, whether the
application is desktop or web-based, security revolves around the
two aforementioned aspects.

Security Testing is a type of Software Testing that uncovers

vulnerabilities of the system and determines that the data and
resources of the system are protected from possible intruders. It
ensures that the software system and application are free from
any threats or risks that can cause a loss. Security testing of any
system is focuses on finding all possible loopholes and
weaknesses of the system which might result into the loss of
information or repute of the organization.

Goal of Security Testing:

The goal of security testing is to:
● To identify the threats in the system.
● To measure the potential vulnerabilities of the system.
● To help in detecting every possible security risks in the system.
● To help developers in fixing the security problems through coding.
Principle of Security Testing:
Below are the six basic principles of security testing:
● Confidentiality
● Integrity
● Authentication
● Authorization
● Availability
● Non-repudiation
Major Focus Areas in Security Testing:
● Network Security
● System Software Security
● Client-side Application Security
● Server-side Application Security

Desktop And Web Security Testing

A desktop application should be secure not only regarding its
access but also with respect to the organization and storage of its
data.

Similarly, web applications demand, even more, security with

respect to its access, along with data protection. A web developer
should make the application immune to SQL Injections, Brute
Force Attacks and XSS (cross-site scripting). Similarly, if the web
application facilitates remote access points then these must be
secure too.

Also, keep in mind that Brute Force Attack is not only related to
web applications, but the desktop software is also vulnerable to
this.

List Of Top 8 Security

Testing Techniques #1)
Access to Application
Whether it is a desktop application or a website, access security
is implemented by “Roles and Rights Management”. It is
often done implicitly while covering functionality.
For Example, in a Hospital Management System, a receptionist
is least concerned about the laboratory tests as his job is to just
register the patients and schedule their appointments with
doctors.
So, all the menus, forms and screens related to lab tests will not
be available to the Role of ‘Receptionist’. Hence, the proper
implementation of roles and rights will guarantee the security of
access.

How to Test: In order to test this, thorough testing of all roles and rights
should be performed.
The tester should create several user accounts with different as
well as multiple roles. He should then be able to use the
application with the help of these accounts and should verify
that every role has access to its own modules, screens, forms,
and menus only. If the tester finds any conflict, then he should
log a security issue with complete confidence.
This can also be understood as authentication and

authorization testing which is very beautifully depicted in

the below image:
So, basically, you need to test about ‘who you are’ and ‘what you
can do’ for distinct users.Some of the authentication tests include
a test for password quality rules, test for default logins, test for
password recovery, test captcha, test for logout functionality, test
for password change, test for security question/answer, etc.

Similarly, some of the authorization tests include a test for path

traversal, test for missing authorization, test for horizontal
access control problems, etc.

#2) Data Protection

There are three aspects of data security. The first one is that a
user can view or utilize only the data which he is
supposed to use. This is also ensured by roles and rights
For Example, TSR (telesales representative) of a company
can view the data of available stock, but cannot see how much
raw material was purchased for production.
So, this aspect of security testing is already explained above. The
second aspect of data protection is related to how that data is
stored in the DB.

All sensitive data must be encrypted to make it secure.

Encryption should be strong, especially for sensitive data like
passwords of user accounts, credit card numbers or other
business-critical information.

The third and the last aspect is an extension of this second

aspect. Proper security measures must be adopted when the
flow of sensitive or business-critical data occurs. Whether this
data floats between different modules of the same application or
is transmitted to different applications, it must be encrypted to
keep it safe.

How to Test Data Protection: The tester should query the

database for ‘passwords’ of the user account, billing information
of clients, other business-critical and sensitive data, should verify
that all such data is saved in encrypted form in the DB.
Similarly, he must verify that the data is transmitted between
different forms or screens after proper encryption only. Moreover,
the tester should ensure that the encrypted data is properly
decrypted at the destination. Special attention should be paid to
different ‘submit’ actions.

The tester must verify that when the information is being

transmitted between the client and server, it is not displayed in
the address bar of a web browser in an understandable format. If
any of these verifications fail, then the application definitely has
a security flaw.

The tester should also check for proper use of salting (appending
an extra secret value to the end input like password and thus
making it stronger and more difficult to be cracked).Insecure
randomness should also be tested as it is a kind of vulnerability.
Another way to test data protection is to check for weak
algorithm usage.

For example, since HTTP is a clear text protocol, if sensitive

data like user credentials are transmitted via HTTP, then it is a
threat to application security. Instead of HTTP, sensitive data
should be transferred via HTTPS (secured through SSL and TLS
tunnels).
However, HTTPS increases the attack surface and thus it should
be tested that the server configurations are proper and
certificate validity is ensured.

#3) Brute-Force Attack

Brute Force Attack is mostly done by some software tools. The
concept is that by using a valid user ID, the software attempts
to guess the associated password by trying to log in
again and again.
A simple example of security against such an attack is account
suspension for a short period of time, as all mailing applications
like Yahoo, Gmail and Hotmail do. If a specific number of
consecutive attempts (mostly 3) fail to log in successfully, then
that account is blocked for some time (30 minutes to 24 hrs).

How to test Brute-Force Attack: The tester must verify that

some mechanism of account suspension is available and is
working accurately. (S)He must attempt to login with invalid user
IDs and Passwords alternatively to make sure that the software
application blocks the account if continuous attempts are made
to login with invalid credentials.
If the application is doing so, then it is secure against brute-force
attack. Otherwise, this security vulnerability must be reported by
the tester.

Testing for brute force can also be divided into two parts –
black box testing and grey-box testing.In Black box testing, the
authentication method employed by the application is
discovered and tested. Furthermore, the grey box testing is
based on partial knowledge of password & account details and
memory trade-off attacks.

4:URL manipulation attack is when someone alters the URL

content in the browser’s location bar in order to probe a website.
URLs are easy to manipulate and often follow a pattern, making
them ideal targets for hackers. Manipulation may be carried either
by unsuspecting users or by hackers looking for security flaws. By
altering a URL, individuals might
get access to confidential information or carry out operations that are
normally banned.
Changing the URL of a website might provide access to a secret page

#5) SQL Injection And XSS (Cross-Site Scripting)

Conceptually speaking, the theme of both these hacking attempts
is similar, hence these are discussed together. In this approach,
the malicious script is used by hackers in order to
manipulate a website. There are several ways to immune
against such attempts. For all input fields on the website, field
lengths should be defined small enough to restrict the input of
any script

For example, the Last Name should have a field length of 30

instead of 255. There may be some input fields where large data
input is necessary, for such fields proper validation of input
should be performed prior to saving that data in the application.
Moreover, in such fields, any HTML tags or script tag input must
be prohibited. In order to provoke XSS attacks, the application
should discard script redirects from unknown or untrusted
applications.

Cross-site scripting (XSS) is an attack in which an attacker

injects malicious executable scripts into the code of a trusted
application or website. Attackers often initiate an XSS attack by
sending a malicious link to a user and enticing the user to click it.

XSS enables an attacker to execute malicious scripts in another

user's browser. However, instead of attacking the victim directly,
the attacker exploits a vulnerability in a website the victim visits
and gets the website to deliver the malicious script.

How to test SQL Injection and XSS: Tester must ensure that
maximum lengths of all input fields are defined and implemented.
(S)He should also ensure that the defined length of input fields
does not accommodate any script input as well as tag input. Both
of these can be easily tested.

For Example, If 20 is the maximum length specified for the ‘Name’ field,
and input string “<p>thequickbrownfoxjumpsoverthelazydog” can verify
both these constraints.
It should also be verified by the tester that the application does
not support anonymous access methods. If any of these
vulnerabilities exist, then the application is in danger.

#6) Session Management:

A web session is a sequence of HTTP requests and response
transactions linked to the same user. Session management tests
check how session management is handled in the web app.You
can test for session expiry after particular idle time, session
termination after maximum lifetime, session termination after log
out, check for session cookie scope and duration, testing if a
single user can have multiple simultaneous sessions, etc.
#7) Error handling: Testing for Error handling includes:
Check for error codes: For example, test 408 request time-
out, 400 bad requests, 404 not found, etc. To test this, you need
to make certain requests on the page such that these error codes
are returned.
The error code will be returned with a detailed message. This
message should not contain any critical information that can be
used for hacking purposes.

Check for stack traces: It basically includes giving some

exceptional input to the application such that the returned error
message contains stack traces that have interesting information
for hackers.
8) Privilege elevation refers to a network attack aiming to gain
unauthorized higher-level access within a security system. It
typically starts with attackers exploiting vulnerabilities to access a
system with limited privileges.

The attackers then elevate their access rights to gain control over
more sensitive systems or data. Common reasons for successful
privilege escalation include insufficient security controls, non-
adherence to the principle of least privilege, and exploitable software
vulnerabilities. This can lead to either external threat actors or
insiders gaining undue access.
9) Specific Risky Functionalities
Mainly, the two risky functionalities are payments and file
uploads. These functionalities should be tested very well. For file
uploads, you need to primarily test if any unwanted or malicious
file upload is restricted.
For payments, you need to primarily test for injection
vulnerabilities, insecure cryptographic storage, buffer overflows,
password guessing, etc.
Stubs Driver