SOFTWARE TESTING

UNIT-I [12 Hours]

Introduction: Basic definitions, A testing life cycle, Test Cases, Fundamental

approaches to apply Test Cases, Levels of Testing, Examples: TheNextDate
function, Triangle problem and The Commission Problem and The SATM
(Simple Automatic Teller Machine) problem.
Boundary Value Testing: Generalizing Boundary Value Analysis,
Limitations of Boundary Value Analysis, Robustness Testing, Worst-Case
Testing, Special Value Testing, Test cases for the Triangle problem, Test
cases for the NextDate function, Test cases for the Commission Problem,
Random Testing and Guidelines for Boundary Value Testing.

UNIT – 1
What is Software Testing ?

Software testing is a process, to evaluate the functionality of a software application

with an intent to find whether the developed software met the specified
requirements or not and to identify the defects to ensure that the product is defect-
free in order to produce the quality product.

Definition:
Software Testing Definition according to ANSI/IEEE 1059 standard – A process
of analyzing a software item to detect the differences between existing and required
conditions (i.e., defects) and to evaluate the features of the software item.

Software Testing Types:

Manual Testing: Manual testing is the process of testing software by hand to learn
more about it, to find what is and isn’t working. This usually includes verifying all
the features specified in requirements documents, but often also includes the testers
trying the software with the perspective of their end user’s in mind. Manual test plans
vary from fully scripted test cases, giving testers detailed steps and expected results,
through to high-level guides that steer exploratory testing sessions. There are lots of
sophisticated tools on the market to help with manual testing, but if you want a
simple and flexible place to start, take a look at Testpad.
Automation Testing: Automation testing is the process of testing the software using
an automation tool to find the defects. In this process, testers execute the test scripts
and generate the test results automatically by using automation tools. Some of the
famous automation testing tools for functional testing are QTP/UFT and Selenium.

Testing Methods:
1. Static Testing
2. Dynamic Testing
Static Testing: It is also known as Verification in Software Testing. Verification is a
static method of checking documents and files. Verification is the process, to ensure
that whether we are building the product right i.e., to verify the requirements which
we have and to verify whether we are developing the product accordingly or not.
Activities involved here are Inspections, Reviews, Walkthroughs

Dynamic Testing: It is also known as Validation in Software Testing. Validation is

a dynamic process of testing the real product. Validation is the process, whether we
are building the right product i.e., to validate the product which we have developed
is right or not.

Testing Approaches:
There are three types of software testing approaches.

1. White Box Testing

2. Black Box Testing
3. Grey Box Testing

• White Box Testing: It is also called as Glass Box, Clear Box, Structural
Testing. White Box Testing is based on application’s internal code structure.
In white-box testing, an internal perspective of the system, as well as
programming skills, are used to design test cases. This testing is usually done
at the unit level.
• Black Box Testing: It is also called as Behavioral/SpecificationBased/Input-
Output Testing. Black Box Testing is a software testing method in which
testers evaluate the functionality of the software under test without looking at
the internal code structure.
• Grey Box Testing: Grey box is the combination of both White Box and Black
Box Testing. The tester who works on this type of testing needs to have access
to design documents. This helps to create better test cases in this process.

Testing Levels:
1. Unit Testing
 2. Integration Testing
3. System Testing
4. Acceptance Testing

• Unit Testing: Unit Testing is done to check whether the individual modules
of the source code are working properly. i.e. testing each and every unit of the
application separately by the developer in the developer’s environment.
It is AKA Module Testing or Component Testing. To learn about Unit Testing,
check out our detailed Unit Testing Guide
• Integration Testing: Integration Testing is the process of testing the
connectivity or data transfer between a couple of unit tested modules. It is
AKA I&T Testing or String Testing. It is subdivided into the Top-Down
Approach, Bottom-Up Approach, and Sandwich Approach (Combination of
Top-Down and Bottom-Up). To learn about Integration Testing, check out our
detailed Integration Testing Guide
• System Testing (end to end testing): It’s a black box testing. Testing the fully
integrated application this is also called as an end to end scenario testing. To
ensure that the software works in all intended target systems. Verify thorough
testing of every input in the application to check for desired outputs. Testing
of the user’s experiences with the application.
• Acceptance Testing: To obtain customer sign-off so that software can be
delivered and payments received. Types of Acceptance Testing are Alpha,
Beta & Gamma Testing.

Types of Black Box Testing:

1. Functionality Testing
2. Non-functionality Testing

• Functional testing: In simple words, what the system actually does is

functional testing. To verify that each function of the software application
behaves as specified in the requirement document. Testing all the
functionalities by providing appropriate input to verify whether the actual
output is matching the expected output or not. It falls within the scope of
black-box testing and the testers need not concern about the source code of
the application.

• Non-functional testing: In simple words, how well the system performs is

non-functionality testing. Non-functional testing refers to various aspects of
the software such as performance, load, stress, scalability, security,
 compatibility, etc., The Main focus is to improve the user experience on how
fast the system responds to a request.

Testing Artifacts:
Test Artifacts are the deliverables that are given to the stakeholders of a software
project. A software project which follows SDLC undergoes the different phases
before delivering to the customer. In this process, there will be some deliverables in
every phase. Some of the deliverables are provided before the testing phase
commences and some are provided during the testing phase and rest after the testing
phase is completed.

Some of the test deliverables are as follows:

• Test plan
• Traceability matrix
• Test case
• Test script
• Test suite
• Test data or Test Fixture
• Test harness

Some of the reasons why software testing becomes a very significant and integral
part in the field of information technology are as follows.
1. Cost-effectiveness
2. Customer Satisfaction
3. Security
4. Product Quality

1. Cost-effectiveness
As a matter of fact, design defects can never be completely ruled out for any complex
system. It is not because developers are careless but because the complexity of a
system is intractable. If the design issues go undetected, then it will become more
difficult to trace back defects and rectify it. It will become more expensive to fix it.
Sometimes, while fixing one bug we may introduce another one in some other
module unknowingly. If the bugs can be identified in the early stages of development
then it costs much less to fix them. That is why it is important to find defects in the
early stages of the software development life cycle. One of the benefits of testing is
cost-effectiveness.

It is better to start testing earlier and introduce it in every phase of the software
development life cycle and regular testing is needed to ensure that the application is
developed as per the requirement.

2. Customer Satisfaction
In any business, the ultimate goal is to give the best customer satisfaction. Yes,
customer satisfaction is very important. Software testing improves the user
experience of an application and gives satisfaction to the customers. Happy
customers mean more revenue for a business. One of the reasons why software
testing is necessary is to provide the best user experience.

3. Security
This is probably the most sensitive and vulnerable part of software testing. Testing
(penetration testing & security testing) helps in product security. Hackers gain
unauthorized access to data. These hackers steal user information and use it for their
benefit. If your product is not secured, users won’t prefer your product. Users always
look for trusted products. Testing helps in removing vulnerabilities in the product.

4. Product Quality
Software Testing is an art that helps in strengthening the market reputation of a
company by delivering the quality product to the client as mentioned in the
requirement specification documents.

Principles of Software Testing:

Testing of software consists of some principles that play a vital role while testing the
project.

The Principles of Software Testing are as follows :

1. Testing shows the presence of defects
2. Exhaustive testing is impossible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is context-dependent
 7. Absence of error

Difference between Defect, Error, Bug, Failure and Fault :

Testing is the process of identifying defects, where a defect is any variance between
actual and expected results. “A mistake in coding is called Error, error found by tester
is called Defect, defect accepted by development team then it is called Bug, build
does not meet the requirements then it Is Failure.”
DEFECT: It can be simply defined as a variance between expected and actual.
Defect is an error found AFTER the application goes into production. It commonly
refers to several troubles with the software products, with its external behavior or
with its internal features. In other words Defect is the difference between expected
and actual result in the context of testing. It is the deviation of the customer
requirement.

Defect can be categorized into the following:

Wrong: When requirements are implemented not in the right way. This defect is a
variance from the given specification. It is Wrong!

Missing: A requirement of the customer that was not fulfilled. This is a variance
from the specifications, an indication that a specification was not implemented, or a
requirement of the customer was not noted correctly.

Extra: A requirement incorporated into the product that was not given by the end
customer. This is always a variance from the specification, but may be an attribute
desired by the user of the product. However, it is considered a defect because it’s a
variance from the existing requirements.
ERROR: An error is a mistake, misconception, or misunderstanding on the part of
a software developer. In the category of developer we include software engineers,
programmers, analysts, and testers. For example, a developer may misunderstand a
de-sign notation, or a programmer might type a variable name incorrectly – leads to
an Error. It is the one which is generated because of wrong login, loop or due to
syntax. Error normally arises in software; it leads to change the functionality of the
program.
BUG: A bug is the result of a coding error. An Error found in the development
environment before the product is shipped to the customer. A programming error that
causes a program to work poorly, produce incorrect results or crash. An error in
software or hardware that causes a program to malfunction. Bug is terminology of
Tester.
FAILURE: A failure is the inability of a software system or component to perform
its required functions within specified performance requirements. When a defect
reaches the end customer it is called a Failure. During development Failures are
usually observed by testers.
FAULT: An incorrect step, process or data definition in a computer program which
causes the program to perform in an unintended or unanticipated manner. A fault is
introduced into the software as the result of an error. It is an anomaly in the software
that may cause it to behave incorrectly, and not according to its specification. It is
the result of the error.

Software Testing Fundamentals

Different types of Software Testing processes are described below:

• Unit Testing
It is a method by which individual units of source code are tested to determine
if they are fit for use.
• Integration Testing
Here individual software modules are combined and tested as a group.
• Functionality Testing
It is a type of black box testing that bases its test cases on the specifications
of the software component under test. • Usability Testing
It is a technique used to evaluate a product by testing it on users.
• System Testing
It is testing conducted on a complete, integrated system to evaluate the
system’s compliance with its specified requirements.
• Performance Testing
It is testing that is performed, to determine how fast some aspect of a system
performs under a particular workload.
 • Load Testing
It refers to the practice of modeling the expected usage of a software program
by simulating multiple users accessing the program concurrently.
• Stress Testing
It is a form of testing that is used to determine the stability of a given system
or entity.

Debugging :
In the context of software engineering, debugging is the process of fixing a bug in
the software. In other words, it refers to identifying, analyzing and removing errors.
This activity begins after the software fails to execute properly and concludes by
solving the problem and successfully testing the software. It is considered to be an
extremely complex and tedious task because errors need to be resolved at all stages
of debugging.
Debugging Process: Steps involved in debugging are:
• Problem identification and report preparation.
• Assigning the report to software engineer to the defect to verify that it is genuine.
• Defect Analysis using modeling, documentations, finding and testing candidate flaws, etc.
• Defect Resolution by making required changes to the system.
• Validation of corrections.
Debugging Strategies:
1. Study the system for the larger duration in order to understand the system. It
helps debugger to construct different representations of systems to be
debugging depends on the need. Study of the system is also done actively to
find recent changes made to the software.
2. Backwards analysis of the problem which involves tracing the program
backward from the location of failure message in order to identify the region of
faulty code. A detailed study of the region is conducting to find the cause of
defects.
3. Forward analysis of the program involves tracing the program forwards using
breakpoints or print statements at different points in the program and studying
the results. The region where the wrong outputs are obtained is the region that
needs to be focused to find the defect.
 4. Using the past experience of the software debug the software with similar
problems in nature. The success of this approach depends on the expertise of
the debugger.
Debugging Tools:
Debugging tool is a computer program that is used to test and debug other
programs. A lot of public domain software like gdb and dbx are available for
debugging. They offer console-based command line interfaces. Examples of
automated debugging tools include code based tracers, profilers, interpreters, etc.
Some of the widely used debuggers are:
• Radare2
• WinDbg
• Valgrind
Difference Between Debugging and Testing:
Debugging is different from testing. Testing focuses on finding bugs, errors, etc
whereas debugging starts after a bug has been identified in the software. Testing is
used to ensure that the program is correct and it was supposed to do with a certain
minimum success rate. Testing can be manual or automated. There are several
different types of testing like unit testing, integration testing, alpha and beta testing,
etc.
Debugging requires a lot of knowledge, skills, and expertise. It can be supported by
some automated tools available but is more of a manual process as every bug is
different and requires a different technique, unlike a pre-defined testing
mechanism.

White Box Testing

WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing,
Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural
Testing) is a software testing method in which the internal
structure/design/implementation of the item being tested is known to the tester. The
tester chooses inputs to exercise paths through the code and determines the
appropriate outputs. Programming know-how and the implementation knowledge is
essential. White box testing is testing beyond the user interface and into the nitty-
gritty of a system.
This method is named so because the software program, in the eyes of the tester, is
like a white/transparent box; inside which one clearly sees.

• White-box testing: Testing based on an analysis of the internal structure of

the component or system.
• White-box test design technique: Procedure to derive and/or select test cases
based on an analysis of the internal structure of a component or system.
Example
A tester, usually a developer as well, studies the implementation code of a certain
field on a webpage, determines all legal (valid and invalid) AND illegal inputs and
verifies the outputs against the expected outcomes, which is also determined by
studying the implementation code.
White Box Testing is like the work of a mechanic who examines the engine to see
why the car is not moving.

White Box Testing method is applicable to the following levels of software testing:
• Unit Testing: For testing paths within a unit.
• Integration Testing: For testing paths between units.
• System Testing: For testing paths between subsystems.

However, it is mainly applied to Unit Testing.

Advantages

• Testing can be commenced at an earlier stage. One need not wait for the GUI
to be available.
• Testing is more thorough, with the possibility of covering most paths.

Disadvantages

•Since tests can be very complex, highly skilled resources are required, with a
thorough knowledge of programming and implementation.
• Test script maintenance can be a burden if the implementation changes too
frequently.
• Since this method of testing is closely tied to the application being tested, tools
to cater to every kind of implementation/platform may not be readily
available.
BLACK BOX TESTING

BLACK BOX TESTING, also known as Behavioral Testing, is a software testing

method in which the internal structure/design/implementation of the item being
tested is not known to the tester. These tests can be functional or non-functional,
though usually functional.
This method is named so because the software program, in the eyes of the tester, is
like a black box; inside which one cannot see. This method attempts to find errors in
the following categories:
• Incorrect or missing functions
• Interface errors
• Errors in data structures or external database access
• Behavior or performance errors
• Initialization and termination errors

Black box testing: Testing, either functional or non-functional, without

reference to the internal structure of the component or system.

Black box test design technique: Procedure to derive and/or select test cases
based on an analysis of the specification, either functional or nonfunctional,
of a component or system without reference to its internal structure.

Example
A tester, without knowledge of the internal structures of a website, tests the web
pages by using a browser; providing inputs (clicks, keystrokes) and verifying the
outputs against the expected outcome.
Black Box Testing method is applicable to the following levels of software testing:

• Integration Testing
• System Testing
• Acceptance Testing

The higher the level, and hence the bigger and more complex the box, the more
black-box testing method comes into use.

Techniques
Following are some techniques that can be used for designing black box tests.

• Equivalence Partitioning: It is a software test design technique that involves

dividing input values into valid and invalid partitions and selecting
representative values from each partition as test data.
 • Boundary Value Analysis: It is a software test design technique that involves
the determination of boundaries for input values and selecting values that are
at the boundaries and just inside/ outside of the boundaries as test data.
• Cause-Effect Graphing: It is a software test design technique that involves
identifying the cases (input conditions) and effects (output conditions),
producing a Cause-Effect Graph, and generating test cases accordingly.

Advantages

• Tests are done from a user’s point of view and will help in exposing
discrepancies in the specifications.
• Tester need not know programming languages or how the software has been
implemented.
• Tests can be conducted by a body independent from the developers, allowing
for an objective perspective and the avoidance of developer-bias.
• Test cases can be designed as soon as the specifications are complete.

Disadvantages

• Only a small number of possible inputs can be tested and many program paths
will be left untested.
• Without clear specifications, which is the situation in many projects, test cases
will be difficult to design.
• Tests can be redundant if the software designer/developer has already run a
test case.

Gray Box Testing

GRAY BOX TESTING is a software testing method which is a combination of
Black Box Testing method and White Box Testing method. In Black Box Testing,
the internal structure of the item being tested is unknown to the tester and in White
Box Testing the internal structure is known. In Gray Box Testing, the internal
structure is partially known. This involves having access to internal data structures
and algorithms for purposes of designing the test cases, but testing at the user, or
black-box level.
Gray Box Testing is named so because the software program, in the eyes of the tester
is like a gray/semi-transparent box; inside which one can partially see.
Example
An example of Gray Box Testing would be when the codes for two units/modules
are studied (White Box Testing method) for designing test cases and actual tests are
conducted using the exposed interfaces (Black Box Testing method).

Unit Testing
Unit Testing is a software testing technique by means of which individual units of
software i.e. group of computer program modules, usage procedures and operating
procedures are tested to determine whether they are suitable for use or not. It is a
testing method using which every independent modules are tested to determine if
there are any issue by the developer himself. It is correlated with functional
correctness of the independent modules.
Unit Testing is defined as a type of software testing where individual components of
a software are tested.
Unit Testing of software product is carried out during the development of an
application. An individual component may be either an individual function or a
procedure. Unit Testing is typically performed by the developer.
In SDLC or V Model, Unit testing is first level of testing done before integration
testing. Unit testing is such type of testing technique that is usually performed by the
developers. Although due to reluctance of developers to tests, quality assurance
engineers also do unit testing.

Objective of Unit Testing:

The objective of Unit Testing is:
1. To isolate a section of code.
2. To verify the correctness of code.
3. To test every function and procedure.
4. To fix bug early in development cycle and to save costs.
5. To help the developers to understand the code base and enable them to make
changes quickly.
6. To help for code reuse.
Types of Unit Testing:
There are 2 type of Unit Testing: Manual, and Automated.

Workflow of Unit Testing:

Unit Testing Tools:
Here are some commonly used Unit Testing tools:
1. Jtest
2. Junit
3. NUnit
4. EMMA
5. PHPUnit
Advantages of Unit Testing:
• Unit Testing allows developers to learn what functionality is provided by a unit
and how to use it to gain a basic understanding of the unit API.
• Unit testing allows the programmer to refine code and make sure the module
works properly.

Integration testing
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/modules.

We normally do Integration testing after “Unit testing”. Once all the individual units
are created and tested, we start combining those “Unit Tested” modules and start
doing the integrated testing.

The main function or goal of this testing is to test the interfaces between the
units/modules.
The individual modules are first tested in isolation. 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?
We feel that Integration testing is complex and requires some development and
logical skill. That’s true! Then what is the purpose of integrating this testing into our
testing strategy?

Some reasons:
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 :
• 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.
In order to minimize the impact while developing a system, few things should be
taken into consideration like possible integration with other systems, etc.

Types of Integration Testing :

Big Bang Approach :
Big bang approach integrates all the modules in one go i.e. it does not go for
integrating the modules one by one. It verifies if the system works as expected or not
once integrated. If any issue is detected in the completely integrated module, then it
becomes difficult to find out which module has caused the issue.
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.
Integration Testing Steps:
1. Prepare Integration Test Plan.
2. Prepare integration test scenarios & test cases.
3. Prepare test automation scripts.
4. Execute test cases.
5. Report the defects.
6. Track and re-test the defects.
7. Re-testing & testing goes on until integration testing is complete.
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.
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
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 bottomup
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.

Since both the approach starts simultaneously, this technique is a bit complex and
requires more people along with specific skill sets and thus adds to the cost.

GUI application Integration Test

Now let’s talk about how we can imply integration testing in Black box technique.
We all understand that a web application is a multitier application. We have a front
end which is visible to the user, we have a middle layer which has business logic, we
have some more middle layer which does some validations, integrate some third
party APIs etc., then we have the back layer which is the database.

Integration testing example:

Let’s check the below example:
I am the owner of an advertising company and I post ads on different websites. At
the end of the month, I want to see how many people saw my ads and how many
people clicked on my ads. I need a report for my ads displayed and I charge
accordingly to my clients.

GenNext software developed this product for me and below was the architecture:

UI – User Interface module, which is visible to the end user, where all the inputs are
given.
BL – Is the Business Logic module, which has all the all the calculations and
business specific methods.
VAL – Is the Validation module, which has all the validations of the correctness of
the input.
CNT – Is the content module which has all the static contents, specific to the inputs
entered by the user. These contents are displayed in the reports.
EN – Is the Engine module, this module reads all the data that comes from BL,
VAL and CNT module and extracts the SQL query and triggers it to the database.
Scheduler – Is a module which schedules all the reports based on the user
selection (monthly, quarterly, semiannually & annually) DB – Is the Database.
Now, having seen the architecture of the entire web application, as a single unit,
Integration testing, in this case, will focus on the flow of data between the modules.

Steps to Kick off Integration Tests

1. Understand the architecture of your application.
2. Identify the modules
3. Understand what each module does
4. Understand how the data is transferred from one module to another.
5. Understand how the data is entered and received into the system ( entry point
and exit point of the application)
6. Segregate the application to suit your testing needs.
7. Identify and create the test conditions
8. Take one condition at a time and write down the test cases.

Entry/Exit Criteria for Integration Testing Entry

Criteria:
• Integration test plan document is signed off and approved.
• Integration test cases have been prepared.
• Test data has been created.
• Unit testing of developed modules/Components is complete.
• All the critical and high Priority defects are closed.
• The test environment is set up for integration. Exit Criteria:
• All the integration test cases have been executed.
• No critical and Priority P1 & P2 defects are opened.
• Test Report has been prepared.

Integration Test Cases

Integration test cases focus mainly on the interface between the modules,
integrated links, data transfer between the modules as modules/components that
are already unit tested i.e. the functionality and the other testing aspects have already
been covered.
So, the main idea is to test if integrating two working modules works as expected
when integrated.
For Example Integration Test cases for Linkedin application will include:
• Verifying the interface link between the login page and the home page i.e.
when a user enters the credentials and logs it should be directed to the
homepage.
• Verifying the interface link between the home page and the profile page i.e.
profile page should open up.
• Verify the interface link between the network page and your connection pages
i.e. clicking accept button on Invitations of the network page should show the
accepted invitation in your connection page once clicked.
• Verify the interface link between the Notification pages and say congrats
button i.e. clicking say congrats button should direct towards the new message
window.
Many integration test cases can be written for this specific site. The above four points
are just an example to understand what Integration test cases are included in testing.

Is Integration a White box or Black box Technique?

Integration testing technique can be counted in both black boxes as well as white box
technique. Black box technique is where a tester need not have any internal
knowledge of the system i.e. coding knowledge is not required whereas white box
technique needs internal knowledge of the application.
Now while performing integration testing it could include testing the two integrated
web services which will fetch the data from the database & provide the data as
required which means it could be tested using white box testing technique whereas
integrating a new feature in the website can be tested using the black box technique.

So, it’s not specific that integration testing is a black box or white box technique.

Integration Testing Tools

There are several tools available for this testing.

Given below is a list of tools:

• Rational Integration Tester
• Protractor
• Steam
• TESSY
For more details on the above tools check this tutorial:
System Integration Testing
System Integration Test is done to test the complete integrated system.
Modules or components are tested individually in unit testing before integrating the
components.

Once all the modules are tested, system integration testing is done by integrating all
the modules and the system as a whole is tested.

Difference between Integration Testing & System Testing

Integration testing is a testing in which one or two modules which are unit tested are
integrated to test and verification is done to verify if the integrated modules work as
expected or not.

System testing is a testing where the system as a whole is tested i.e. all the
modules/components are integrated together to verify whether the system works as
expected and no issues occur because of the integrated modules.

Test Environment for Software Testing

A testing environment is a setup of software and hardware for the testing teams to
execute test cases. In other words, it supports test execution with hardware, software
and network configured.

Test bed or test environment is configured as per the need of the Application Under
Test. On a few occasion, test bed could be the combination of the test environment
and the test data it operates.

For the test environment, a key area to set up includes

• System and applications

• Test data
• Database server
• Front-end running environment
• Client operating system
• Browser
• Hardware includes Server Operating system
• Network
• Documentation required like reference
documents/configuration guides/installation guides/ user manuals

Process of Software Test environment setup

Tests are limited to what can be tested and what not should be tested.

Following people are involved in test environment setup

• System Admins,
• Developers
• Testers
• Sometimes users or techies with an affinity for testing.
The test environment requires setting up of various number of distinct areas like,
Setup of Test Server

Every test may not be executed on a local machine. It may need establishing a test
server, which can support applications.

For example, Fedora set up for PHP, Java-based applications with or without mail
servers, cron set up, Java-based applications, etc.

Network

Network set up as per the test requirement. It includes,

• Internet setup
• LAN Wifi setup
• Private network setup

It ensures that the congestion that occurs during testing doesn't affect other members.
(Developers, designers, content writers, etc.)

Test PC setup

For web testing, you may need to set up different browsers for different testers. For
desktop applications, you need various types of OS for different testers PCs.

For example, windows phone app testing may require

• Visual Studio installation

• Windows phone emulator
• Alternatively, assigning a windows phone to the tester.

Bug Reporting

Bug reporting tools should be provided to testers.

Creating Test Data for the Test Environment

Many companies use a separate test environment to test the software product. The
common approach used is to copy production data to test. This helps the tester, to
detect the same issues as a live production server, without corrupting the production
data.
The approach for copying production data to test data includes,

• Set up production jobs to copy the data to a common test environment

• All PII (Personally Identifiable Information) is modified along with other
sensitive data. The PII is replaced with logically correct, but non-personal
data.
• Remove data that is irrelevant to your test.

Testers or developers can copy this to their individual test environment. They can
modify it as per their requirement.

Privacy is the main issue in copy production data. To overcome privacy issues you
should look into obfuscated and anonymized test data.

For Anonymization of data two approaches can be used,

• BlackList: In this approach, all the data fields are left unchanged. Except those
fields specified by the users.
• WhiteList: By default, this approach, anonymizes all data fields. Except for a
list of fields which are allowed to be copied. A whitelisted field implies that it
is okay to copy the data as it is and anonymization is not required.

Also, if you are using production data, you need to be smart about how to source
data. Querying the database using SQL script is an effective approach.

Test Environment Management

Test Environment Management deals with the maintenance and upkeep of the test bed.

List of activities by the Test environment management function include,Maintenance of a

central repository with all the updated version of test environments.
1. Test environment management as per the test team demands.
2. As per the new requirements creating new environments
3. Monitoring of the environments
4. Updating/deleting outdated test-environments 6. Investigation of issues on the
environment
7. Co-ordination till an issue resolution.
Besides these, there are a few more questions to answer before setting up the test
environment.

• Whether to develop an internal Test Environment or to outsource?

• Whether to follow an internal company standard or follow any External (IEE,
ISO, etc.)?
• How long the test environment is required?
• Differences between the test and production systems and their impact on test
validity must be determined.
• Can you re-use an existing setup for other projects in the company?

Challenges in setting up Test Environment Management :

1. Proper planning on resource usage

Ineffective planning for resource usage can affect the actual output. Also, it
may lead to conflict between teams.

2. Remote environment

It is possible that a Test environment is located geographically apart. In such

a case, the testing team has to rely on the support team for various test assets.
(Software, hardware, and other issues).

3. Elaborate setup time

Sometimes test set up gets too elaborated in cases of Integration Testing.

4. Shared usage by teams

If the testing environment is used by development & testing team

simultaneously, test results will be corrupted.

5. Complex test configuration

Certain test requires complex test environment configuration. It may pose a

challenge to the test team.
Summary:
• A testing environment is a setup of software and hardware on which the test
team will conduct the testing
• For the test environment, a key area to set up includes o System and
applications

o Test data o Database server o Front-end running

environment, etc.
• Few challenges while setting up a test environment include, o Remote
environment o Combined usage between teams
o Elaborate setup time
o Ineffective planning for resource usage for integration o
Complex test configuration

Client-Server And Web Based Testing

CLIENT / SERVER TESTING

This type of testing usually done for 2 tier applications (usually developed for LAN).
Here we will be having Front-end and Backend.

The application launched on front-end will be having forms and reports which will
be monitoring and manipulating data

For Example, applications developed in VB, VC++, Core Java, C, C++, D2K,
PowerBuilder, etc., The backend for these applications would be MS Access, SQL
Server, Oracle, Sybase, Mysql, Quadbase
The tests performed on these types of applications would be
• User Interface Testing
• Manual Support Testing
• Functionality Testing
• Compatibility Testing & Configuration Testing
• Intersystem Testing
WEB TESTING :

This is done for 3 tier applications (developed for Internet / intranet / xtranet) Here
we will be having Browser, web server and DB server.
The applications accessible in the browser would be developed in HTML, DHTML,
XML, JavaScript, etc. (We can monitor through these applications)
Applications for the webserver would be developed in Java, ASP, JSP, VBScript,
JavaScript, Perl, Cold Fusion, PHP, etc. (All the manipulations are done on the
webserver with the help of these programs developed)
The DB server would be having Oracle, SQL Server, Sybase, MySQL, etc. (All data
is stored in the database available on the DB server)

The tests performed on these types of applications would be

• User Interface Testing
• Functionality Testing
• Security Testing
• Browser Compatibility Testing
• Load/Stress Testing
• Interoperability Testing/Intersystem Testing
• Storage and Data Volume Testing
A Web Application is a Three-Tier Application
This has a browser (monitors data) [monitoring is done using HTML, Dhtml, XML,
javascript]-> webserver (manipulates data) [manipulations are done using
programming languages or scripts like adv java, asp, JSP, VBScript, javascript, Perl,
ColdFusion, php] -> database server (stores data) [data storage and retrieval is done
using databases like Oracle, SQL Server, Sybase, mysql].

The types of tests, which can be applied to this type of applications, are
• User Interface Testing for validation & user-friendliness
• Functionality Testing to validate behaviors, i/p, error handling, o/p,
manipulations, services levels, the order of functionality, links, content of web
page & backend coverage’s
• Security Testing
• Browser Compatibility
• Load/Stress Testing
• Interoperability Testing
• Storage & Data Volume Testing
A Client-Server Application is a Two-Tier Application
This has forms & reporting at front-end (monitoring & manipulations are done)
[using vb, vc++, core java, c, c++, d2k, power builder etc.,] -> database server at the
backend [data storage & retrieval) [using ms access, SQL Server, Oracle, Sybase,
MySQL, quad base etc.,]
The tests performed on these applications would be
• User Interface testing
• Manual Support Testing
• Functionality Testing
• Compatibility Testing
• Intersystem Testing
Some more points to clear the difference between Client-Server, Web and Desktop
applications:
Desktop Application:
• Application runs in single memory (Front end and Back end in one place)
• Single user only Client/Server Application:
• Application runs in two or more machines
• Application is a menu-driven
• Connected mode (connection exists always until logout)
• A limited number of users
• Less number of network issues when compared to the web app.
Web Application:
• Application runs in two or more machines
• URL-driven
• Disconnected mode (stateless)
• Unlimited number of users
• Many issues like Hardware Compatibility, Browser Compatibility, Version
Compatibility, Security Issues, performance issues, etc.
As per difference in both, the applications come where, how to access the resources.
In Client-Server, once the connection is made it will be in the state on connected,
whereas in case of web testing HTTP protocol is stateless, then there comes logic of
cookies, which is not in Client-Server.

For Client-Server application users are well known, whereas for web application any
user can log in and access the content, he/she will use it as per his intentions.
 TESTING DOCUMENTATION
Documentation as part of process
Testing documentation is usually associated with the documentation of artifacts that
should be developed before or during the testing of software.

Testing Documentation is an important part of the testing process.

Documentation for software testing is necessary for evaluating the testing effort
needed, requirement tracking/tracing, test coverage etc.

Further are described commonly used documented artifacts

concerning software testing:

• Test Plan.
• Test Case.
• Test Scenario.

Test plan outlines the common strategy that will be applied to test an application.
• Traceability [Link] PlanA Test plan outlines the common strategy that will be applied to test an
application, the resources that will be used, the test environment in which testing will be performed, and the
schedule of testing activities along with the limitations. Typically writing a Test Plan is the competence of the
Quality Assurance Team Lead.
A test plan includes the following:
• Introduction to the Test Plan document.
• Assumptions while testing the application.
• Approaches to be used while testing the software/application.
• List of test cases used during the testing process.
• Enumeration of features to be tested.
• List of deliverables to be tested.
• The resources allocated for testing the application.
• A schedule of tasks and milestones to be reached.
 • Possible risks involved during the testing process.
Test Case

Test case is a complexity of inputs, serious of steps, and conditions that can be used
during the process of testing. The key point of this activity is to find out whether a
software is successful in terms of its functionality and other aspects. There are
various types of test cases such as logical, functional, error, negative test cases,
physical test cases, UI test cases, etc.

What's more, test cases are written to keep track of the software testing coverage.
Basically, there are no formal templates that can be used while writing a test case.

Test case is a complexity of inputs, serious of steps, and conditions that can be used
during the process of testing.
The following components are commonly accepted:

• Test case ID.

• Product module.
• Product version.
• Revision history.
• Purpose.
• Assumptions.
• Pre-conditions.
• Steps.
• Expected outcome.
• Actual outcome.
• Post-conditions.

A single test scenario can be applied to many test cases. In addition, sometimes
numerous test cases are written for a single software which are collectively known
as test suites.

Test Step – is the smallest unit of testing. This is the minimum action which is done
by a tester during testing. As an example, a good test scenario is the wish to brush
your teeth. Rather simple and clear wish, I may say. The test case can be performed
by the process of squeezing a toothpaste from the tube. This process can easily be
divided into smaller steps, such as: taking the tube, unscrewing the cap, pressing it
until there is enough toothpaste etc.
Test Step – is the smallest unit of testing.

Test Scenario

Test Scenario - it is a one line statement which purpose is to inform what particular
area in the application will be tested. Test scenarios are used to ensure that all process
flows are thoroughly tested. For a particular area of an application a single test
scenario may be enough, and for others the number may go up to a few hundred
scenarios depending on the significance and complexity of the application.

Test scenarios are used to ensure that all process flows are thoroughly tested.
The terms 'test scenario' and 'test cases' are sometimes used interchangeably,
however a test scenario usually consists of several steps, whereas a test case has a
single step. Taking this into account, test scenarios are test cases, but they include
several test cases and the sequence that they should be executed. Moreover, each test
relies on the output from the previous test.

Traceability Matrix

Traceability Matrix (also referred to as Requirement Traceability Matrix - RTM) is

a table that is used to trace the requirements during the Software Development Life
Cycle. It can be applied in various usages: forward tracing (i.e. from Requirements
to Design or Coding) or backward (i.e. from Coding to Requirements). Different
user-defined templates for RTM may be used.

Traceability Matrix is a table that is used to trace the requirements during the
Software Development Life Cycle.
Each requirement in the RTM document is linked with its associated test case so that
testing can be done as per the mentioned requirements. Moreover, Bug ID is also
included and linked with its associated requirements and test case.
The main goals for this matrix are:
• Verification that the software is developed as per the mentioned requirements.
• Identification the root cause of any bug.
• Tracing the developed documents during different phases of SDLC.

What is meant by the term "Real Time Testing"?

In the field of software testing, real time testing refers to the process of testing the
real time software product or system i.e. the system is constrained by some specific
time limits to perform and complete the job. Air Traffic Control and space navigation
system, may be seen as the examples of real time system, i.e. they responses in real
time.

Generally, it involves, testing of the software product in its running/operational mode

to evaluate its capability, to execute and finish a particular in a given stipulated time.
The chief purpose behind the real time testing is to drastically minimize the
probability of software’s failure in real time environment at the user site. It is done
to ensure that all the bugs and defects have been removed or fixed before its delivery
to the client or user.

Difficulties in Real time testing

First of all, real time systems are associated with the time-constraints as such testing
the system endorsed with the deadlines and real-time responses may seems to be a
tedious & complex job. Moreover, the results being generated by the real time
systems are non –predictable and have non-deterministic outcomes as such
conventional methods may not prove to be effective to test the real time systems.
Further, analyzing and testing the real time systems may be carried out in various
ways as such it would not recommendable to rely on one strategy or approach, i.e. it
would need exhaustive type of testing to evaluate the real time system and thereby,
may prove to be a time-consuming and expensive process.
How to do it?
Real time testing technique follow a simple and basic strategy to execute the testing
task, as described below:

• Task Testing

Involves the implementation and usage of conventional static techniques to

discover errors and flaws in the programming code such as syntax error. It,
usually, overlooks the behavorial aspect of the software product along with
the sequence of the action as it does not faces the time constraint.

• Behavioral Testing

The simulated real environment is being created based on the design model
with the help of automated tools to study the behaviour of the system under
the impact of external forces.

• Intertask Testing

After getting through the task of revealing errors in code and behavorial aspect
of the system, time-constraints are being introduced through intertask testing.

• System Testing

Testing the completely integrated system as a single whole system to explore

the defects & issues occurred during the integration process and in the
interfaces of the integrated software and hardware.
o
 Strategies of Software Testing
• Testing is a set of activities which are decided in advance i.e before the start of
development and organized systematically.
• In the literature of software engineering various testing strategies to implement the
testing are defined.
• All the strategies give a testing template.

Following are the characteristic that process the testing templates:

• The developer should conduct the successful technical reviews to perform the
testing successful.
• Testing starts with the component level and work from outside toward the
integration of the whole computer based system.
• Different testing techniques are suitable at different point in time.
• Testing is organized by the developer of the software and by an independent test
group.
• Debugging and testing are different activities, then also the debugging should be
accommodated in any strategy of testing.
•

•
Verification Validation
Verification is the process to find whether the software The validation process is checked whether the
meets the specified requirements for particular phase. software meets requirements and expectation of
the customer.
It estimates an intermediate product. It estimates the final product.

The objectives of verification is to check whether The objectives of the validation is to check
software is constructed according to requirement and whether the specifications are correct and satisfy
design specification. the business need.
It describes whether the outputs are as per the inputs or It explains whether they are accepted by the user or
not. not.
Verification is done before the validation. It is done after the verification.

Plans, requirement, specification, code are evaluated Actual product or software is tested under
during the verifications. validation.
It manually checks the files and document. It is a computer software or developed program
based checking of files and document.

Unit testing
Unit testing starts at the centre and each unit is implemented in source code.

Integration testing
An integration testing focuses on the construction and design of the software.
 Validation testing
Check all the requirements like functional, behavioral and performance requirement
are validate against the construction software.

System testing
System testing confirms all system elements and performance are tested entirely.

Testing strategy for procedural point of view

As per the procedural point of view the testing includes following steps.

1) Unit testing
2) Integration testing
3) High-order tests
4) Validation testing

These steps are shown in following figure:

Following are the issues considered to implement software testing strategies.

• Specify the requirement before testing starts in a quantifiable manner.
• According to the categories of the user generate profiles for each category of user.
• Produce a robust software and it's designed to test itself.
• Should use the Formal Technical Reviews (FTR) for the effective testing.
• To access the test strategy and test cases FTR should be conducted.
• To improve the quality level of testing generate test plans from the users feedback.
Test strategies for conventional softwareFollowing are the four strategies for conventional
software:
 1) Unit testing
2) Integration testing
3) Regression testing
4) Smoke testing

1) UNIT TESTING :
• Unit testing focus on the smallest unit of software design, i.e module or software
component.
• Test strategy conducted on each module interface to access the flow of input and
output.
• The local data structure is accessible to verify integrity during execution.
• Boundary conditions are tested.
• In which all error handling paths are tested.
• An Independent path is tested.
Following figure shows the unit testing:

Unit test environment

The unit test environment is as shown in following figure:

 Difference between stub and driver
Stub Driver
Stub is considered as subprogram. It is a simple main program.

Stub does not accept test case data. Driver accepts test case data.

It replace the modules of the program into subprograms and Pass the data to the tested components and
are tested by the next driver. print the returned result.
2) INTEGRATION TESTING

Integration testing is used for the construction of software architecture.

There are two approaches of incremental testing are: i)

Non incremental integration testing
ii) Incremental integration testing

i) Non incremental integration testing

• Combines all the components in advanced.
• A set of error is occurred then the correction is difficult because isolation cause is
complex. ii) Incremental integration testing
• The programs are built and tested in small increments.
• The errors are easier to correct and isolate.
• Interfaces are fully tested and applied for a systematic test approach to it.
Following are the incremental integration strategies:

a. Top-down integration
b. Bottom-up integration

1. TOP-DOWN INTEGRATION

• It is an incremental approach for building the software architecture.

• It starts with the main control module or program.
• Modules are merged by moving downward through the control hierarchy.
 Following figure shows the top down integration.

Problems with top-down approach of testing

Following are the problems associated with top-down approach of testing as

follows:
• Top-down approach is an incremental integration testing approach in which the test
conditions are difficult to create.
• A set of errors occur, then correction is difficult to make due to the isolation of cause.
• The programs are expanded into various modules due to the complications.
• If the previous errors are corrected, then new get created and the process continues.
This situation is like an infinite loop.

[Link]-UP INTEGRATION

In bottom up integration testing the components are combined from the lowest level
in the program structure.

The bottom-up integration is implemented in following steps:

• The low level components are merged into clusters which perform a specific
software sub function.
• A control program for testing(driver) coordinate test case input and output.
• After these steps are tested in cluster.
• The driver is removed and clusters are merged by moving upward on the program
structure.
 Following figure shows the bottom up integration:

3) REGRESSION TESTING
• In regression testing the software architecture changes every time when a new
module is added as part of integration testing.
4) SMOKE TESTING
• The developed software component are translated into code and merge to complete
the product.

DIFFERENCE BETWEEN REGRESSION AND SMOKE TESTING

Regression testing Smoke testing

Regression testing is used to check defects generated to At the time of developing a software product
other modules by making the changes in existing smoke testing is used.
programs.
In regression tested components are tested again to verify It permit the software development team to test
the errors. projects on a regular basis.
Regression testing needs extra manpower because the cost Smoke testing does not need an extra manpower
of the project increases. because it does not affect the cost of project.

Testers conduct the regression testing. Developer conducts smoke testing just before
releasing the product.
 ALPHA AND BETA TESTING
Alpha testing Beta testing

Alpha testing is executed at developers end by the Beta testing is executed at end-user sites in the
customer. absence of a developer.

It handles the software project and applications. It usually handles software product.

It is not open to market and the public. It is always open to the market and the public.

Alpha testing does not have any different name. Beta testing is also known as the field testing.

Alpha testing is not able to test the errors because the In beta testing, the developer corrects the errors
developer does not known the type of user. as users report the problems.
In alpha testing, developer modifies the codes before In beta testing, developer modifies the code after
release the software without user feedback. getting the feedback from user.

Verification and Validation

Verification and Validation is the process of investigating that a software system
satisfies specifications and standards and it fulfills the required purpose.
Verification:
Verification is the process of checking that a software achieves its goal without any
bugs. It is the process to ensure whether the product that is developed is right or not.
It verifies whether the developed product fulfills the requirements that we have.
Verification is Static Testing.
Activities involved in verification:Inspections
1. Reviews
2. Walkthroughs
3. Desk-checking
Validation:
Validation is the process of checking whether the software product is up to the mark
or in other words product has high level requirements. It is the process of checking
the validation of product i.e. it checks what we are developing is the right product.
it is validation of actual and expected product.
Validation is the Dynamic Testing. Activities
involved in validation:
1. Black box testing
2. White box testing
3. Unit testing
4. Integration testing
Note: Verification is followed by Validation.
SYSTEM TESTING is a level of software testing where a complete and
integrated software is tested. The purpose of this test is to evaluate the system’s
compliance with the specified requirements.

Definition

• system testing: The process of testing an

integrated system to verify that it meets
specified requirements.

During the process of manufacturing a ballpoint pen, the cap, the body, the tail, the
ink cartridge and the ballpoint are produced separately and unit tested separately.
When two or more units are ready, they are assembled and Integration Testing is
performed. When the complete pen is integrated, System Testing is performed.

Method
Usually, Black Box Testing method is used.

When is it performed?

System Testing is the third level of software

testing performed after Integration Testing and

before Acceptance Testing.

Who performs it?

Normally, independent Testers perform System Testing.

System Testing is a type of software testing that is performed on a complete
integrated system to evaluate the compliance of the system with the corresponding
requirements.
In system testing, integration testing passed components are taken as input. The goal
of integration testing is to detect any irregularity between the units that are integrated
together. System testing detects defects within both the integrated units and the
whole system. The result of system testing is the observed behavior of a component
or a system when it is tested.
System Testing is carried out on the whole system in the context of either system
requirement specifications or functional requirement specifications or in the context
of both. System testing tests the design and behavior of the system and also the
expectations of the customer. It is performed to test the system beyond the bounds
mentioned in the software requirements specification (SRS).
System Testing is basically performed by a testing team that is independent of the
development team that helps to test the quality of the system impartial. It has both
functional and non-functional testing.
System Testing is a black-box testing.
System Testing is performed after the integration testing and before the acceptance
testing.
Performance Testing
Performance Testing also knows as ‘Perf Testing', is a type of testing performed to
check how application or software performs under workload in terms of
responsiveness and stability. The Performance Test goal is to identify and remove
performance bottlenecks from an application.
This test is mainly performed to check whether the software meets the expected
requirements for application speed, scalability, and stability.
Types Of Performance Testing

Load Testing
Load Testing is a type of performance test where the application is tested for its
performance on normal and peak usage. The performance of an application is
checked with respect to its response to the user request and its ability to respond
consistently within an accepted tolerance on different user loads.

The key considerations are:

1. What is the maximum load the application is able to hold before the
application starts behaving unexpectedly?
2. How much data the Database able to handle before the system slows or the
crash is observed?
3. Are there any network related issues to be addressed?
Stress Testing
Stress Testing is used to find ways to break the system. The test also provides the
range of maximum load the system can hold.

Generally, Stress Testing has an incremental approach where the load is increased
gradually. The test is started with a load for which the application has already been
tested. Then, more load is added slowly to stress the system. The point at which we
start seeing servers not responding to the requests is considered the breaking point.

The following questions are to be addressed:

• What is the maximum load a system can sustain before it breaks down?
• How is the system break down? • Is the system able to recover once it’s
crashed?
• In how many ways a system can break and which are the weak node while
handling the unexpected load?
Volume Testing
Volume Testing is to verify that the performance of the application is not affected by
the volume of data that is being handled by the application. In order to execute a
Volume Test, a huge volume of data is entered into the database. This test can be an
incremental or steady test. In the incremental test, the volume of data is increased
gradually.
Generally, with the application usage, the database size grows, and it is necessary to
test the application against a heavy database. A good example of this could be a
website of a new school or a college having small amounts of data to store initially,
but after 5-10 years, the data stores in the database of the website is much more.

Capacity Testing
=> Is the application capable of meeting business volume under both normal and
peak load conditions?
Capacity Testing is generally done for future prospects. Capacity Testing addresses
the following:
1. Will the application be able to support the future load?
2. Is the environment capable of standing for the upcoming increased load?
3. What are the additional resources required to make the environment capable
enough?
Capacity Testing is used to determine how many users and/or transactions a given
web application will support and still meet performance. During this testing,
resources such as processor capacity, network bandwidth, memory usage, disk
capacity, etc. are considered and altered to meet the goal.

Online Banking is a perfect example of where capacity testing could play a major
role.
Reliability/Recovery Testing

Reliability Testing or Recovery Testing – is to verify whether or not the application

is able to return back to its normal state after a failure or abnormal behavior and how
long does it take for it to do so (in other words, time estimation).

If an online trading site experiences a failure where the users are not able to buy/sell
shares at a certain point of the day (peak hours) but are able to do so after an hour or
two, we can say the application is reliable or recovered from the abnormal behavior.

Performance Test Process

Here are all the activities performed in this testing:

1) Requirement Analysis/Gathering
The performance team interacts with the client for identification and gathering of
requirements – technical and business. This includes getting information on the
application's architecture, technologies, and database used, intended users,
functionality, application usage, test requirement, hardware & software
requirements, etc.
2) POC/Tool selection
Once the key functionality is identified, POC (Proof Of Concept – which is a sort of
demonstration of the real-time activity but in a limited sense) is done with the
available tools.
The list of available tools depends on the cost of the tool, protocol that application
is using, the technologies used to build the application, the number of users we are
simulating for the test, etc. During POC, scripts are created for the identified key
functionality and executed with 10-15 virtual users.

3) Performance Test Plan & Design

Depending on the information collected in the preceding stages, test planning and
designing are conducted.

Test Planning involves information on how the performance test is going to take
place – test environment, workload, hardware, etc.

More on the Test Strategy document below.

4) Performance Test Development
• Use cases are created for the functionality identified in the test plan as the
scope of PT.
• These use cases are shared with the client for their approval. This is to make
sure the script will be recorded with the correct steps.
• Once approved, script development starts with a recording of the steps in use
cases with the performance test tool selected during the POC (Proof of
Concepts) and enhanced by performing Correlation (for handling dynamic
value), Parameterization (value substitution) and custom functions as per the
situation or need. More on these techniques in our video tutorials.
• The Scripts are then validated against different users.
• Parallel to script creation, the performance team also keeps working on setting
up the test environment (Software and hardware).
• The performance team will also take care of Metadata (back-end) through
scripts if this activity is not taken up by the client.
5) Performance Test Modeling
Performance Load Model is created for the test execution. The main aim of this step
is to validate whether the given Performance metrics (provided by clients) are
achieved during the test or not. There are different approaches to create a Load
model. “Little's Law” is used in most cases.
6) Test Execution
The scenario is designed according to the Load Model in Controller or
Performance Center but the initial tests are not executed with maximum users that
are in the Load model.
Test Execution is done incrementally.
For Example, If the maximum number of users is 100, the scenarios are first run
with 10, 25, 50 users and so on, eventually moving on to 100 users. 7) Test
Results Analysis
Test results are the most important deliverable for the performance tester. This is
where we can prove the ROI (Return on Investment) and productivity that a
performance testing effort can provide.

Some of the best practices that help the Result Analysis process:
1. A unique and meaningful name to every test result – this helps in
understanding the purpose of the test.
2. Include the following information in the test result summary:
• Reason for the failure/s
• Change in the performance of the application compared to the previous test
run
• Changes made in the test from the point of application build or test
environment.
• It’s a good practice to make a result summary after each test run so that
analysis results are not compiled every time test results are referred.
• PT generally requires many test runs to reach the correct conclusion.
• It is good to have the following points in result summary:
• Purpose of test
• Number of virtual users
• Scenario summary
• Duration of test
• Throughput
• Graphs
• Graphs comparison
• Response Time
• Error occurred
• Recommendations
8) Report
Test results should be simplified so the conclusion is clearer and should not need
any derivation. Development Team needs more information on analysis,
comparison of results, and details of how the results were obtained.
The test report is considered to be good if it is brief, descriptive and to the point.
How To Write Performance Test Strategy Document?
The key objectives of Performance Testing are as follows:
• To gain the confidence that the changes to the existing chat application are in
line with the defined Service Level Agreement.
• To ensure that the application performance, service availability, and the
stability of the application are not impacted as a result of the new
enhancements.
• Transaction Response Times remain within the acceptable tolerance over the
increasing Load profile.
• JVMs show stable memory usage over the increasing load profiles.
The below picture clearly explains Performance Testing & Optimization process:
 Performance Test Scenarios
Include the excel with the set of scenarios.

For Example,
Scenario 1: To validate the Agent and customer chat for X no. of concurrent
sessions.
Performance Test Types
The table given below explains the various types of Performance Tests along with
their objectives.
Test Type Objective

Baseline Test Establish the best performance under specific volumes which will be used as a reference
for subsequent measurements.

Load Test Measure the system performance under anticipated peak production load.

Endurance Measuring the system stability under high volume for an extended period.
Test
Stress Test Measure the system performance under unfavorable conditions.
Performance Metrics
• Client-side Metrics

[Link] Metric Description Format

1 Transaction onse Time Response time of pages during the steady state of the Graph
performance test

2 Throughput The amount of data that the VUsers received from the Graph
server over time

3 Hits/second The number of HTTP requests made by VUsers to the Graph

Web server during the scenario run
4 Number of Passed/Failed Total number of transactions that Passed and Failed Excel
Transactions during the test execution

5 Transaction Error Rate The Percentage of transactions that failed during the Graph test execution
System & Network Performance Metrics

2) Test Data
It is being assumed that the Performance environment data will be a copy of the
production data and the required test data will be provided by the project team.

3) Entry & Exit Criteria

• Access to all the applications in the environment.
• Environment readiness complete.
• Performance Test Data readiness.
REGRESSION TESTING
Regression Testing is a type of testing that is done to verify that a code change in the
software does not impact the existing functionality of the product. This is to make
sure the product works fine with new functionality, bug fixes or any change in the
existing feature. Previously executed test cases are re-executed in order to verify the
impact of change.

Regression Testing is the process of testing the modified parts of the code and the
parts that might get affected due to the modifications to ensure that no new errors
have been introduced in the software after the modifications have been made.
Regression means return of something and in the software field, it refers to the return
of a bug.
When to do regression testing?
• When a new functionality is added to the system and the code has been modified
to absorb and integrate that functionality with the existing code.
• When some defect has been identified in the software and the code is debugged
to fix it.
• When the code is modified to optimize its working.
Process of Regression testing:
Firstly, whenever we make some changes to the source code for any reasons like
adding new functionality, optimization, etc. then our program when executed fails in
the previously designed test suite for obvious reasons. After the failure, the source
code is debugged in order to identify the bugs in the program. After identification of
the bugs in the source code, appropriate modifications are made. Then appropriate
test cases are selected from the already existing test suite which covers all the
modified and affected parts of the source code. We can add new test cases if required.
In the end regression testing is performed using the selected test cases.
TECHNIQUES FOR THE SELECTION OF TEST CASES FOR
REGRESSION TESTING:
• Select all test cases: In this technique, all the test cases are
selected from the already existing test suite. It is the most
simple and safest technique but not much efficient.
• Select test cases randomly: In this technique, test cases are
selected randomly from the existing test-suite but it is only
useful if all the test cases are equally good in their fault
detection capability which is very rare. Hence, it is not used in
most of the cases.
• Select modification traversing test cases: In this technique,
only those test cases are selected which covers and tests the
modified portions of the source code the parts which are
affected by these modifications.
• Select higher priority test cases: In this technique, priority
codes are assigned to each test case of the test suite based upon
their bug detection capability, customer requirements, etc. After
assigning the priority codes, test cases with highest priorities are
selected for the process of regression testing. Test case with
highest priority has highest rank. For example, test case with
priority code 2 is less important than test case with priority code
1.

Tools for regression testing: In regression testing, we generally

select the test cases form the existing test suite itself and hence, we
need not to compute their expected
output and it can be easily automated due to this reason. Automating
the process of regression testing will be very much effective and time
saving. Most commonly used tools for regression testing are:
• Selenium
• WATIR (Web Application Testing In Ruby)
• QTP (Quick Test Professional)
• RFT (Rational Functional Tester)
• Winrunner
 • Silktest
•
Advantages of Regression Testing:
• It ensures that no new bugs has been introduced after adding new
functionalities to the system.
• As most of the test cases used in Regression Testing are
selected from the existing test suite and we already know their
expected outputs. Hence, it can be easily automated by the
automated tools.
• It helps to maintain the quality of the source code.
Disadvantages of Regression Testing:
• It can be time and resource consuming if automated tools are not used.
• It is required even after very small changes in the code.
Implementation - process

• Analyse the problem carefully to identify strengths,

weaknesses and opportunities
• The Constraints such as budgets, time and other requirements are noted.
• Evaluating the options and Shortlisting the ones that are meets the
requirement
• Developing the Proof of Concept which captures the pros and cons
• Create a Pilot Project using the selected tool within a specified team
• Rolling out the tool phase wise across the organization.
BOUNDARY VALUE ANALYSIS IN SOFTWARE TESTING
Boundary value analysis is a (software testing) black box Testing technique or
specification-based testing technique. This technique is used to test the boundary
values. It is widely recognized that input values at the extreme ends of the input
domain cause more chances of errors in the application.

While testing the boundary value analysis the main aim of the software tester is
to check whether the application is providing the correct input or not when
entering the boundary values.

Boundary value analysis was done after the compilation of Equivalence

Partitioning. Equivalence class Partitioning plays an important role in boundary
testing.
What is boundary value?
A boundary value is one that contains the limits of a variable (Upper and lower ).
For Example, there is a student registration page and an age field is there which
accept student aged 18 as the minimum and 35 as the maximum. Here (18 -35) are
the boundary value for the field.

How to do Boundary Value Testing?

If the field to be tested accept the range of value from a to b then test the field by
(a-1, a a+1 and b-1, b,b+1)
Example of Boundary Value Analysis
In the below student sign-up page the boundary value for the age field is 18 and
35 let's try to understand the real analysis by this example.

Fig. Boundary value analysis Example Boundary

Value : 18(Minimum) and 35 (maximum)

using (a-1, a,a+1 and b-1, b,b+1) formula test engineers have to find the range
and on the basis of this, they have to write the test cases.
(17, 18, 19 and 34,35,36).

While writing the test cases for boundary value tester has to identify the range
boundary value and then start writing test cases.
Example - Test Cases :

Check the age field by entering the value which is not in the range (ie.17and 36)

Check the age field by entering the exact boundary value (ie . 18and 35 )

Check the age field by entering the value which is within the boundary value (17
to 34)

Advantage of boundary value analysis :

The various boundary value analysis advantage is given below
The boundary value analysis (BVA) technique of testing is very easy to use and
remember.

The overall time taken to execute the test cases is reduced.

Generation of test cases through BVA is minimal

Disadvantage of boundary value analysis :

A list of the disadvantage of boundary value analysis is given below.

BVA does not test all possible inputs.

BVA does not test the combination of inputs.

Boundary Value Analysis

Boundary Value Analysis is based on testing the boundary values of valid and
invalid partitions. The behaviour at the edge of the equivalence partition is more
likely to be incorrect than the behaviour within the partition, so boundaries are an
area where testing is likely to yield defects.
It checks for the input values near the boundary that have a higher chance of
error. Every partition has its maximum and minimum values and these maximum
and minimum values are the boundary values of a partition.

Note:

A boundary value for a valid partition is a valid boundary value.

A boundary value for an invalid partition is an invalid boundary value.
For each variable we check-

Minimum value.

Just above the minimum. Nominal

Value.

Just below Max value. Max

value.

Example: Consider a system that accepts ages from 18 to 56.

Boundary Value Analysis(Age accepts 18 to 56)

Invalid Valid Invalid

(min-1) (min, min + 1, nominal, max – 1, max) (max + 1)

17 18, 19, 37, 55, 56 57

Valid Test cases: Valid test cases for the above can be any value entered greater
than 17 and less than 57.

Enter the value- 18.

Enter the value- 19.

Enter the value- 37.

Enter the value- 55.

Enter the value- 56.

Invalid Testcases: When any value less than 18 and greater than 56 is entered.

Enter the value- 17.

Enter the value- 57.

Single Fault Assumption: When more than one variable for the same application is
checked then one can use a single fault assumption. Holding all but one variable
to the extreme value and allowing the remaining variable to take the extreme
value. For n variable to be checked:

Maximum of 4n+1 test cases

Problem: Consider a Program for determining the Previous Data.

Input: Day, Month, Year with valid ranges as-

1 ≤ Month≤12 1
≤ Day ≤31
1900 ≤ Year ≤ 2000

Design Boundary Value Test Cases.

Solution: Taking the year as a Single Fault Assumption i.e. year will be having
values varying from 1900 to 2000 and others will have nominal values.

Test Cases Month Day Year Output

1 6 15 1990 14 June 1990

2 6 15 1901 14 June 1901

3 6 15 1960 14 June 1960

4 6 15 1999 14 June 1999

5 6 15 2000 14 June 2000

Taking Day as Single Fault Assumption i.e. Day will be having values varying
from 1 to 31 and others will have nominal values.

Test Case Month Day Year Output

6 6 1 1960 31 May 1960

7 6 2 1960 1 June 1960

 8 6 30 1960 29 June 1960

9 6 31 1960 Invalid day

Taking Month as Single Fault Assumption i.e. Month will be having values
varying from 1 to 12 and others will have nominal values.

Test Case Month Day Year Output

10 1 15 1960 14 Jan 1960

11 2 15 1960 14 Feb 1960

12 11 15 1960 14 Nov 1960

13 12 15 1960 14 Dec 1960

For the n variable to be checked Maximum of 4n + 1 test case will be required.

Therefore, for n = 3, the maximum test cases are-

4 × 3 + 1 =13
The focus of BVA: BVA focuses on the input variable of the function. Let’s
define two variables X1 and X2, where X1 lies between a and b and X2 lies
between c and d.

Showing legitimate domain

The idea and motivation behind BVA are that errors tend to occur near the
extremes of the variables. The defect on the boundary value can be the result of
countless possibilities.
Typing of Languages:
BVA is not suitable for free-form languages such as COBOL and FORTRAN,
These languages are known as weakly typed languages. This can be useful and
can cause bugs also.

PASCAL, ADA is the strongly typed language that requires all constants or
variables defined with an associated data type.

Limitation of Boundary Value Analysis:

It works well when the product is under test.
It cannot consider the nature of the functional dependencies of variables.

BVA is quite rudimentary.-

ROBUSTNESS TESTING
********************************************************
What is Robustness Testing?
Robustness testing, also known as fault tolerance testing or negative testing, is a
software testing technique designed to assess a system’s ability to handle
unexpected or invalid inputs gracefully. It aims to identify vulnerabilities and
weaknesses in the software that could lead to crashes, security breaches, or data
corruption when faced with unpredictable circumstances. Robustness testing
goes beyond normal functionality testing and pushes the software to its limits.
**************************************************************

IMPORTANCE OF ROBUSTNESS TESTING

*************************************************************
Robustness testing is critically important in software development and quality
assurance for several key reasons:

Ensuring Reliability: Robustness testing verifies that software functions reliably

even when exposed to unexpected or adverse conditions. This is crucial for
preventing crashes, data corruption, and unexpected downtime, which can
damage user trust and disrupt business operations.
Security Assurance: Security vulnerabilities often arise from unexpected inputs
or error conditions. Robustness testing helps uncover these vulnerabilities,
reducing the risk of security breaches, data leaks, and cyberattacks.
User Experience: Users expect software to work seamlessly, and robustness
testing helps ensure a positive user experience. When software handles errors
gracefully, users are less likely to encounter frustrating crashes or data loss,
leading to higher satisfaction.
Legal and Regulatory Compliance: In many industries, compliance with
regulations requires software to be robust and capable of handling exceptional
scenarios. Robustness testing assists organizations in meeting these legal
requirements and avoiding costly penalties.
Cost Savings: Identifying and addressing issues during the development phase
through robustness testing is significantly more cost-effective than dealing with
them post-deployment. This testing helps avoid expensive downtime, data
breaches, and litigation.

Preventative Maintenance: This testing encourages a proactive approach to

software quality by identifying vulnerabilities early. This allows developers to
take preventive measures, reducing the likelihood of issues propagating
throughout the system.
Risk Mitigation: This testing helps mitigate the risks associated with software
failures, which can include reputation damage, financial losses, and customer
attrition. By addressing robustness issues, organizations can minimize these
risks.
Continuous Improvement: Integrating robustness testing into CI/CD pipelines
ensures that software robustness is continually assessed as the code evolves. This
facilitates ongoing improvement and maintenance of software quality.
Optimized Performance: Stress testing, a type of thi testing, evaluates how
software performs under heavy loads and resource constraints. This information
is invaluable for optimizing performance and scalability.

Market Competitiveness: In a competitive market, software reliability and

robustness can be differentiating factors. Robust software is more likely to stand
out and gain a competitive edge.

******************************************************************

ROBUSTNESS TESTING METHODOLOGIES

******************************************************************

Boundary Value Analysis: This technique involves testing the boundaries of

valid input ranges. Test cases are created to assess how the software responds to
values at the extreme ends of the input domain.

Stress Testing: Stress testing involves subjecting the software to extreme

conditions, such as high loads, heavy traffic, or resource exhaustion. This helps
evaluate the software’s stability and performance under adverse circumstances.

Fuzz Testing: Fuzz testing, or fuzzing, is a technique where the software is

bombarded with a large volume of random or unexpected inputs to identify
vulnerabilities, crashes, or security weaknesses.

Negative Testing: Negative testing focuses on providing invalid or unexpected

input data to the software, testing its ability to handle errors gracefully and
prevent crashes.

Load Testing: While typically associated with performance testing, load testing
can also be used for robustness testing by simulating heavy loads to assess how
the software responds to stress.
CHALLENGES IN ROBUSTNESS TESTING:
Test Case Generation: Creating comprehensive test cases for robustness testing
can be challenging, as it requires identifying potential weaknesses in the
software.
Resource Intensive: This testing, especially stress testing, can be resource-
intensive and time-consuming, requiring powerful hardware and thorough
monitoring.
False Positives: This testing may generate false positives, where the software
may handle invalid inputs correctly, but the test reports indicate issues

BEST PRACTICES IN ROBUSTNESS TESTING:

To conduct effective robustness testing, consider these best practices:

Thorough Requirement Analysis: Begin by understanding the software’s

requirements and potential use cases. Identify scenarios where unexpected inputs
or adverse conditions may occur.
Boundary Testing: Pay close attention to boundary conditions, as many
vulnerabilities arise when software processes values near the boundaries of valid
input ranges.
Test Automation: Automate robustness tests wherever possible, as manual testing
can be time-consuming and less reliable for repeated execution.

Diverse Inputs: Ensure that your test inputs are diverse and cover a wide range of
potential scenarios, including edge cases and error conditions.

Monitoring and Reporting: Implement robust monitoring during testing to

capture system behavior under stress. Detailed reporting of failures and their
impact is crucial for developers to address issues effectively.

Recovery Testing: Include recovery testing to evaluate the software’s ability to

recover gracefully from unexpected errors, crashes, or resource exhaustion.
Regression Testing: As you identify and fix robustness issues, include these test
cases in your regression testing suite to prevent the reoccurrence of known
vulnerabilities.
Continuous Testing: Implement continuous robustness testing as part of your
DevOps or CI/CD pipelines to catch issues early in the development process.
ADVANTAGES OF ROBUSTNESS TESTING:
Enhanced Software Reliability: This testing identifies and addresses
vulnerabilities, ensuring that the software remains reliable even in the presence
of unexpected inputs or adverse conditions. This reliability enhances the user
experience and fosters trust in the software.

Improved Security: By subjecting the software to a variety of unexpected inputs,

this testing helps uncover potential security vulnerabilities. Addressing these
vulnerabilities before deployment is crucial in preventing security breaches and
protecting sensitive data.

Cost Savings: Identifying and fixing issues during the development phase
through robustness testing is considerably more cost-effective than addressing
them after the software has been deployed. This testing can help avoid costly
downtime, data breaches, and legal repercussions.
Optimized Performance: This testing, particularly stress testing, assesses how the
software handles heavy loads and resource exhaustion. This information is
valuable for optimizing the software’s performance and scalability.

User Satisfaction: Robust software is more likely to provide a seamless and

uninterrupted user experience. Users are less likely to encounter crashes, errors,
or data loss, leading to higher user satisfaction and loyalty.

Compliance with Regulations: In many industries, regulatory compliance

requires software to handle exceptions and errors gracefully. This testing helps
organizations meet these legal requirements and avoid penalties.

Early Issue Identification: This testing is often conducted early in the software
development lifecycle. This allows developers to identify and address issues
before they propagate through the entire system, saving time and effort.
Preventative Maintenance: This testing promotes a proactive approach to
software quality assurance. By anticipating potential issues, organizations can
take preventive measures to ensure software robustness.

Risk Mitigation: Identifying and addressing robustness issues reduces the risk of
software failures and their associated consequences, including reputation
damage, financial losses, and customer churn.

Continuous Improvement: This testing can be integrated into continuous

integration and continuous delivery (CI/CD) pipelines, ensuring that robustness
is continually assessed as software evolves. This facilitates ongoing improvement
and maintenance of software quality.
 ******************************************************************

WORST CASE BOUNDARY VALUE TESTING

*******************************************************
Worst-Case boundary value analysis is a Black Box software testing technique.
In Worst case boundary value testing, we make all combinations of each value of
one variable with each value of another variable.

Worst Boundary value testing on 2 variables

1) Worst-Case Testing : Introduction

Highlight the importance of worst-case scenarios for safety, effectiveness, and
compliance. Stress the need for a versatile, systematic approach applicable
across various product families and/or processes.

2) Worst-Case: Scope and Purpose

Clearly define the scope of the worst-case scenario, specifying its intended
application (e.g., process validation, design verification, cleaning validation,
etc.).

State the purpose, emphasizing risk mitigation, compliance, or process

optimization.

3) Worst-Case: Identify Critical Parameters

Identify the key parameters that significantly influence safety, efficacy, or
compliance of the product or process.

Consider factors such as materials, environmental conditions, user interactions,

and potential failure modes.

4) Worst-Case: Assess Variability

Evaluate the variability associated with each critical parameter.
Determine the lower and upper limits, considering both typical and extreme
conditions.
5) Define Worst-Case Conditions
Develop a matrix or framework that combines critical parameters and their
variability.

Select worst-case conditions by identifying the most extreme values or

combinations of parameters from the matrix.

An example of worst-case testing

Please note that the matrix provided is solely an illustrative example and is
neither accurate nor exhaustive in representing the full scope of a specific
scenario

5) Worst-Case: Documentation and Rationale

Document the rationale behind the selection of worst-case conditions

Include detailed information on how each parameter was evaluated and why
specific conditions were chosen.
6) Worst-Case: Monitoring and Adaptation
Emphasize the need for ongoing monitoring and reassessment of worst-case
scenarios (e.g., product and/or process changes; is the worst-case still
applicable?).Acknowledge that technology, regulations, or other circumstances
may change, requiring updates to worst-case definitions.

TEST CASE
*****************************************************************
A test case specifies the inputs, execution conditions, testing procedure, and
expected results that define a single test to achieve a particular software testing
objective, such as to exercise a particular program path or verify compliance
with a specific requirement.
Test cases are software or application pieces that you can use to test the
functionality of a real system. They can be used to evaluate the correctness and
completeness of your code and can be used in conjunction with unit testing tools
to ensure the quality of your applications.
Test cases can be created manually or using software testing tools. They are an
essential part of software development and should be used wherever possible to
ensure the quality and functionality of your applications, including end-user test
execution.
How To Write Test Cases In Software Testing :
Writing test cases is an essential part of software testing. Without them, it would
not be easy to verify the results of your tests. Test cases are templates that help
automate the testing process. They help specify the conditions under which a
particular functionality should be tested, including the postcondition.
For example, a test case could include clicking the login button and verifying
that the user is directed to the correct page.

Creating test cases ensures your software functions as expected and performs
properly in all situations, including login functionality where the user enters
their username and password. Additionally, TCs are necessary for manual
testing – without them, it would be difficult to verify the results of your tests.
Best Practice for Writing Good Test Case For Tester
Writing good pre-test cases is essential for testing the functionality and usability
of your software or application. If you follow best practices for software
requirements, your TCs will be easy to follow and understand, and you’ll be able
to run them frequently to ensure they’re accurate.

Include all the necessary details in your test cases to test the software under all
possible conditions. Finally, ensure your test cases are easy to follow and run so
that everyone involved in testing can get the most out of them. You can also
provide a tutorial to help users understand how to run the test cases effectively.

Basic Format of Test Cases Excel Sheet

Creating test cases with a traceability matrix is essential to software testing,

including regression testing. A test case is a scenario you use to test software or
system. The statement of the problem, what you want to be tested, and the
conditions under which the test will take place are all included in a test case.
A TC can be used to verify that your application works as expected or to find
problems early in development. Writing test cases well makes it easier for you
and other developers to work on your project.

Now, we will see how to create a basic test case format. First, we will create the
test case template and then implement the test cases as required. So, to create a
test case template, I will open an Excel sheet and add the required fields,
including documentation.
So before start writing the test case template, let’s see what fields are necessary
in a TCs template while writing test cases. Here is the fields list:

1. Project Name
2. Created By
3. Reviewed By
4. Test Scenario ID
5. Test Case ID
6. Test Steps
 7. Post Conditions
8. Actual Result
9. Executed By
10. Comments ( if any )
11. Module Name
12. Creation Date
13. Reviewed Date
14. Test Scenario Description
15. Test Case Description
16. Preconditions
17. Expected Result
18. Status
19. Executed Date
Manual Testing Test Cases QA

We noticed that the interviewer mostly gave some real-time scenarios and
expected test cases. If you have good knowledge of that application, you need to
think as much as possible about test scenarios. If you are unaware of that
application, you can ask for the details of the application, which is called
Business Rules and Acceptance Criteria.
Different Types of Test Case Scenarios
Test cases are a set of specific instructions or criteria that are used to determine
whether a piece of code is working correctly. These test cases can be designed to
test different aspects of the code, such as its functionality, performance, or
security. In some cases, test cases may be designed to intentionally cause the
code to fail, for example, by providing incorrect input or attempting to access
restricted areas.

This is done to verify that the code can handle such situations and respond
appropriately rather than crashing or behaving unexpectedly. So, based on the
behaviors, we can divide the test cases into the following:
Test Cases Examples ~ Test Cases Scenario Example
We Know if someone started his/her career as a manual tester, then the first
assigned work for him may be writing test cases. In that time, you may be
looking for Test Cases in Software Testing Examples PDF, which will help you
to understand how to write test cases.
We will provide the manual testing projects with test cases in a PDF. So, if you
have been searching for Test Cases in the Software Testing Examples PDF, we
will gladly share the test cases below.

The manual testing projects below with test cases pdf can be used for software
testing, performance testing, and penetration testing. The test case example for
manual testing provided in the PDF is only an example to give you a better idea
of how these tools work best in the software development environment
(development/testing).
Functional Test Case Examples

A functional test case is a valuable tool for testers that helps ensure that a new
function or feature works as expected. Creating and running a functional test case
lets you quickly determine if the function or feature works as intended. This
process helps prevent any unexpected side effects during the release process,
which could lead to chaos and instability.

Functional tests should be conducted throughout the development cycle – at the

initial design stage, during development, and after release. They help to identify
potential issues early on so that they can be fixed before users experience them.

*****************************************************************

TEST CASES FOR TRIANGLE PROBLEM

*****************************************************
Check if the shape is equilateral or isosceles, or scalene.

Check It must be a closed figure.

Check that the figure must contain only three sides, straight, and only three
angles.

Check two sides must be passing through each vertex.

Check the sum of all three angles must be 180 degrees.

Check all sides should be the same in length for equilateral.

Check only two sides should be the same for an isosceles.

Check if one angle is 90′, then it is right-angled.

One/Two/Three sides are 0.

Check if the sides are coinciding or not.

Check if the image’s shape is right-angled isosceles, if there is a right angle, or
not if the triangle is acute or obtuse or right-angle.
Check what the isosceles shape is; the opposite angles are equal or not. Check

if it is equilateral and if all the angles are equal (i.e., 60 degrees]. Check if the

user can draw the three circles [interior, exterior, circumcircle ] Check

whether all sides are equal or not.

Verify If all sides are equal, it is the equal or scalene triangle.

Check all angles or equal or not.

The sum of all angles in a triangle should be 180 degrees.

The sum of any two sides of a triangle is always higher than the third side. It is
less than the third side. It implies that the three sides lie in a straight line.

A triangle can not have two right angles, i.e., it can not have two angles equal to
90o as it is equal to 180o for two angles, and the third angle must be zero, which
is impossible.

A triangle can not have two obtuse angles, and a triangle can not have two angles
more than 90o as it only exceeds 180o for two angles.

Check Minimum and Max number of sides = 3

Check all the sides are connected (there must be three connection points)

Check No lines overlap each other.

Check two sides are cut perpendicular.

Check that no sides are parallel.

Test Cases for Equilateral Triangle It

should have only three sides.

Each side is connected to the other two sides.

The angle between any two sides must be equal to 60 degrees.

The sum of angles must be 180 degrees.

The length of all sides must be the same.

Examples :
Test Case For Tea Cup Or Coffee Cup :

These Software testing techniques are categorized into different aspects to

ensure the quality and functionality of the cups. Let’s break down the
categorization:
Company Information Verification:

Verify the company name on the cup.

Verify the company logo on the cup.

Material and Design Verification: Verify

the material of the cup.

Verify the colour of the cup.

Verify the size of the cup.

Verify the shape of the cup.

Verify the weight of the cup.

Verify the cost of the cup.

Functionality Verification: Verify

if the cup is easy to carry. Verify

the capacity of the cup.

Verify the grip of the cup.

Verify if it is easily washable.

Verify if a handle is available.

Verify if the cup is reusable.
Verify that the cup can be placed on a surface without falling down.

Verify if the cup can sustain hot tea for at least 1 hour.

Verify if the cup can sustain cold tea for at least 1 hour. Verify

there is no leakage when filled with tea.

User Experience Verification:

Check if the cup has the shape of normal cup models.
Supply hot and cold tea and check stability for the specified time.

Supply tea and check for leaks.

Check if the cup meets specified user-friendliness criteria.

Paper Cup Verification:

Check the colour of the paper cup.

Check the width and weight of the paper cup. Check

the temperature conduction of the paper cup. Check

the smoothness and curve of the lip area.

Check the shape of the base for stability with and without tea. Negative

test cases for Coffee or Tea Cup

Verify any leakage for the coffee cup or tea cup. Verify

that it is breakable or not.

These Test cases for Tea Cup testing techniques cover a comprehensive range of
factors, ensuring a thorough assessment of the coffee or tea cups in terms of their
design and functionality.
 Conclusion:
Developing thorough Test Case For Tea Cups, coffee, and all-purpose cups is crucial for
identifying design flaws before manufacturing. As we have seen, testcases should
evaluate factors like temperature sustainability, spill and leak prevention, durability,
capacity, grip, usability, and compliance with relevant standards.

Random Testing in Software Testing

Random testing is software testing in which the system is tested with the help of
generating random and independent inputs and test cases. Random testing is also
named monkey testing. It is a black box assessment outline technique in which the tests
are being chosen randomly and the results are being compared by some software
identification to check whether the output is correct or incorrect.
Some important points about Random Testing:
1. Random testing was first examined by Melvin Breuer in the year 1971.
2. This testing was initially assessed by Pratima and Vishwani Agrawal in the
year 1975 to check the successful output of the software.
3. For random testing, there is also a book that contains some formulas for the
number of tests that can be taken and the number of successful results and
failure results.
Working Random Testing:
Step-1: Identify Input domain
Step-2: Select test inputs independently/randomly from the input domain
Step-3: Test the system on these inputs and form a random test set
Step-4: Compare the result with system specification
Step-5: If the Report fails then take necessary action.
The below image represents the working of Random Testing more clearly.
 Working of Random Testing

Types of Random Testing:Random input sequence generation: It is also known as

Random Number Generator (RNG) in which a random sequential number or symbols is being generated
which cannot be assumed during the random selection.
1. Random sequence of data inputs: In this, all the data are selected randomly
for the inputs which can be used during the testing.
2. Random data selection from an existing database: The record where all the
data are available from that record only the data can be selected for testing afterward no
additional data cannot be added which are not available in the record.
Characteristics of Random Testing:
1. Random testing is implemented when the bug in an application is not recognized.
2. It is used to check the system’s execution and dependability.
3. It saves our time and does not need any extra effort.
4. Random testing is less costly, it doesn’t need extra knowledge for testing the
program.
Methods to Implement Random Testing:
To implement the random testing basically, four steps are applied:
1. The user input domain is analyzed.
2. After that, from that domain, the data of test inputs are chosen separately.
3. With the help of these test inputs, the test is executed successfully. These
input tests conduct random sets of tests.
4. The outcomes are compared with the system identification. The outcome of the
test becomes unsuccessful if any test input doesn’t match with the original one
otherwise the outcomes are always successful.

Advantages of Random Testing :

1. It is very cheap so that anyone can use this software.
2. It doesn’t need any special intelligence to access the program during the
tests.
3. Errors can be traced very easily; it can easily detect the bug throughout the
testing.
4. This software is lacking bias means it makes the groups evenly for the testing and
it prefers not to repeatedly check the errors as
there can be some changes in the codes throughout the testing process.
 Disadvantages of Random Testing:

1. This software only finds changes errors.

2. They are not practical. Some tests will be of no use for a longer time.
3. Most of the time is consumed by analyzing all the tests.
4. New tests cannot be formed if their data is not available during testing.
Tools used for Random Testing :
1. QuickCheck: It is a famous test tool, which was introduced for Haskell which is
available in many different languages. This tool generates random orders for API
calls that are related to the model and the properties of the system which can give
successful results after every test.
2. Randoop: This tool provides an order of methods and constructor acknowledgment for
the classes during the test and generates JUnit tests.
3. Simulant: It is a Clojure tool that runs according to the system’s different
specifications, the behavior of the model.
4. Gram Test: This random testing tool is based on grammar which is written in Java, It
utilizes BNF notation for specifying the grammar which is used as input during testing.

QUESTION AND ANSWERS :-

1. What is testing ?
2. What is software testing?
3. Why do we need testing in project ?
4. What are the stages involved in testing?
5. What are the types of testing?
6. Difference between black box testing and white box testing.
7. Explain the types of testing in detail.(11 marks)
8. What is a test case?
9. Why do we need a test case in testing?
[Link] are the principles used in testing that are applied for all the test case?
[Link] are the four important test cases used in testing ?
[Link] the guidelines of BVA in all the 4 test case. (11marks)
[Link] and disadvantages of BVA.
[Link] a short note on robust testing , worst case testing , special value testing (11marks)
[Link] in detail about the four test cases .(11marks)