UNIT-4

What is Software Testing

Software testing is a process of identifying the correctness of software by considering its all attributes (Reliability,
Scalability, Portability, Re-usability, Usability) and evaluating the execution of software components to find the
software bugs or errors or defects.

Why Software Testing is Important?

Software Testing is Important because if there are any bugs or errors in the software, it can be identified early
and can be solved before delivery of the software product. Properly tested software product ensures reliability,
security and high performance which further results in time saving, cost effectiveness and customer satisfaction.

What is the need of Testing?

Testing is important because software bugs could be expensive or even dangerous. Software bugs can potentially
cause monetary and human loss, and history is full of such examples.
•In April 2015, Bloomberg terminal in London crashed due to software glitch affected more than 300,000 traders
on financial markets. It forced the government to postpone a 3bn pound debt sale.
•Nissan cars recalled over 1 million cars from the market due to software failure in the airbag sensory detectors.
There has been reported two accident due to this software failure.
•Starbucks was forced to close about 60 percent of stores in the U.S and Canada due to software failure in its
POS system. At one point, the store served coffee for free as they were unable to process the transaction.
•Some of Amazon's third-party retailers saw their product price is reduced to 1p due to a software glitch. They
were left with heavy losses.
•Vulnerability in Windows 10. This bug enables users to escape from security sandboxes through a flaw in the
win32k system.
•In 2015 fighter plane F-35 fell victim to a software bug, making it unable to detect targets correctly.
•China Airlines Airbus A300 crashed due to a software bug on April 26, 1994, killing 264 innocents live
•In 1985, Canada's Therac-25 radiation therapy machine malfunctioned due to software bug and delivered lethal
radiation doses to patients, leaving 3 people dead and critically injuring 3 others.
•In April of 1999, a software bug caused the failure of a $1.2 billion military satellite launch, the costliest
accident in history
•In May of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited
with 920 million US dollars.
What are the benefits of Software Testing?
Here are the benefits of using software testing:
•Cost-Effective: It is one of the important advantages of software testing. Testing any IT project on time helps you
to save your money for the long term. In case if the bugs caught in the earlier stage of software testing, it costs less
to fix.
•Security: It is the most vulnerable and sensitive benefit of software testing. People are looking for trusted
products. It helps in removing risks and problems earlier.
•Product quality: It is an essential requirement of any software product. Testing ensures a quality product is
delivered to customers.
•Customer Satisfaction: The main aim of any product is to give satisfaction to their customers. UI/UX Testing
ensures the best user experience.
Software Testing Principles
Software testing is a procedure of implementing software or the application to identify the defects or bugs. For
testing an application or software, we need to follow some principles to make our product defects free, and that also
helps the test engineers to test the software with their effort and time. Here, in this section, we are going to learn
about the seven essential principles of software testing.
Testing Show Exhaustive
Let us see the seven different testing principles, one by the presence Testing is
one: of defects Impossible
1 2
1. Testing shows the presence of defects Early testing
The test engineer will test the application to make
Testing
3
sure that the application is bug or defects free. 7
While doing testing, we can only identify that the Absence of
application or software has any errors. The primary Error fallacy Defects Clustering
purpose of doing testing is to identify the numbers 4
of unknown bugs with the help of various methods
and testing techniques because the entire test
6
should be traceable to the customer requirement,
Testing is
which means that to find any defects that might
Context Pesticide paradox
cause the product failure to meet the client's needs. dependent 5
2. Exhaustive (entire) Testing is not possible
Sometimes it seems to be very hard to test all the modules and their features with effective and non- effective
combinations of the inputs data throughout the actual testing process.
Hence, instead of performing the exhaustive testing as it takes boundless determinations and most of the hard
work is unsuccessful. So we can complete this type of variations according to the importance of the modules
because the product timelines will not permit us to perform such type of testing scenarios

3. Early Testing
Here early testing means that all the testing activities should start in the early stages of the software development
life cycle's requirement analysis stage to identify the defects because if we find the bugs at an early stage, it will
be fixed in the initial stage itself, which may cost us very less as compared to those which are identified in the
future phase of the testing process.
To perform testing, we will require the requirement specification documents; therefore, if the requirements are
defined incorrectly, then it can be fixed directly rather than fixing them in another stage, which could be the
development phase.

4. Defect clustering
The defect clustering defined that throughout the testing process, we can detect the numbers of bugs which are
correlated to a small number of modules. We have various reasons for this, such as the modules could be
complicated; the coding part may be complex, and so on.
 5. Pesticide paradox
This principle defined that if we are executing the same set of test cases again and again over a particular time,
then these kinds of the test will not be able to find the new bugs in the software or the application. To get over
these pesticide paradoxes, it is very significant to review all the test cases frequently. And the new and different
tests are necessary to be written for the implementation of multiple parts of the application or the software, which
helps us to find more bugs

6. Testing is context-dependent
Testing is a context-dependent principle states that we have multiple fields such as e-commerce websites,
commercial websites, and so on are available in the market. There is a definite way to test the commercial site
as well as the e-commerce websites because every application has its own needs, features, and functionality. To
check this type of application, we will take the help of various kinds of testing, different technique, approaches,
and multiple methods. Therefore, the testing depends on the context of the application.

7. Absence of errors fallacy

Once the application is completely tested and there are no bugs identified before the release, so we can say that the
application is 99 percent bug-free. But there is the chance when the application is tested beside the incorrect
requirements, identified the flaws, and fixed them on a given period would not help as testing is done on the wrong
specification, which does not apply to the client's requirements. The absence of error fallacy means identifying and
fixing the bugs would not help if the application is impractical and not able to accomplish the client's requirements
and needs.
Objectives of Software Testing:

•Identification of bugs and errors

•Quality product

•Justification with requirement

•Offers confidence

•Enhances growth
 Type of Software testing
We have various types of testing available in the market, which are used to test the application or the software.
With the help of below image, we can easily understand the type of software testing:
Software Testing Types

Manual Automatic

White Box Testing Black Box Testing Gray Box Testing

Functional Non-Functional
Load Testing
Unit Testing Top Down Compatibility Testing Stress Testing
Integration
Bottom UP Performance Testing Scalability
System Testing Testing
User Acceptance Testing Usability Testing
Stability Testing
 Manual testing
The process of checking the functionality of an application as per the customer needs without taking any help of
automation tools is known as manual testing. While performing the manual testing on any application, we do
not need any specific knowledge of any testing tool, rather than have a proper understanding of the product so
we can easily prepare the test document.
Manual testing can be further divided into three types of testing, which are as follows:
• White box testing
• Black box testing
• Gray box testing

Why we need manual testing

Whenever an application comes into the market, and it is unstable or having a bug or issues or creating a problem
while end-users are using it.
If we don't want to face these kinds of problems, we need to perform one round of testing to make the application
bug free and stable and deliver a quality product to the client, because if the application is bug free, the end-user
will use the application more conveniently.
If the test engineer does manual testing, he/she can test the application as an end-user perspective and get more
familiar with the product, which helps them to write the correct test cases of the application and give the quick
feedback of the application.
 White Box Testing
In white-box testing, the developer will inspect every line of code before handing it over to the testing team or the
concerned test engineers.

In other words, we can say that the developer will execute the complete white-box testing for the particular
software and send the specific application to the testing team.
The purpose of implementing the white box testing is to emphasize the flow of inputs and outputs over the software
and enhance the security of an application.

Input
Output

White box testing is also known as open box testing, glass box testing, structural testing, clear box testing, and
transparent box testing.
Black Box Testing

Another type of manual testing is black-box testing. In this testing, the test engineer will analyze the software
against requirements, identify the defects or bug, and sends it back to the development team.

• Then, the developers will fix those defects, do one round of White box testing, and send it to the testing team.
• Here, fixing the bugs means the defect is resolved, and the particular feature is working according to the given
requirement.
• The main objective of implementing the black box testing is to specify the business needs or the customer's
requirements.
• In other words, we can say that black box testing is a process of checking the functionality of an application as
per the customer requirement. The source code is not visible in this testing; that's why it is known as black-
box testing.

Test Case Input

Test Case Output
 Types of Black Box Testing
Black box testing further categorizes into two parts, which are as discussed below:
Functional Testing
Non-function Testing

Functional Testing
The test engineer will check all the components systematically against requirement specifications, is known
as functional testing. Functional testing is also known as Component testing.
In functional testing, all the components are tested by giving the value, defining the output, and validating the actual
output with the expected value.
Functional testing is a part of black-box testing as it emphases on application requirement rather than actual
code. The test engineer has to test only the program instead of the system.

Types of Functional Testing

Just like another type of testing is divided into several parts, functional testing is also classified into
various categories.
The diverse types of Functional Testing contain the following:
• Unit Testing
• Integration Testing
• System Testing
 1. Unit Testing
Unit testing is the first level of functional testing in order to test
any software. In this, the test engineer will test the module of an
application independently or test all the module functionality is
called unit testing.
The primary objective of executing the unit testing is to confirm
the unit components with their performance. Here, a unit is
defined as a single testable function of a software or an
application. And it is verified throughout the specified application
development phase.

2. Integration Testing
Once we are successfully implementing the unit testing, we will go integration testing. It is the second level
of functional testing, where we test the data flow between dependent modules or interface between two
features is called integration testing.
The purpose of executing the integration testing is to test the statement's accuracy between each module.
Types of Integration Testing:
Integration testing is also further divided into the following parts:
•Incremental Testing
•Non-Incremental Testing
 Incremental Integration Testing
Whenever there is a clear relationship between modules, we go for
incremental integration testing. Suppose, we take two modules and
analysis the data flow between them if they are working fine or
not.
If these modules are working fine, then we can add one more
module and test again. And we can continue with the same process
to get better results.
In other words, we can say that incrementally adding up the
modules and test the data flow between the modules is known
as Incremental integration testing.

Types of Incremental Integration Testing

Incremental integration testing can further classify into
two parts, which are as follows:
1.Top-down Incremental Integration Testing
2.Bottom-up Incremental Integration Testing
Let's see a brief introduction of these types of integration testing:
1. Top-down Incremental Integration Testing
In this approach, we will add the modules step by step or incrementally and test the data flow between them. We
have to ensure that the modules we are adding are the child of the earlier ones.
2. Bottom-up Incremental Integration Testing
In the bottom-up approach, we will add the modules incrementally and check the data flow between modules. And
also, ensure that the module we are adding is the parent of the earlier ones.

Non-Incremental Integration Testing/ Big Bang Method

Whenever the data flow is complex and very difficult to classify a parent and a child, we will go for the non-
incremental integration approach. The non-incremental method is also known as the Big Bang method.

3. System Testing
Whenever we are done with the unit and integration testing, we can proceed with the system testing.
In system testing, the test environment is parallel to the production environment.
It is also known as end-to-end testing.
In this type of testing, we will undergo each attribute of the software and test if the end feature works
according to the business requirement. And analysis the software product as a complete system.
Acceptance Testing
When the software is ready to hand over to the customer it has to go through last phase of testing where it is tested
for user-interaction and response. This is important because even if the software matches all user requirements and
if user does not like the way it appears or works, it may be rejected.
•Alpha testing - The team of developer themselves perform alpha testing by using the system as if it is being
used in work environment. They try to find out how user would react to some action in software and how the
system should respond to inputs.
• Alpha Testing is a type of acceptance testing; performed to identify all possible issues and bugs before releasing
the final product to the end users. Alpha testing is carried out by the testers who are internal employees of the
organization. The main goal is to identify the tasks that a typical user might perform and test them.
• To put it as simple as possible, this kind of testing is called alpha only because it is done early on, near the end of
the development of the software, and before beta testing. The main focus of alpha testing is to simulate real users by
using a black box and white box techniques.

•Beta testing - After the software is tested internally, it is handed over to the users to use it under their production
environment only for testing purpose. This is not as yet the delivered product. Developers expect that users at this
stage will bring minute problems, which were skipped to attend.
Beta Testing is performed by "real users" of the software application in "real environment" and it can be
considered as a form of external User Acceptance Testing. It is the final test before shipping a product to the
customers. Direct feedback from customers is a major advantage of Beta Testing. This testing helps to test
products in customer's environment.
Beta version of the software is released to a limited number of end-users of the product to obtain feedback on the
product quality. Beta testing reduces product failure risks and provides increased quality of the product through
customer validation.

KEY DIFFERENCE BETWEEN ALPHA AND BETA

• Alpha Testing is performed by the Testers within the organization whereas Beta Testing is performed by
the end users.
• Alpha Testing is performed at Developer's site whereas Beta Testing is performed at Client's location.
• Reliability and Security testing are not performed in-depth in Alpha Testing while Reliability, Security
and Robustness are checked during Beta Testing.
• Alpha Testing involves both Whitebox and Blackbox testing whereas Beta Testing mainly involves
Blackbox testing.
• Alpha Testing requires testing environment while Beta Testing doesn't require testing environment.
• Alpha Testing requires long execution cycle whereas Beta Testing requires only few weeks of execution.
• Critical issues and bugs are addressed and fixed immediately in Alpha Testing whereas issues and bugs
are collected from the end users and further implemented in Beta Testing.
 Types of Beta Testing

There are different types of Beta tests in software testing, and they are as follows:
Traditional Beta testing: Product is distributed to the target market, and related data is gathered in all
aspects. This data can be used for Product improvement.

Public Beta Testing: Product is publicly released to the outside world via online channels and data can be
gathered from anyone. Based on feedback, product improvements can be done. For example, Microsoft
conducted the largest of all Beta Tests for its OS -- Windows 8 before officially releasing it.

Technical Beta Testing: Product is released to the internal group of an organization and gathers
feedback/data from the employees of the organization.

Focused Beta: Product is released to the market for gathering feedback on specific features of the program.
For example, important functionality of the software.

Post-release Beta: Product is released to the market and data is gathered to make improvements for the future
release of the product.
 Phases of Testing

Release
Pre-Alpha Alpha Beta Candidate Release
(RC)

Pre-Alpha:- Software is a prototype. UI is complete. But not all features are completed. At this stage, software
is not published.
Alpha: Software is near its development and is internally tested for bugs/issues
Beta: Software is stable and is released to a limited user base. The goal is to get customer feedback on the
product and make changes in software accordingly
Release Candidate (RC): Based on the feedback of Beta Test, you make changes to the software and want to
test out the bug fixes. At this stage, you do not want to make radical changes in functionality but just check for
bugs. RC is also put out to the public
Release: All works, software is released to the public.
 Advantages of Alpha Testing: Disadvantages of Alpha Testing:
• Provides better view about the reliability of the •In depth, functionality cannot be tested as software is
software at an early stage still under development stage Sometimes developers and
• Helps simulate real time user behaviour and testers are dissatisfied with the results of alpha testing
environment.
• Detect many showstopper or serious errors
• Ability to provide early detection of errors with
respect to design and functionality

Disadvantages of Beta Testing

Advantages of Beta Testing • Test Management is an issue. As compared to other
• Reduces product failure risk via customer validation. testing types which are usually executed inside a
• Beta Testing allows a company to test post-launch company in a controlled environment, beta testing is
infrastructure. executed out in the real world where you seldom have
• Improves product quality via customer feedback control.
• Cost effective compared to similar data gathering • Finding the right beta users and maintaining their
methods participation could be a challenge
• Creates goodwill with customers and increases
customer satisfaction
 Differences between the Alpha testing and Beta testing are

Sr. No. Alpha Testing Beta Testing

1. Alpha testing performed by a team of highly skilled testers who Beta testing performed by clients or end-users in a real-time environment, who is not an
are usually the internal employee of the organization. employee of the organization.

2. Alpha testing performed at the developer's site; it always needs a Beta testing doesn't need any lab environment or the testing environment; it is
testing environment or lab environment. performed at a client's location or end-user of the product.

3. Reliability or security testing not performed in-depth in alpha Reliability, security, and robustness checked during beta testing.
testing.
4. Alpha testing involves both white box and black-box techniques. Beta testing uses only black-box testing.
5. Long execution cycles maybe require for alpha testing. Only a few weeks are required for the execution of beta testing.

6. Critical issues or fixes can be identified by developers immediately Most of the issues or feedback is collecting from the beta testing will be implemented for
in alpha testing. the future versions of the product.

7. Alpha testing performed before the launch of the product into the At the time of software product marketing.
market.
8. Alpha testing focuses on the product's quality before going to Beta testing concentrates on the quality of the product, but gathers users input on the
beta testing. product and ensures that the product is ready for real-time users.

9. Alpha testing performed nearly the end of the software Beta testing is a final test before shipping a product to the customers.
development.
10. Alpha testing is conducting in the presence of developers and the Beta testing reversed of alpha testing.
absence of end-users.
 Non-function Testing
The next part of black-box testing is non-functional testing. It provides detailed information on software product
performance and used technologies.
Non-functional testing will help us minimize the risk of production and related costs of the software.
Non-functional testing is a combination of performance, load, stress, usability and, compatibility testing.
Types of Non-functional Testing
Non-functional testing categorized into different parts of testing, which we are going to discuss further:
• Performance Testing
• Usability Testing
• Compatibility Testing
1. Performance Testing
In performance testing, the test engineer will test the working of an application by applying some load.
In this type of non-functional testing, the test engineer will only focus on several aspects, such as Response time,
Load, scalability, and Stability of the software or an application.
Classification of Performance Testing
Performance testing includes the various types of testing, which are as follows:
• Load Testing
• Stress Testing
• Scalability Testing
• Load Testing
• Stability Testing
While executing the performance testing, we will
apply some load on the particular application to
Classification of Performance Testing check the application's performance, known
as load testing. Here, the load could be less than or
equal to the desired load.
It will help us to detect the highest operating
volume of the software and bottlenecks.
• Stress Testing
It is used to analyze the user-friendliness and robustness of the software beyond the common functional limits.
Primarily, stress testing is used for critical software, but it can also be used for all types of software applications.

• Scalability Testing
To analysis, the application's performance by enhancing or reducing the load in particular balances is known
as scalability testing.
In scalability testing, we can also check the system, processes, or database's ability to meet an upward need. And
in this, the Test Cases are designed and implemented efficiently.

• Stability Testing
Stability testing is a procedure where we evaluate the application's performance by applying the load for a precise
time.
It mainly checks the consistancy problems of the application and the efficiency of a developed product. In this
type of testing, we can rapidly find the system's defect even in a stressful situation.
2. Usability Testing
Another type of non-functional testing is usability testing. In usability testing, we will analyze the user-
friendliness of an application and detect the bugs in the software's end-user interface.
Here, the term user-friendliness defines the following aspects of an application:
• The application should be easy to understand, which means that all the features must be visible to end-users.
• The application's look and feel should be good that means the application should be pleasant looking and make
a feel to the end-user to use it.

3. Compatibility Testing
In compatibility testing, we will check the functionality of an application in specific hardware and software
environments. Once the application is functionally stable then only, we go for compatibility testing.
Here, software means we can test the application on the different operating systems and other browsers,
and hardware means we can test the application on different sizes.
3. Grey Box Testing
Another part of manual testing is Grey box testing. It is a collaboration of black box and white box testing.
Since, the grey box testing includes access to internal coding for designing test cases. Grey box testing is
performed by a person who knows coding as well as testing.

Black
Box
+ White = Grey Box
Testing
Box

In other words, we can say that if a single-person team done both white box and black-box testing, it is
considered grey box testing.
 Black Box Testing vs. White Box Testing vs. Grey Box
Testing
Index Black Box Testing White Box Testing Grey Box Testing

1 Knowledge of internal working structure (Code) is Knowledge of internal working structure (Coding Partially Knowledge of the internal
not required for this type of testing. Only GUI of software) is necessarily required for this type of working structure is required.
(Graphical User Interface) is required for test testing.
cases.

2 Black Box Testing is also known as functional White Box Testing is also known as structural Grey Box Testing is also known as
testing, data-driven testing, and closed box testing, clear box testing, code-based testing, and translucent testing as the tester has
testing. transparent testing. limited knowledge of coding.

3 The approach towards testing includes trial White Box Testing is proceeded by verifying the If the tester has knowledge of
techniques and error guessing method because system boundaries and data domains inherent in coding, then it is proceeded by
tester does not need knowledge of internal the software as there is no lack of internal coding validating data domains and internal
coding of the software. knowledge. system boundaries of the software.

4 The testing space of tables for inputs (inputs to be The testing space of tables for inputs (inputs to be The testing space of tables for
used for creating test cases) is pretty huge and used for creating test cases) is less as compared to inputs (inputs to be used for
largest among all testing spaces. Black Box testing. creating test cases) is smaller than
Black Box and White Box testing.

5 It is very difficult to discover hidden errors of the It is simple to discover hidden errors because it Difficult to discover the hidden
software because errors can be due to internal can be due to internal working which is deeply error. Might be found in user level
working which is unknown for Black Box testing. explored in White Box testing. testing.
Index Black Box Testing White Box Testing Grey Box Testing
6 It is not considered for algorithm testing. It is well suitable and recommended It is not considered for algorithm testing.
for algorithm testing.

7 Time consumption in Black Box testing depends White Box testing takes a long time Test cases designing can be done in a short time
upon the availability of the functional to design test cases due to lengthy period.
specifications. code.

8 Tester, developer and the end user can be the part Only tester and developer can be a Tester, developer and the end user can be the part
of testing. part of testing; the end user can not of testing.
involve.

9 It is the least time-consuming process among all The entire testing process is the most less time consuming than White Box testing.
the testing processes. time consuming among all the testing
processes.

10 Resilience and security against viral attacks are Resilience and security against viral Resilience and security against viral attacks are not
covered under Black Box testing. attacks are not covered under White covered under Grey Box testing.
Box testing.

11 The base of this testing is external expectations The base of this testing is coding Testing based on high-level database diagrams and
internal behavior is unknown. which is responsible for internal dataflow diagrams.
working.

12 It is less exhaustive than White Box and Grey Box It is most exhaustive between Black Partly exhaustive; depends upon the type of test
testing methods. Box and Grey Box testing methods. cases are coding based or GUI based.
Software Testing Life Cycle (STLC)
The procedure of software testing is also known as STLC
(Software Testing Life Cycle) which includes phases of the testing
process. The testing process is executed in a well-planned and
systematic manner. All activities are done to improve the quality of
the software product.
Let's see, the different steps of STLC.

Requirement Analysis

Test plan creation

Environment setup Requirement Analysis:
Test case execution The first step of the manual testing procedure is
requirement analysis. In this phase, tester analyses
Defect logging
requirement document of SDLC (Software Development
Test cycle closure Life Cycle) to examine requirements stated by the client.
After examining the requirements, the tester makes a test
plan to check whether the software is meeting the
requirements or not.
 Entry Criteria Activities Deliverable
For the planning of test plan requirement Prepare the list of all requirements and queries, List of all the necessary tests for the testable
specification, application architecture and get resolved from Technical Manager/Lead, requirements and Test environment details
document and well-defined acceptance criteria System Architecture, Business Analyst and
should be available. Client.
Make a list of all types of tests (Performance,
Functional and security) to be performed.
Make a list of test environment details, which
should contain all the necessary tools to execute
test cases.

Test Plan Creation:

Test plan creation is the crucial phase of STLC where all the testing strategies are defined. Tester determines the
estimated effort and cost of the entire project. This phase takes place after the successful completion of
the Requirement Analysis Phase. Testing strategy and effort estimation documents provided by this phase. Test
case execution can be started after the successful completion of Test Plan Creation.
 Entry Criteria Activities Deliverable
Requirement Document Define Objective as well as the scope of the software. Test strategy document.
List down methods involved in testing. Testing Effort estimation documents are the
Overview of the testing process. deliverables of this phase.
Settlement of testing environment.
Preparation of the test schedules and control procedures.
Determination of roles and responsibilities.
List down testing deliverables, define risk if any.

Environment setup:
Setup of the test environment is an independent activity and can be started along with Test Case Development.
This is an essential part of the manual testing procedure as without environment testing is not possible.
Environment setup requires a group of essential software and hardware to create a test environment. The testing
team is not involved in setting up the testing environment, its senior developers who create it.

Entry Criteria Activities Deliverable

Test strategy and test plan document. Prepare the list of software and hardware by Execution report.
Test case document. analyzing requirement specification. Defect report.
Testing data. After the setup of the test environment,
execute the smoke test cases to check the
readiness of the test environment.
 Test case Execution:
Test case Execution takes place after the successful completion of test planning. In this phase, the testing team
starts case development and execution activity. The testing team writes down the detailed test cases, also prepares
the test data if required. The prepared test cases are reviewed by peer members of the team or Quality Assurance
leader.
RTM (Requirement Traceability Matrix) is also prepared in this phase. Requirement Traceability Matrix is industry
level format, used for tracking requirements. Each test case is mapped with the requirement specification.
Backward & forward traceability can be done via RTM.

Entry Criteria Activities Deliverable

Requirement Document Creation of test cases. Test execution result.
Execution of test cases. List of functions with the detailed explanation
Mapping of test cases according to requirements. of defects.

Defect Logging:
Testers and developers evaluate the completion criteria of the software based on test coverage, quality, time
consumption, cost, and critical business objectives. This phase determines the characteristics and drawbacks of the
software. Test cases and bug reports are analyzed in depth to detect the type of defect and its severity.
Defect logging analysis mainly works to find out defect distribution depending upon severity and types.If any
defect is detected, then the software is returned to the development team to fix the defect, then the software is re-
tested on all aspects of the testing.
Entry Criteria Activities Deliverable
Test case execution report. It evaluates the completion criteria of the software Closure report
Defect report based on test coverage, quality, time consumption, Test metrics
cost, and critical business objectives.
Defect logging analysis finds out defect distribution
by categorizing in types and severity.

Test Cycle Closure:

The test cycle closure report includes all the documentation related to software design, development, testing results,
and defect reports.
This phase evaluates the strategy of development, testing procedure, possible defects in order to use these practices
in the future if there is a software with the same specification.

Entry Criteria Activities Deliverable

All document and reports related to Evaluates the strategy of development, Test closure report
software. testing procedure, possible defects to use
these practices in the future if there is a
software with the same specification
 What is a Test Plan?
A software product, once developed and tested completely, is prepared for its
release, during which various documents, reports, screenshots, etc. are also
delivered to the client and other stakeholders of the project. Known
as deliverables, these documents and reports are an integral part of software
development life cycle (SDLC), as they necessary information related to the
product to the concerned individual. Test plan is one such important testing
deliverable offered during the release of the product . Therefore, let us understand
the significance of test plan, with the assistance of the following discussion.
Among the various deliverables delivered to the client after the completion of the project, a test plan is the most
important document. It encompasses all the activities performed during the testing process
In short, a test plan is a document is considered to be a pre-planned blueprint of everything that is
required to make the testing process complete, successful and executed on time.
Different Types of Test Plan:
Test plans are classified according to the testing types, level, and the size of the test plan and are of three types.
These test plans define high-level details about the software testing techniques as well as its process. Hence, the
three types of test plans are:
 • Level specific test plans: These include Unit test plan, Integration test plan and system test plan.
• Type specific test plan: these include plans for major parameters like performance testing plan.
• Master test plan: This is one single big plan combining all the other plans to be carried out on the software
product.
Features of a Test Plan:
Often known as master test plan or project test plan document, test plan outlines various components of the testing
process, such as the test strategy, test estimation, deliverables, etc., which helps the client and other stakeholders to
get a deeper insight into the testing process. Other important features of a test plan are:
• It is an important guide that is used to ensure the success of the project.
• Serves as a blueprint to conduct software test, while minutely monitoring and controlling the process.
• Helps the testing team to control various risks associated with the testing process.
• It serves as a means of communication across the software team.
• With the assistance of a test plan, the team can track the changes in the testing process and make necessary
adjustments.

Test Plan Template:

A test plan can vary from one project to another. However, while creating a test plan, the testing team or the test
management team ensures that it follows a set template, which allows them to log all the necessary details about
the testing process in the document. Defined by the standard IEEE 829, a test plan template constitutes of the
following details:
Every test plan consists of a fixed set of parameters, the brief description of whose is given below:

1. Test Identifier: A test identifier is nothing but an identifying reference unique to the document.
2. Introduction: The introduction is a brief overview of the scope and adjectives of the test to be conducted.
It also specifies the constraints related to the testing exercise.
3. References: This contains links to documents related to the test plan such as the project report or the test
configuration management plan.
4. Test items: Test items are the software entities related to the application under test.
5. Features not to be tested: They are those items which have been excluded from the realm of testing.
Under this, reasons for their omission are also mentioned.
6. Testing approach: This raises questions related to selection of strategy for testing. Be it black box/ white
box testing. This also includes decisions pertaining to the use of automation testing or sticking with manual
testing.
7. Pass/fail criteria: This is the documentation of those parts of the software product under test which have
passed or failed, upon the administration of test cases.
8. Suspension and resumption criteria: It is used for specifying a criteria in the form of limits for a certain
percentage of test cases which fail and beyond which the testing has to suspend temporarily until the resolution of
all issues.
9. Test deliverables: Includes the tools and documents developed, used and maintained for the testing process.
Their types are:
1. Deliverables provided before the Test the Testing Phase: Documents related to test cases and the test
design specifications.
2. Deliverables provided during the Test Phase: These include the simulators, bug logs, traceability matrices
and execution logs.
3. Deliverables for Post Testing Phase: These are the defect reports, test results and the test procedure
guideline with release notes.
10. Testing Tasks: All the tasks related to planning and execution of test cases.
11. Environmental needs: The environment is the platform of software and hardware on which the test cases are
carried out. It is also the landscape where the real user or business settings are simulated for testing the software
product on different servers, back/front end environment, different operating systems and the like. Requires
interaction between developers and testers for setting up of environment.
12. Roles and responsibilities: This aspect is related to assigning responsibilities in the form of project schedules
and deadlines to individuals as well as team leaders and managers.
How to Write a Good Test Plan?
The template defined above has made the process of creating a test plan easy. However, it is essential to create an
effective test plan that offers all the relevant information, as this document is delivered not only to the client, but at
times to the customer also. Therefore, to help you write a good test plan, here are some important points.
• Conduct product analysis.
• Develop an efficient test strategy.
• Define and allocate roles and responsibilities.
• Calculate all the anticipated risks.
• Develop a schedule for testing.
• Plan and prepare test environment.
 Test Suite

test suite is the accumulation of test cases that will be run in a test progression until
some stopping criteria are met.

Test suite preparation involves the construction and allocation of test cases in some systematic way based on the specific testing
techniques used. For instance, when usage-based statistical testing is planned, the test case allocation will be defined by the
operational profiles created as the testing models.
Also known as “validation suite,” a test suite is a collection of various test cases that are intended to test a software
product or its specific functionality/feature, once the software development is accomplished.
Features of Test Suite:
Test suites offers various advantages to the team of testers as well as the organization they are working for.
Therefore, to offer you a better insight into its qualities, mentioned below are some of its important features:
1. Test suites are created after test plan.
2. It includes a number of tests and test cases.
3. Describes the goals and objective of test cases.
4. It has test parameters, such as application, environment, version, etc.
5. One can create test suites on the basis of the test cycle as well as the test scope.
6. It consists of various types of tests, such as functional or non-functional.
 Test Test
Case-1 Case-2
Test Suit-1
Test Test
Case-3 Case-4

Test Test
Test Plan Test Suit-2 Case-1 Case-2

Test Test
Test Suit-3 Case-1 Case-2

Test
Case-3

Test Suites Types:

Typically, test suites are divided into two types, with distinct functioning. These also describe the importance as
well as the usability of test suite in software testing life cycle. Hence, the type of test suites are:
1. Abstract Test Suite: The abstract test suite is a part of model-based testing, that can be defined as a
collection of abstract test cases, which are taken from a high-level model of the system under test (SUT).
These cannot be used directly by the team on the software, as they remain constantly at the high-level and lack
concrete details about the software and the environment.
2. Executable Test Suite: Executable test suite is the second type of test suite, which is derived from abstract
test cases. It provides the basic, low-level information that is required to execute a test suite program. This type
of test suite works on a sufficiently detailed level and it correctly communicates with the software under test.
Moreover, it has a test harness that interfaces the executable test suite with the software under test (SUT).
Test Suite Template:
Since the importance of test suite is immense in Software Development Life Cycle (SDLC), it is vital for
software testers to follow a standardized template to create test suite and define the various aspects covered by
it. These templates can either be predefined or can be created by the team as per the requirements of their
project. Hence, to help you with the process, here is a sample of test suite template.
•Test Suite Summary: As suggested by the title, this section of the template consists of a detailed summary of
the test suite. It might also include categories of test suites, to further improve the comprehensiveness of the test
suite.
• Test Suite Design: Again, this section offers details about the design of the test suite, along with various
suggestions to enhance the quality and coverage of the testing.
• Formal Review: Once the test suite summary and design are defined, the team performs a formal review,
which helps organizations in making their business processes conform to standards and regulations of the
industry.
• Pre-condition & Post-condition: These define and check the various requirements that are needed to be
fulfilled before and after executing test suite.
•Expected Results: Here, the team defines the conditions that are required to be fulfilled for a test suite to be
considered successful. These expected results are then compared with the actual result to further validate the
success of a test suite.
Example of Test Suite:
To help you better understand the significance of test suite, following is an example that aptly reflects its
importance during software testing.
An application has some metrics:
Current version: 2.2
Previous version 2.1 has 500 test cases.
For version 2.2, there are 300 test cases to test the new functionality.
Therefore, the current test case has: 500+ 300 = 800 test cases, including regression testing and new
functionality. Thus, Test suites can generate several test cases for each different requirement.
 Test Case

The test case is defined as a group of conditions under which a tester determines whether a software application
is working as per the customer's requirements or not. Test case designing includes preconditions, case name,
input conditions, and expected result. A test case is a first level action and derived from test scenarios.

It is an in-details document that contains all possible inputs (positive as well as negative) and the navigation steps,
which are used for the test execution process. Writing of test cases is a one-time attempt that can be used in the
future at the time of regression testing.
Test case gives detailed information about testing strategy, testing process, preconditions, and expected output.
These are executed during the testing process to check whether the software application is performing the task for
that it was developed or not.
Test case helps the tester in defect reporting by linking defect with test case ID. Detailed test case documentation
works as a full proof guard for the testing team because if developer missed something, then it can be caught
during execution of these full-proof test cases.
To write the test case, we must have the requirements to derive the inputs, and the test scenarios must be written so
that we do not miss out on any features for testing. Then we should have the test case template to maintain the
uniformity, or every test engineer follows the same approach to prepare the test document.
When do we write a test case?
We will write the test case when we get the following:
• When the customer gives the business needs then, the developer starts developing and says that they need 3.5
months to build this product.
• And In the meantime, the testing team will start writing the test cases.
• Once it is done, it will send it to the Test Lead for the review process.
• And when the developers finish developing the product, it is handed over to the testing team.
• The test engineers never look at the requirement while testing the product document because testing is constant
and does not depends on the mood of the person rather than the quality of the test engineer.

Why we write the test cases?

We will write the test for the following reasons:
• To require consistency in the test case execution
• To make sure a better test coverage
• It depends on the process rather than on a person
• To avoid training for every new test engineer on the product
• To require consistency in the test case execution: we will see the test case and start testing the
application.
• To make sure a better test coverage: for this, we should cover all possible scenarios and document it,
so that we need not remember all the scenarios again and again.
 How to Write Test Cases in Manual Testing

Test Case # Test Case Description Test steps

Test Case Data Test Case Data
Step 1) A simple test case to
explain the scenario would be 1 Check response when valid email 1) [email protected]
Email: Email Address Email: [email protected] P
and password is entered 2) Enter Password
m Password: lNf9Oti72h assword: lNf9Oti72h
3) Click Sign in

Step 2) In order to execute the test

case, you would need Test Data.
Adding it below
Identifying test data can be time-consuming and
may sometimes require creating test data afresh.
The reason it needs to be documented.

Step 3) In order to execute a test case, a tester needs to

perform a specific set of actions on the AUT. This is
documented as below:
 Test Test Case Description Test Data Expected
Step 4) The goal of test cases in software testing Case # Result
is to check behaviour of the AUT for an expected 1 Check response when valid Email: [email protected] Login should
result. This needs to be documented as below email and password is entered Password: lNf9^Oti7^2h be successful

During test execution time, the tester will check

expected results against actual results and assign a
pass or fail status Test Test Case Description Test Data Expected Actual Pass/Fail
Case # Result Result
1 Check response when Email: [email protected] Login should be Login was Pass
valid email and Password: lNf9^Oti7^2h successful successful
password is entered
The format of Standard Test Cases
Test Test Scenario Test Steps Test Data Expected Results Actual Results Pass/Fail
Case ID

TU01 Check Customer 1.Go to site Userid = guru99 User should Login As Expected Pass
Login with valid Data http://demo.guru99.com Password = pass99 into an application
2. Enter UserId
3. Enter Password
4. Click Submit
TU02 Check Customer 1.Go to Userid = guru99 User should not As Expected Pass
Login with invalid site http://demo.guru99.com Password = glass99 Login into an
Data 2.Enter UserId application
3.Enter Password
4.Click Submit
While drafting a test case to include the following information
• The description of what requirement is being tested
• The explanation of how the system will be tested
• The test setup like a version of an application under test, software, data files, operating system, hardware,
security access, physical or logical date, time of day, prerequisites such as other tests and any other setup
information pertinent to the requirements being tested
• Inputs and outputs or actions and expected results
• Any proofs or attachments
• Use active case language
• Test Case should not be more than 15 steps
• An automated test script is commented with inputs, purpose and expected results
• The setup offers an alternative to pre-requisite tests
• With other tests, it should be an incorrect business scenario order
Best Practice for writing good Test Case Example.
1. Test Cases need to be simple and transparent:
Create test cases that are as simple as possible. They must be clear and concise as the author of the test case
may not execute them.
Use assertive language like go to the home page, enter data, click on this and so on. This makes the
understanding the test steps easy and tests execution faster.
2. Create Test Case with End User in Mind
The ultimate goal of any software project is to create test cases that meet customer requirements and is easy to
use and operate. A tester must create test cases keeping in mind the end user perspective
3. Avoid test case repetition.
Do not repeat test cases. If a test case is needed for executing some other test case, call the test case by its test
case id in the pre-condition column
4. Do not Assume
Do not assume functionality and features of your software application while preparing test case. Stick to the
Specification Documents.

5. Ensure 100% Coverage

Make sure you write test cases to check all software requirements mentioned in the specification document.
Use Traceability Matrix to ensure no functions/conditions is left untested.
6. Test Cases must be identifiable.
Name the test case id such that they are identified easily while tracking defects or identifying a software
requirement at a later stage.
7. Implement Testing Techniques
It's not possible to check every possible condition in your software application. Software Testing techniques help
you select a few test cases with the maximum possibility of finding a defect.
1. Boundary Value Analysis (BVA): As the name suggests it's the technique that defines the testing of
boundaries for a specified range of values.
2. Equivalence Partition (EP): This technique partitions the range into equal parts/groups that tend to have the
same behavior.
3. State Transition Technique: This method is used when software behavior changes from one state to another
following particular action.
4. Error Guessing Technique: This is guessing/anticipating the error that may arise while doing manual testing.
This is not a formal method and takes advantages of a tester's experience with the application
8. Self-cleaningThe test case you create must return the Test Environment to the pre-test state and should not
render the test environment unusable. This is especially true for configuration testing.
Boundary Value Analysis
Boundary value analysis is one of the widely used case design technique for black box testing. It is used to test boundary values
because the input values near the boundary have higher chances of error.
Whenever we do the testing by boundary value analysis, the tester focuses on, while entering boundary value whether the
software is producing correct output or not.
Boundary values are those that contain the upper and lower limit of a variable. Assume that, age is a variable of any function,
and its minimum value is 18 and the maximum value is 30, both 18 and 30 will be considered as boundary values.
Testing of boundary values is done by making valid and invalid partitions. Invalid partitions are tested because testing of
output in adverse condition is also essential
Example:
Imagine, there is a function that accepts a number between 18 to 30, where 18 is the minimum and 30 is the maximum value
of valid partition, the other values of this partition are 19, 20, 21, 22, 23, 24, 25, 26, 27, 28 and 29. The invalid partition
consists of the numbers which are less than 18 such as 12, 14, 15, 16 and 17, and more than 30 such as 31, 32, 34, 36 and 40.
Tester develops test cases for both valid and invalid partitions to capture the behavior of the system on different input
conditions.
The software system will be passed in the
Invalid Test Case Valid Test Case Invalid Test Case test if it accepts a valid number and gives the
(Examples) (Examples) desired output, if it is not, then it is
1,5,8,12,14,16,117 18,19,23,25,26,28,30 31,34,45,67,78,90 unsuccessful. In another scenario, the
software system should not accept invalid
numbers, and if the entered number is
invalid, then it should display error massage.
Equivalence Partitioning Technique
Equivalence partitioning is a technique of software testing in which input data is divided into partitions of valid
and invalid values, and it is mandatory that all partitions must exhibit the same behavior. If a condition of one
partition is true, then the condition of another equal partition must also be true, and if a condition of one partition is
false, then the condition of another equal partition must also be false. The principle of equivalence partitioning is,
test cases should be designed to cover each partition at least once. Each value of every equal partition must exhibit
the same behavior as other.
The equivalence partitions are derived from requirements and specifications of the software. The advantage of this
approach is, it helps to reduce the time of testing due to a smaller number of test cases from infinite to finite. It is
applicable at all levels of the testing process.
Examples:
Assume that there is a function of a software application that accepts a particular number of digits, not greater and
less than that particular number. For example, an OTP number which contains only six digits, less or more than six
digits will not be accepted, and the application will redirect the user to the error page.

INVALID INVALID VALID VALID

1 Test case 2 Test Case 3 Test case 4 Test case
DIGITS >= 7 DIGITS <= 5 DIGITS = 6 DIGITS= 6
4567382 45632 345678 238976
Let's see one more example.
A function of the software application accepts a 10 digit mobile number.

INVALID INVALID VALID VALID

1 Test case 2 Test Case 3 Test case 4 Test case
DIGITS >= 11 DIGITS <= 9 DIGITS = 10 DIGITS= 10
98754632123 98765432 9834562178 8765439612

In both examples, we can see that there is a partition of two equally valid and invalid partitions, on applying
valid value such as OTP of six digits in the first example and mobile number of 10 digits in the second example,
both valid partitions behave same, i.e. redirected to the next page.
Another two partitions contain invalid values such as 5 or less than 5 and 7 or more than 7 digits in the first
example and 9 or less than 9 and 11 or more than 11 digits in the second example, and on applying these invalid
values, both invalid partitions behave same, i.e. redirected to the error page.

How we perform equivalence partitioning

We can perform equivalence partitioning in two ways which are as follows:
 Condition1
If the requirement is a range of values, then derive the
test case for one valid and two invalid inputs.
Here, the Range of values implies that whenever we
want to identify the range values, we go for equivalence
partitioning to achieve the minimum test coverage. And
after that, we go for error guessing to achieve maximum
test coverage.

According to pressman:
For example, the Amount of test field accepts a Range (100-400) of values:
 According to General Practice method:
Whenever the requirement is Range + criteria, then divide the Range into the internals and check for all these
values.
For example:

In the below image, the pressman technique is enough to test for an age text field for one valid and two invalids.
But, if we have the condition for insurance of ten years and above are required and multiple policies for various age
groups in the age text field, then we need to use the practice method.
Condition 3
If the requirement id Boolean (true/false), then derive the test case for both true/false values.
The Boolean value can be true and false for the radio button, checkboxes.

Serial Description Input Expected Note

no
1 Select valid NA True ---
2 Select invalid NA False Values can be
change based
according to
the
requirement.
3 Do not select NA Do not select We cannot go
anything, error for next
message should question
be displayed

4 Select both NA We can select Only one radio

any radio button can be
button selected at a
time.
 Stubs and Drivers
In software testing life cycle, there are numerous components that play a prominent part in making the process of
testing accurate and hassle free. Every element related to testing strives to improve its quality and helps deliver
accurate and expected results and services that are in compliance with the defined specifications. Stubs and
drivers are two such elements used in software testing process, which act as a temporary replacement for a
module. These are an integral part of software testing process as well as general software development.
Therefore, to help you understand the significance of stubs and drivers in software testing, here is elaborated
discussion on the same.

Stubs Drivers
Modules
 What is meant by Stubs and Drivers?
In the field of software testing, the term stubs and drivers refers to the replica of the modules, which acts as a
substitute to the undeveloped or missing module. The stubs and drives are specifically developed to meet the
necessary requirements of the unavailable modules and are immensely useful in getting expected results.

Stubs and drivers are two types of test harness, which is a collection of software and test that is configured
together in order to test a unit of a program by stimulating variety of conditions while constantly monitoring its
outputs and behaviour. Stubs and drivers are used in top-down integration and bottom-up integration testing
respectively and are created mainly for the testing purpose.

Defining Stubs:
Stubs are used to test modules and are created by the team of testers during the process of Top-Down Integration
Testing. With the assistance of these test stubs testers are capable of stimulating the behaviour of the lower level
modules that are not yet integrated with the software. Moreover, it helps stimulates the activity of the missing
components.
Types of Stubs:
There are basically four types of stubs used in top-down approach of integration
testing, which are mentioned below:

• Displays the trace message.

• Values of parameter is displayed.
• Returns the values that are used by the modules.
• Returns the values selected by the parameters that were used by modules being
tested.

Defining Drivers:
Drivers, like stubs, are used by software testers to fulfil the requirements of missing or incomplete components and
modules. These are usually complex than stubs and are developed during Bottom-Up approach of Integration
Testing. Drivers can be utilized to test the lower levels of the code, when the upper level of codes or modules are
not developed. Drivers act as pseudo codes that are mainly used when the stub modules are ready, but the primary
modules are not ready.

Stubs and Drivers: Example

Consider an example of a web application, which consists of 4 modules i.e., Module-A, Module-B, Module-C and
Module-D. Each of the following modules is responsible for some specific activity or functionality, as under:
 Module-A ? Login page of the web application.
Module-B → Home page of the web application.
Module-C → Print Setup.
Module-D → Log out page.
modules A, B, C & D involves the interdependencies of each module over other.

It is always preferable, to perform testing, in parallel, to the development process. Thus, it implies that subsequent
testing must be carried out, immediately after the development of the each module.
Module-A will be tested, as soon as, it develops. However, to carry out and validate the testing procedures in
respect of module-A, there urges the need of Module-B, which is not yet developed. The expected functionality of
the login page (module-A) could be validated, only if it is directed to the home page (Module-B), based on the
valid and correct inputs.
But, on the non-availability of the Module-B, it will not be possible to test module-A. These types of
circumstances, introduces the stubs & drivers in the process of software testing. A dummy module, representing
the basic functionality or feature of the module-B, is being developed, and thereafter, it is being integrated with the
module-A, to perform testing, efficiently.
Similarly, stubs and drivers, are used to fulfil the requirements of other modules,
Why are Stubs & Drivers Required?
Though, the important of stubs and drivers is immense during software testing, but its relevance as well as the
requirement ends once the equivalent module is created. As they act as a temporary replacement of modules, these
role in testing culminates once final output is generated. Therefore, these pseudo modules or stubs and drivers are
mainly used for following reasons:
1. Commonly used in porting, distributed computing, as well as general software development.
2. Used for meeting necessary requirements unavailable modules.
3. They are required when the system needs to interact with external systems.
4. Stubs and drivers are used to test modules.
5. Stubs are used to test the functionality of modules, whereas drivers are used when the main module is not ready.

Key Points: Stubs and Drivers

1. Stubs and Drivers works as a substitute for the missing or unavailable module.
2. They are specifically developed, for each module, having different functionalities.
3. Generally, developers and unit testers are involved in the development of stubs and drivers.
4. Although, it provides ease to carry out of individual components, without concerning the availability of other
modules, but it is a time-consuming process, as it requires to develop dummy for each missing module.
5. Their most common use may be seen in the integration incremental testing, where stubs are used in top bottom
approach and drivers in a bottom up approach.
Comparison of Stubs & Drivers:
Even though both stubs and drivers are dummy/pseudo codes, there are various features of these two components
that are different from each other. Therefore, to signify their differences, here is a comparison of stubs and drivers.

Stubs Drivers
1. Used in Top-Down Integration Testing. 1.Used in Bottom-Up Integration Testing.

2. A piece of code that emulates the called function. 2. A piece of code that emulates a calling function.

3. Stubs stimulates the activity of missing and not 3. Drivers pass test cases to another code and invoke
developed modules. modules under testing.

4. These are created when high level modules are 4. These are created when lower level modules are
tested and lower level modules are not developed. tested and higher level modules are not yet developed.
As a tester, you may think that ‘Designing Test cases is challenging enough, then why bother about
something as trivial as Test Data’. The purpose of this tutorial is to introduce you to Test Data, its importance
and give practical tips and tricks to generate test data quickly. So, let's Begin!

What is Test Data in Software Testing?

Test Data in Software Testing is the input given to a software program during test execution. It represents data
that affects or affected by software execution while testing. Test data is used for both positive testing to verify that
functions produce expected results for given inputs and for negative testing to test software ability to handle
unusual, exceptional or unexpected inputs.
Poorly designed testing data may not test all possible test scenarios which will hamper the quality of the software.

Typically test data is created in-sync with the test case it is intended to be used for.
Test Data can be Generated -
• Manually
• Mass copy of data from production to testing environment
• Mass copy of test data from legacy client systems
• Automated Test Data Generation Tools
• Typically sample data should be generated before you begin test execution because it is difficult to handle
test data management otherwise. Since in many testing environments creating test data takes multiple pre-
steps or very time-consuming test environment configurations. . Also If test data generation is done while
you are in test execution phase you may exceed your testing deadline.
Test Data for White Box Testing
In White Box Testing, test data Management is derived from direct examination of the code to be tested.
Test data may be selected by taking into account the following things:
• It is desirable to cover as many branches as possible; testing data can be generated such that all branches
in the program source code are tested at least once
• Path testing: all paths in the program source code are tested at least once - test data preparation can done
to cover as many cases as possible
• Negative API Testing:
• Testing data may contain invalid parameter types used to call different methods
• Testing data may consist in invalid combinations of arguments which are used to call the program's
methods
Test Data for Black Box Testing
In Black Box Testing the code is not visible to the tester. Your functional test cases can have test data meeting
following criteria -
• No data: Check system response when no data is submitted
• Valid data: Check system response when Valid test data is submitted
• Invalid data: Check system response when InValid test data is submitted
• Illegal data format: Check system response when test data is in an invalid format
• Boundary Condition Dataset: Test data meeting boundary value conditions
• Equivalence Partition Data Set: Test data qualifying your equivalence partitions.
• Decision Table Data Set: Test data qualifying your decision table testing strategy
• State Transition Test Data Set: Test data meeting your state transition testing strategy
• Use Case Test Data: Test Data in-sync with your use cases.
Test Data for Security Testing
Security Testing is the process that determines if an information system protects data from malicious intent. The set
of data that need to be designed in order to fully test a software security must cover the following topics:
• Confidentiality: All the information provided by clients is held in the strictest confidence and is not shared with
any outside parties. As a short example, if an application uses SSL, you can design a set of test data which
verifies that the encryption is done correctly.
• Integrity: Determine that the information provided by the system is correct. To design suitable test data you can
start by taking an in-depth look at the design, code, databases and file structures.
• Authentication: Represents the process of establishing the identity of a user. Testing data can be designed as a
different combination of usernames and passwords and its purpose is to check that only the authorized people
are able to access the software system.
• Authorization: Tells what are the rights of a specific user. Testing data may contain a different combination of
users, roles and operations in order to check only users with sufficient privileges are able to perform a particular
operation.

Testing Documentation
Testing documentation is the documentation of artifacts that are created during or before the testing of a software
application. Documentation reflects the importance of processes for the customer, individual and organization.
Projects which contain all documents have a high level of maturity. Careful documentation can save the time,
efforts and wealth of the organization.
There is the necessary reference document, which is prepared by every test engineer before stating the test
execution process. Generally, we write the test document whenever the developers are busy in writing the code.
Once the test document is ready, the entire test execution process depends on the test document. The primary
objective for writing a test document is to decrease or eliminate the doubts related to the testing activities.

Types of test document Test Test

Execution Scenarios
In software testing, we have various types report
of test document, which are as follows: Test
• Test scenarios Case
• Test case Bug
• Test plan Report Testing
Documentation
• Requirement traceability matrix(RTM) Test
Plan
• Test strategy
• Test data
Test
• Bug report Data
Requirement
Traceability
• Test execution report Matrix
Test
Strategy (RTM)
Test Scenario
The test scenario is a detailed document of test cases that cover end to end functionality of a software application
in liner statements. The liner statement is considered as a scenario. The test scenario is a high-level classification
of testable requirements. These requirements are grouped on the basis of the functionality of a module and
obtained from the use cases.
In the test scenario, there is a detailed testing process due to many associated test cases. Before performing the test
scenario, the tester has to consider the test cases for each scenario.
In the test scenario, testers need to put themselves in the place of the user because they test the software
application under the user's point of view. Preparation of scenarios is the most critical part, and it is necessary to
seek advice or help from customers, stakeholders or developers to prepare the scenario.

Test
Case

Test
Test Test Case
Document Scenario

Test
Case
 Test case
It is an in-details document that describes step by step procedure to test an application. It consists of the complete
navigation steps and inputs and all the scenarios that need to be tested for the application. We will write the test
case to maintain the consistency, or every tester will follow the same approach for organizing the test document.
Test plan
It is a document that is prepared by the managers or test lead. It consists of all information about the testing
activities. The test plan consists of multiple components such as Objectives, Scope, Approach, Test
Environments, Test methodology, Template, Role & Responsibility, Effort estimation, Entry and Exit
criteria, Schedule, Tools, Defect tracking, Test Deliverable, Assumption, Risk, and Mitigation Plan or
Contingency Plan.
Traceability Matrix
Traceability matrix is a table type document that is used in the development of software application to trace
requirements. It can be used for both forward (from Requirements to Design or Coding) and backward (from
Coding to Requirements) tracing. It is also known as Requirement Traceability Matrix (RTM) or Cross
Reference Matrix (CRM).
It is prepared before the test execution process to make sure that every requirement is covered in the form of a
Test case so that we don't miss out any testing. In the RTM document, we map all the requirements and
corresponding test cases to ensure that we have written all the test cases for each condition.
The test engineer will prepare RTM for their respective assign modules, and then it will be sent to the Test
Lead. The Test Lead will go repository to check whether the Test Case is there or not and finally Test Lead
consolidate and prepare one necessary RTM document.
Note:
We go for RTM after approval and before execution so that we don't miss out on any Test Case for any requirement.
We don't write RTM while writing the testing because it can be incomplete, and after writing the test case, we don't
go here because the test case can be rejected.
RTM document ensures that at least there is one test case written in each requirement, whereas it does not talk
about all possible test cases written for the particular requirement.

RTM Template
Below is the sample template of requirement traceability matrix (RTM):
Example of RTM template
Let us one sample of RTM template for better understanding:

Goals of Traceability Matrix

• It helps in tracing the documents that are developed during various phases of SDLC.
• It ensures that the software completely meets the customer's requirements.
• It helps in detecting the root cause of any bug.
Types of Traceability Test Matrix
The traceability matrix can be classified into three different types which are as follows:
• Forward traceability
• Backward or reverse traceability
• Bi-directional traceability

Forward traceability
The forward traceability test matrix is used to ensure that every business's needs or requirements are executed
correctly in the application and also tested rigorously. The main objective of this is to verify whether the product
developments are going in the right direction. In this, the requirements are mapped into the forward direction to
the test cases.

Requirements

Test Case
Backward or reverse traceability
The reverse or backward traceability is used to check that Requirements
we are not increasing the space of the product by
enhancing the design elements, code, test other things
which are not mentioned in the business needs. And the
main objective of this that the existing project remains in
the correct direction. In this, the requirements are mapped
Test Case
into the backward direction to the test cases.

Bi-directional traceability
It is a combination of forwarding and backward traceability matrix, which is used to make sure that all the
business needs are executed in the test cases. It also evaluates the modification in the requirement which is
occurring due to the bugs in the application.
Forward Backword

Requirements Requirements

Test Case Test Case

Advantage of RTM
Following are the benefits of requirement traceability matrix:
• With the help of the RTM document, we can display the complete test execution and bugs status based on
requirements.
• It is used to show the missing requirements or conflicts in documents.
• In this, we can ensure the complete test coverage, which means all the modules are tested.
• It will also consider the efforts of the testing teamwork towards reworking or reconsidering on the test cases.
Test strategy
The test strategy is a high-level document, which is used to verify the test types (levels) to be executed for the
product and also describe that what kind of technique has to be used and which module is going to be tested. The
Project Manager can approve it. It includes the multiple components such as documentation formats, objective, test
processes, scope, and customer communication strategy, etc. we cannot modify the test strategy.

Test data
It is data that occurs before the test is executed. It is mainly used when we are implementing the test case. Mostly,
we will have the test data in the Excel sheet format and entered manually while performing the test case.
The test data can be used to check the expected result, which means that when the test data is entered, the expected
outcome will meet the actual result and also check the application performance by entering the in-correct input data.

Bug report
The bug report is a document where we maintain a summary of all the bugs which occurred during the testing
process. This is a crucial document for both the developers and test engineers because, with the help of bug
reports, they can easily track the defects, report the bug, change the status of bugs which are fixed successfully,
and also avoid their repetition in further process.
Test execution report
It is the document prepared by test leads after the entire testing execution process is completed. The test summary
report defines the constancy of the product, and it contains information like the modules, the number of written test
cases, executed, pass, fail, and their percentage. And each module has a separate spreadsheet of their respective
module.

Benefits of using Documentation

• Documentation clarifies the quality of methods and objectives.
• It ensures internal coordination when a customer uses software application.
• It ensures clarity about the stability of tasks and performance.
• It provides feedback on preventive tasks.
• It provides feedback for your planning cycle.
• It creates objective evidence for the performance of the quality management system.
• If we write the test document, we can't forget the values which we put in the first phase.
• It is also a time-saving process because we can easily refer to the text document.
• It is also consistent because we will test on the same value.
The drawback of the test document
• It is a bit tedious because we have to maintain the modification provided by the customer and parallel change in
the document.
• If the test documentation is not proper, it will replicate the quality of the application.
• Sometimes it is written by that person who does not have the product knowledge.
• Sometimes the cost of the document will be exceeding its value.
 Difference between test plan, test suit , test case and test scenarios
Test Plan Test Suite Test Case Test Scenarios
1. Test plan is a document 1. Test case is an important 1. Test scenarios or test
1. Prepared after test plan,
that defines the scope, document that consists of condition is any
test suite consists of a
objective, and strategy of various crucial details about functionality of the software
collection of test cases.
testing. testing. that can be tested.
2. It is of three types, level 2. These are of two
2. It is of two types, abstract 2. It is performed from the
specific, type specific, types, formal test cases and
and executable test suites. perspective of the end users.
master test plan. informal test case.
3. It defines a set of
3. It follows a standardized 3. Test suites define the 3. It defines the various
conditions that help verify
template, which offers objective and goal of test operations that are
the compliance of the
details about the testing cases that are intended to performed by the team on
software with specified
process. test the software product. the software product.
functionality.
4. These are derived from
4. Separate test suites offer
4. It is derived from Product the test scenarios and are 4. They are derived from the
great advantages to team and
Description, SRS , or Use designed on the basis of use cases and they ensure
it created testing to be hassle
Case Document. Software Requirement complete test coverage.
free, flexible agile .
Specification (SRS).
Static Testing
In this section, we are going to understand Static testing, which is used to check the application without executing
the code. And we also learn about static Testing, why we use static Testing, how to perform it, a different
technique for static Testing, advantages of static testing, and various Static Testing tools.

Introduction to Static Testing

Static testing is a verification process used to test the application without implementing the code of the application.
And it is a cost-effective process.
To avoid the errors, we will execute Static testing in the initial stage of development because it is easier to identify
the sources of errors, and it can fix easily.
In other words, we can say that Static testing can be done manually or with the help of tools to improve the quality
of the application by finding the error at the early stage of development; that is also called the verification process.

Why do we need to perform Static Testing?

• We can perform static testing to fulfill the below aspects:
• We can use static testing to improve the development productivity.
• If we performed static testing on an application, we could find the detects in the earlier stages and easily fix
them.
• The usage of static testing will decrease the testing cost, development timescales, and time.
What are the different features we can test in Static Testing?
We can test the various testing activities in Static Testing, which are as
follows:
• BRD [Business Requirements Document]
• Functional or system Requirements
• Unit Use Cases
• Prototype
• Prototype Specification Document
• Test Data
• DB Fields Dictionary Spreadsheet
• Documentation/Training Guides/ User Manual
• Test Cases/Test Plan Strategy Document
• Traceability Matrix Document
• Performance Test Scripts/Automation

When we performed Static Testing?

To perform static testing, we need to follow the below steps:
Step1: To review the design of the application entirely, we will perform the inspection process.
Step2: After that, we will use a checklist for each document under review to make sure that all reviews are
covered completely.
We can also implement several activities while performing static testing, which are discussed in the following
table:

Activities Explanation
Architecture Review •The architecture review activities contain all business-level processes such as network diagram, load
balancing, server locations, protocol definitions, test equipment, database accessibility, etc.

Use Cases •It is used to authenticates all the end-user actions along with associated input and output.
Requirements •If the use case is more comprehensive and detailed, we can make more precise and inclusive test
Validation cases.
Functional •The functional requirement validation activity is used to make sure that all necessary elements
Requirements identify correctly.
Validation •And it also took care of the software, interface listings, network requirements, hardware, and
database functionality.
Field Dictionary •In the field dictionary validation, we will test each field in the user interface specified to create field-
Validation level validation test cases.
•And we can check the fields for error messages, minimum or maximum length, list values, etc.
Prototype/Screen •The prototype validation activity contains the authentication of requirements and uses cases.
Mockup Validation
Why we need Static Testing?
We required Static testing whenever we encounter the following situation while testing an application or the
software:
• Dynamic Testing is time-consuming
• Flaws at earlier stages/identification of Bugs
• Dynamic Testing is expensive
• Increased size of the software
• Dynamic Testing is time-consuming
We need static testing to test the application as dynamic testing is time-taking process even though the dynamic testing identifies
the bug and provides some information about the bug.
• Flaws at earlier stages/identification of Bugs
When we are developing the software, we cannot completely rely on Dynamic testing as it finds the bugs or defects of the
application/software at a later stage because it will take the programmer's plenty of time and effort to fix the bugs.
• Dynamic Testing is expensive
We need to perform the static testing on the software product because dynamic testing is more expensive than static testing.
Involving the test cases is expensive in dynamic testing as the test cases have been created in the initial stages.
And we also need to preserve the implementation and validation of the test case, which takes lots of time from the test
engineers.
• Increased size of the software
Whenever we test the software, it will increase the size of the software product, which we cannot handle because of the
reduction in the productivity of code coverage.
That is why we require static testing to get free from the bugs or defects earlier in the software development life cycle.
Objectives of Static testing
The main objectives of performing static testing is as below:
• Static testing will decrease the flaws in production.
• Static testing will identify, anticipate and fix the bugs at the earliest possible time.
• It is used to save both time and cost.
• It is used to identify defects in the early stage of SDLC, where we can fix them easily.

Static Testing Techniques

Static testing techniques offer a great way to enhance the quality and efficiency of software development. The
Static testing technique can be done in two ways, which are as follows:
• Review
• Static Analysis
Static Testing
Techniques

Static
Review
Analysis
Review
In static testing, the review is a technique or a process
implemented to find the possible bugs in the application.
We can easily identify and eliminate faults and defects in
the various supporting documents such as SRS [Software
Requirements Specifications] in the review process.
In other words, we can say that a review in Static Testing Review
is that where all the team members will understand about
the project's progress.
In static testing, reviews can be divided into four
different parts, which are as follows: Inspection
• Informal reviews
• Walkthroughs
• Technical/peer review
• Inspections
• Informal reviews
In informal review, the document designer place the contents in front of viewers, and everyone gives
their view; therefore, bugs are acknowledged in the early stage.
• Walkthrough
Generally, the walkthrough review is used to performed by a skilled person or expert to verify the
bugs. Therefore, there might not be problem in the development or testing phase.
• Peer review
In Peer review, we can check one another's documents to find and resolve the bugs, which is generally
done in a team.
• Inspection
In review, the inspection is essentially verifying the document by the higher authority, for example,
the verification of SRS [software requirement specifications] document.
Static Analysis
Another Static Testing technique is static analysis, which is used to contain the assessment of the code quality,
which is established by developers.
We can use the different tools to perform the code's analysis and evaluation of the same.
In other words, we can say that developers' developed code is analyzed with some tools for structural bugs, which
might cause the defects.
The static analysis will also help us to identify the below errors:
Dead code
Unused variables
Endless loops
Incorrect syntax Control
Data Flow
Variable with undefined value Flow

Static
Analysis
In static testing, Static Analysis can be further
classified into three parts, which are as Cyclomatic
discuss below: Complexity
 1. Data Flow: In static analysis, the data flow is connected to the stream processing.
2. Control Flow: Generally, the control flow is used to specify how the commands or instructions are
implemented.
3. Cyclomatic Complexity: It is the measurement of the program's complexity, which is mostly linked to
the number of independent paths in the control flow graph of the program.

Tools used for Static Testing

In static testing, we have several tools in the market, but
here we are discussing the most commonly used tools,
which are as follow:
• CheckStyle
• SourceMeter
• Soot
 It is a development tool that is used to help the developers write Java code, which follows a coding standard.
The CheckStyle tool automates the process of checking Java code.
It is a highly configured tool, which is made to support almost any coding standard. The Google Java Style, Sun
code conventions are those configuration files, which is supported by CheckStyle.

Feature of CheckStyle
Following are the most common features of CheckStyle:
•It can check various characteristics of our source code.
•The CheckStyle code has the capability to verify the code layout and formatting issues.
•It can also help to identify the method design problems, class design problems.
 SourceMeter
It is an advanced tool for the specific static source code analysis of various programming languages such
as C/C++, C#, Java, Python, and RPG projects.
With the SourceMeter tool's help, we can easily identify the vulnerable spots of a system under development
from the source code.
The free version with partial functionality of SourceMeter can be accessible for all programming languages.
In SourceMeter, we can use the output of the analysis, the quality of the analyzed source code to enhance and
developed both the short and long term in a directed way.

Feature of SourceMeter
The most commonly used features of the SourceMeter tool are as follows:
•It provides the most precise coding error detection.
•The SourceMeter tool will provide a deep static code analysis.
•It improved the user interface with the help of third-party integration.
•It will provide platform-independent command-line tools.
 Soot
It is a Java optimization framework, which means that it is a framework for analyzing and transforming Java
and Android applications where we can test the following aspects:
•Named module and modular jar files.
•Automatic modules, which means the modules are repeatedly created from jars in the module-path.
•Exploded modules
•Resolving modules in Soot's

And a Soot can also produce possibly transformed code in the various output formats such as Android bytecode,
Java bytecode Jasmin, and Jimple.
Advantages of Static Testing
The advantages of static testing are as follows:
• Improved Product quality
Static testing will enhance the product quality because it identifies the flaws or bugs in the initial stage of
software development.
• Improved the efficiency of Dynamic testing
The usage of Static testing will improve Dynamic Testing efficiency because the code gets cleaner and
better after executing Static Testing.
As we understood above, static Testing needs some efforts and time to generate and keep good quality
test cases.
• Reduced SDLC cost
The Static Testing reduced the SDLC cost because it identifies the bugs in the earlier stages of the
software development life cycle. So, it needs less hard work and time to change the product and fix
them.
• Immediate evaluation & feedback
The static testing provides us immediate evaluation and feedback of the software during each phase while
developing the software product.
• Exact location of bug is traced
When we perform the static testing, we can easily identify the bugs' exact location compared to the
dynamic Testing.
Some Terminologies
Error, Mistake, Bug, Fault and Failure
People make errors. A good synonym is mistake. This may be a syntax error or misunderstanding of
specifications. Sometimes, there are logical errors.
When developers make mistakes while coding, we call these mistakes “bugs”.
A fault is the representation of an error, where representation is the mode of expression, such as narrative text,
data flow diagrams, ER diagrams , source code etc. Defect is a good synonym for fault.
A failure occurs when a fault executes. A particular fault may cause different failures, depending on how it has
been exercised.
for a program of n variables, boundary value analysis yield 4n + 1 test cases.

Two alternate methods are available for the complexity calculations.

1. Cyclomatic complexity V(G) of a flow graph G is equal to the number of predicate (decision) nodes plus one.
V(G)= ∏ +1
Where ∏ is the number of predicate nodes contained in the flow graph G.
2. Cyclomatic complexity is equal to the number of regions of the flow graph.

•Predicate nodes are the conditional nodes.

•They give rise to two branches in the control flow graph.
Cyclomatic complexity can be calculated by any of the three
methods.
1. V(G) = e – n + 2P
= 13 – 10 + 2 = 5
2. V(G) = ∏ + 1
=4+1=5
3. V(G) = number of regions
=5