Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

UNIT - 1 INTRODUCTION TO SOFTWARE TESTING 9

Overview of Software Testing-Definition, objectives, and importance of software testing, Software Development
Life Cycle (SDLC) and Testing-Role of testing in different SDLC phases, Testing Levels and Types-Unit testing,
integration testing, system testing, acceptance testing.

Overview of Software Testing:

Software Testing:
Definition 1- "Software testing is a process, to evaluate the functionality of a software application with an intent
to find whether the developed software met the specified requirements or not and to identify the defects to ensure
that the product is defect-free in order to produce the quality product."
Definition 2- “Software testing is the processes of identifying the completeness, Correctness, Quality of the
developed software product. In software testing process the Software is tested in both positive and negative
condition.”
Objectives of Software Testing:

1. Identify Defects:
- The primary objective of software testing is to identify and document defects in the software. Defects can
include bugs, errors, and any other issues that may affect the functionality or performance of the software. By
finding these defects early, testers can ensure they are addressed before the software is released to users.
2. Ensure Quality:
- Software testing aims to verify that the software meets the required standards and specifications. This
involves checking that the software functions as intended and meets the quality criteria set by stakeholders.
Ensuring quality helps in delivering a reliable and robust product.
3. Validate Functionality:
- Testing involves validating that the software behaves as expected under various conditions. This includes
checking if the software performs correctly according to the defined requirements and use cases. Functional
validation ensures that all features work as intended and that the software provides the expected results.
4. Improve Performance:
- Performance testing is an essential part of software testing, aimed at ensuring the software performs
efficiently. This includes testing for speed, scalability, and optimal use of resources. Performance testing helps
identify bottlenecks and areas where the software can be optimized for better performance.
5. Enhance Security:
- Security testing is critical to identify vulnerabilities and ensure the software is secure against potential
threats. This involves testing for issues such as data breaches, unauthorized access, and other security risks.
Enhancing security through testing helps protect sensitive information and maintain user trust.
6. Ensure Usability:
- Usability testing focuses on verifying that the software is user-friendly and provides a good user experience.
This involves testing the interface, navigation, and overall ease of use. Ensuring usability is crucial for user
satisfaction and adoption of the software.
7. Compliance Verification:
- Compliance testing ensures that the software adheres to relevant laws, regulations, and industry standards.
This is particularly important for software in regulated industries, such as healthcare or finance. Compliance
verification helps avoid legal issues and ensures that the software meets all necessary regulatory requirements.

1
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

8. Reliability Assurance:
- Reliability testing aims to confirm that the software can operate consistently over time without failures. This
includes testing the software under different conditions and over extended periods. Ensuring reliability is
important for maintaining the software's stability and dependability.
9. Facilitate Maintenance:
- Effective software testing includes documenting tests and results to facilitate future maintenance. Well-
documented testing processes and outcomes make it easier to understand the software's behavior and implement
updates or fixes. This helps in maintaining the software over its lifecycle.
10. Risk Reduction:
- Testing helps minimize the risks associated with software failure in production. By thoroughly testing the
software, potential issues can be identified and mitigated before the software is deployed. Risk reduction is
essential for preventing costly failures and ensuring smooth operation of the software in the real world.

Importance of Software Testing:

2
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Software Validation

Validation is process of examining whether or not the software satisfies the user requirements. It is
carried out at the end of the SDLC. If the software matches requirements for which it was made, it is
validated.

 Validation ensures the product under development is as per the user requirements.
 Validation answers the question – "Are we developing the product which attempts all that user needs
from this software ?".
 Validation emphasizes on user requirements.

Software Verification

Verification is the process of confirming if the software is meeting the business requirements, and is
developed adhering to the proper specifications and methodologies.

 Verification ensures the product being developed is according to design specifications.

 Verification answers the question– "Are we developing this product by firmly following all design
specifications ?"
 Verifications concentrates on the design and system specifications.

Target of the test are -

Errors - These are actual coding mistakes made by developers. In addition, there is a difference in
output of software and desired output, is considered as an error.

Fault - When error exists fault occurs. A fault, also known as a bug, is a result of an error which can
cause system to fail.

Failure - failure is said to be the inability of the system to perform the desired task. Failure occurs when
fault exists in the system.

Manual Vs Automated Testing

Testing can either be done manually or using an automated testing tool:

Manual - This testing is performed without taking help of automated testing tools. The software tester
prepares test cases for different sections and levels of the code, executes the tests and reports the result to
the manager.
Manual testing is time and resource consuming. The tester needs to confirm whether or not right test
cases are used. Major portion of testing involves manual testing.

Automated This testing is a testing procedure done with aid of automated testing tools. The limitations
with manual testing can be overcome using automated test tools.

3
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

A test needs to check if a webpage can be opened in Internet Explorer. This can be easily done with
manual testing. But to check if the web-server can take the load of 1 million users, it is quite impossible
to test manually.

There are software and hardware tools which helps tester in conducting load testing, stress testing,
regression testing.

Testing Approaches

Tests can be conducted based on two approaches –

 Functionality testing
 Implementation testing

When functionality is being tested without taking the actual implementation in concern it is known as
black-box testing. The other side is known as white-box testing where not only functionality is tested but
the way it is implemented is also analyzed.

Exhaustive tests are the best-desired method for a perfect testing. Every single possible value in the
range of the input and output values is tested. It is not possible to test each and every value in real world
scenario if the range of values is large.

Black-box testing

It is carried out to test functionality of the program. It is also called ‘Behavioral’ testing. The tester in
this case, has a set of input values and respective desired results. On providing input, if the output
matches with the desired results, the program is tested ‘ok’, and problematic otherwise.

In this testing method, the design and structure of the code are not known to the tester, and testing
engineers and end users conduct this test on the software.

Black-box testing techniques:

Equivalence class - The input is divided into similar classes. If one element of a class passes the test, it
is assumed that all the class is passed.

Boundary values - The input is divided into higher and lower end values. If these values pass the test, it
is assumed that all values in between may pass too.

Cause-effect graphing - In both previous methods, only one input value at a time is tested. Cause (input)
– Effect (output) is a testing technique where combinations of input values are tested in a systematic way.
4
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Pair-wise Testing - The behavior of software depends on multiple parameters. In pairwise testing, the
multiple parameters are tested pair-wise for their different values.

State-based testing - The system changes state on provision of input. These systems are tested based on
their states and input.

White-box testing

It is conducted to test program and its implementation, in order to improve code efficiency or structure.
It is also known as ‘Structural’ testing.

In this testing method, the design and structure of the code are known to the tester. Programmers of the
code conduct this test on the code.

The below are some White-box testing techniques:

Control-flow testing - The purpose of the control-flow testing to set up test cases which covers all
statements and branch conditions. The branch conditions are tested for both being true and false, so that
all statements can be covered.

Data-flow testing - This testing technique emphasis to cover all the data variables included in the
program. It tests where the variables were declared and defined and where they were used or changed.

Testing Levels

Testing itself may be defined at various levels of SDLC. The testing process runs parallel to software
development. Before jumping on the next stage, a stage is tested, validated and verified.

Testing separately is done just to make sure that there are no hidden bugs or issues left in the software.
Software is tested on various levels -

Unit Testing

While coding, the programmer performs some tests on that unit of program to know if it is error free.
Testing is performed under white-box testing approach. Unit testing helps developers decide that
individual units of the program are working as per requirement and are error free.

Integration Testing

5
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Even if the units of software are working fine individually, there is a need to find out if the units if
integrated together would also work without errors. For example, argument passing and data updation
etc.

System Testing

The software is compiled as product and then it is tested as a whole. This can be accomplished using one
or more of the following tests:

Functionality testing - Tests all functionalities of the software against the requirement.

Performance testing - This test proves how efficient the software is. It tests the effectiveness and
average time taken by the software to do desired task. Performance testing is done by means of load
testing and stress testing where the software is put under high user and data load under various
environment conditions.

Security & Portability - These tests are done when the software is meant to work on various platforms
and accessed by number of persons.

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.

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.

Regression Testing

Whenever a software product is updated with new code, feature or functionality, it is tested thoroughly
to detect if there is any negative impact of the added code. This is known as regression testing.

Testing Documentation

Testing documents are prepared at different stages -

Before Testing

Testing starts with test cases generation. Following documents are needed for reference –

6
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

SRS document - Functional Requirements document

Test Policy document - This describes how far testing should take place before releasing the product.

Test Strategy document - This mentions detail aspects of test team, responsibility matrix and
rights/responsibility of test manager and test engineer.

Traceability Matrix document - This is SDLC document, which is related to requirement gathering
process. As new requirements come, they are added to this matrix. These matrices help testers know the
source of requirement. They can be traced forward and backward.

While Being Tested

The following documents may be required while testing is started and is being done:

Test Case document - This document contains list of tests required to be conducted. It includes Unit test
plan, Integration test plan, System test plan and Acceptance test plan.

Test description - This document is a detailed description of all test cases and procedures to execute
them.

Test case report - This document contains test case report as a result of the test.

Test logs - This document contains test logs for every test case report.

After Testing

The following documents may be generated after testing :

Test summary - This test summary is collective analysis of all test reports and logs. It summarizes and
concludes if the software is ready to be launched. The software is released under version control system
if it is ready to launch.

Testing vs. Quality Control, Quality Assurance and Audit

We need to understand that software testing is different from software quality assurance, software
quality control and software auditing.

Software quality assurance - These are software development process monitoring means, by which it is
assured that all the measures are taken as per the standards of organization. This monitoring is done to
make sure that proper software development methods were followed.
Software quality control - This is a system to maintain the quality of software product. It may include
functional and non-functional aspects of software product, which enhance the goodwill of the
organization. This system makes sure that the customer is receiving quality product for their requirement
and the product certified as ‘fit for use’.
Software audit - This is a review of procedure used by the organization to develop the software. A team
of auditors, independent of development team examines the software process, procedure, requirements
and other aspects of SDLC. The purpose of software audit is to check that software and its development
process, both conform standards, rules and regulations.

7
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

SOFTWARE DEVELOPMENT LIFE CYCLE AND TESTING

Software Development Life Cycle, SDLC for short, is a well-defined, structured sequence of stages in
software engineering to develop the intended software product.

SDLC Activities

SDLC provides a series of steps to be followed to design and develop a software product efficiently.
SDLC framework includes the following steps:

Communication

This is the first step where the user initiates the request for a desired software product. He contacts the
service provider and tries to negotiate the terms. He submits his request to the service providing
organization in writing.

Requirement Gathering

This step onwards the software development team works to carry on the project. The team holds
discussions with various stakeholders from problem domain and tries to bring out as much information
as possible on their requirements. The requirements are contemplated and segregated into user
requirements, system requirements and functional requirements. The requirements are collected using a
number of practices as given -

8
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

 studying the existing or obsolete system and software,

 conducting interviews of users and developers,
 referring to the database or
 collecting answers from the questionnaires.

Feasibility Study

After requirement gathering, the team comes up with a rough plan of software process. At this step the
team analyzes if a software can be made to fulfill all requirements of the user and if there is any
possibility of software being no more useful. It is found out, if the project is financially, practically and
technologically feasible for the organization to take up. There are many algorithms available, which help
the developers to conclude the feasibility of a software project.

System Analysis

At this step the developers decide a roadmap of their plan and try to bring up the best software model
suitable for the project. System analysis includes Understanding of software product limitations, learning
system related problems or changes to be done in existing systems beforehand, identifying and
addressing the impact of project on organization and personnel etc. The project team analyzes the scope
of the project and plans the schedule and resources accordingly.

Software Design

Next step is to bring down whole knowledge of requirements and analysis on the desk and design the
software product. The inputs from users and information gathered in requirement gathering phase are the
inputs of this step. The output of this step comes in the form of two designs; logical design and physical
design. Engineers produce meta-data and data dictionaries, logical diagrams, data-flow diagrams and in
some cases pseudo codes.

Coding

This step is also known as programming phase. The implementation of software design starts in terms of
writing program code in the suitable programming language and developing error-free executable
programs efficiently.

Testing

An estimate says that 50% of whole software development process should be tested. Errors may ruin the
software from critical level to its own removal. Software testing is done while coding by the developers
and thorough testing is conducted by testing experts at various levels of code such as module testing,
program testing, product testing, in-house testing and testing the product at user’s end. Early discovery
of errors and their remedy is the key to reliable software.

Integration

Software may need to be integrated with the libraries, databases and other program(s). This stage of
SDLC is involved in the integration of software with outer world entities.

9
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Implementation

This means installing the software on user machines. At times, software needs post-installation
configurations at user end. Software is tested for portability and adaptability and integration related
issues are solved during implementation.

Operation and Maintenance

This phase confirms the software operation in terms of more efficiency and less errors. If required, the
users are trained on, or aided with the documentation on how to operate the software and how to keep
the software operational. The software is maintained timely by updating the code according to the
changes taking place in user end environment or technology. This phase may face challenges from
hidden bugs and real-world unidentified problems.

Disposition

As time elapses, the software may decline on the performance front. It may go completely obsolete or
may need intense upgradation. Hence a pressing need to eliminate a major portion of the system arises.
This phase includes archiving data and required software components, closing down the system,
planning disposition activity and terminating system at appropriate end-of-system time.

Software Development Paradigm

The software development paradigm helps developer to select a strategy to develop the software. A
software development paradigm has its own set of tools, methods and procedures, which are expressed
clearly and defines software development life cycle. A few of software development paradigms or
process models are defined as follows:

Waterfall Model

Waterfall model is the simplest model of software development paradigm. It says the all the phases of
SDLC will function one after another in linear manner. That is, when the first phase is finished then only
the second phase will start and so on.

10
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

This model assumes that everything is carried out and taken place perfectly as planned in the previous
stage and there is no need to think about the past issues that may arise in the next phase. This model does
not work smoothly if there are some issues left at the previous step. The sequential nature of model does
not allow us go back and undo or redo our actions.

This model is best suited when developers already have designed and developed similar software in the
past and are aware of all its domains.

Iterative Model

This model leads the software development process in iterations. It projects the process of development
in cyclic manner repeating every step after every cycle of SDLC process.

The software is first developed on very small scale and all the steps are followed which are taken into
consideration. Then, on every next iteration, more features and modules are designed, coded, tested and
added to the software. Every cycle produces a software, which is complete in itself and has more features
and capabilities than that of the previous one.

After each iteration, the management team can do work on risk management and prepare for the next
iteration. Because a cycle includes small portion of whole software process, it is easier to manage the
development process but it consumes more resources.

Spiral Model

Spiral model is a combination of both, iterative model and one of the SDLC model. It can be seen as if
you choose one SDLC model and combine it with cyclic process (iterative model).

11
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

This model considers risk, which often goes un-noticed by most other models. The model starts with
determining objectives and constraints of the software at the start of one iteration. Next phase is of
prototyping the software. This includes risk analysis. Then one standard SDLC model is used to build
the software. In the fourth phase of the plan of next iteration is prepared.

V – model

The major drawback of waterfall model is we move to the next stage only when the previous one is
finished and there was no chance to go back if something is found wrong in later stages. V-Model
provides means of testing of software at each stage in reverse manner.

12
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

At every stage, test plans and test cases are created to verify and validate the product according to the
requirement of that stage. For example, in requirement gathering stage the test team prepares all the test
cases in correspondence to the requirements. Later, when the product is developed and is ready for
testing, test cases of this stage verify the software against its validity towards requirements at this stage.

This makes both verification and validation go in parallel. This model is also known as verification and
validation model.

Big Bang Model

This model is the simplest model in its form. It requires little planning, lots of programming and lots of
funds. This model is conceptualized around the big bang of universe. As scientists say that after big bang
lots of galaxies, planets and stars evolved just as an event. Likewise, if we put together lots of
programming and funds, you may achieve the best software product.

13
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

For this model, very small amount of planning is required. It does not follow any process, or at times the
customer is not sure about the requirements and future needs. So the input requirements are arbitrary.

This model is not suitable for large software projects but good one for learning and experimenting.

Role of testing in SDLC:

The role of testing in the Software Development Life Cycle (SDLC) is to ensure that the final product
meets the user's expectations. Testing is a crucial phase that can help reduce costs, improve quality, and
increase user satisfaction.

Here are some ways testing is important in different phases of the SDLC:
 Early testing: Testing early in the SDLC can help minimize the cost of fixing bugs.
 Quality assurance: Testing is a way to ensure that the product meets quality standards.
 User satisfaction: Proper testing can lead to more customer engagement and improved
productivity.
 Cost savings: Testing can reduce the overall cost of product development and maintenance.
 Bug prevention: Designing tests well can help prevent bugs before they are coded.
 Security: Security testing can help identify flaws that could expose users' personal data or make the
software susceptible to malware.

During the testing phase, developers use a test plan to identify and investigate any issues. The test
plan includes the types of testing to be performed, who will be testing, and how the software will be
tested. Some types of testing include:
 Unit testing
 Integration testing
 System testing
 Acceptance testing
 Quality assurance testing (QA)
 User acceptance testing (UAT)

SOFTWARE TESTING LIFE CYCLE

Software Testing Life Cycle (STLC) is a process used to test software and ensure that quality
standards are met. Tests are carried out systematically over several phases. During product
development, phases of the STLC may be performed multiple times until a product is deemed
suitable for release.

Entry and Exit Criteria in STLC

 Entry Criteria: Entry Criteria gives the prerequisite items that must be comple
 Exit Criteria: Exit Criteria defines the items that must be completed before testing can
be concluded

14
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

The 6 STLC Phases In-Depth

Software Testing Life Cycle consists of 6 phases, each with defined entry and exit criteria and
associated activities and deliverables.
Entry and exit criteria define when a phase can start and when it can end.
Activities and deliverables define what actions are performed and what the expected result is.

STLC Model Phases

1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure

Each of these stages has a definite Entry and Exit criteria, Activities & Deliverables associated
with it.

Phase 1: Requirement Analysis

During this phase, feature requirements collected in the SDLC process are evaluated to identify
testable aspects. If necessary, testing teams may need to consult with stakeholders to clarify
requirements. These requirements can either be functional or non-functional, defining what a
feature can do or it’s characteristics respectively. The ability to automate testing is also evaluated
during this phase.

 Entry Criteria—documented requirements, acceptance criteria, and intended product

architecture.
 Exit Criteria—approved requirement traceability matrix (RTM) and automation feasibility
report.
 Activities
o Identify types of tests to be performed.
o Gather details about testing priorities and focus.
o Prepare Requirement Traceability Matrix (RTM).
15
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

 Deliverables

RTM
Automation feasibility report

Phase 2: Test Planning

During this phase, the test strategy is outlined in a test plan document. This strategy includes
tools needed, testing steps, and roles and responsibilities. Part of determining this strategy is a risk
and cost analysis and an estimated timeline for testing.

 Entry Criteria—requirement analysis, RTM, and automation feasibility report.

 Exit Criteria—approved test plan including timelines and risk/cost analysis.
 Activities

Preparation of test plan/strategy

Test tool selection
Test effort estimation
Resource planning and determining roles and responsibilities.
Training requirement

 Deliverables

Test plan /strategy document.

Effort estimation document.

Phase 3: Test Case Development

During this phase, test cases are created. Each case defines test inputs, procedures, execution
conditions, and anticipated results. Test cases should be transparent, efficient, and adaptable. Once
all test cases are created, test coverage should be 100%. Any necessary automation scripts are also
created during this phase.

 Entry Criteria—approved test plan including timelines and risk/cost analysis.

 Exit Criteria—approved test cases and automation scripts.
 Activities

Create test cases, automation scripts (if applicable)

Review and baseline test cases and scripts
Create test data

 Deliverables

Test
cases/scripts
Test data

16
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Phase 4: Test Environment Setup

During this phase, testing environments are configured and deployed. This phase may include a
variety of testing tools, including TestComplete, Selenium, Appium, or Katalon Studio. Sometimes,
this phase also includes setting up test servers. Once environments are deployed, smoke tests are
performed to ensure that environments are working as expected with all intended functionality.

 Entry Criteria: system design and project architecture definitions.

 Exit Criteria: a fully functional test environment and approved test cases.
 Activities

Understand the required architecture, environment set-up and prepare

hardware/software requirement list for the Test Environment.
Setup test Environment and test data
Perform smoke test on the build

 Deliverables

Environment ready with test data set up

Smoke Test Results.

Phase 5: Test Execution

During this phase, features are tested in the deployed environment, using the established test
cases. Expected test results are compared to actual and results are gathered to report back to
development teams.

 Entry Criteria—all exit criteria from previous steps.

 Exit Criteria—all tests are performed and results are documented.
 Activities

Execute tests as per plan

Document test results, and log defects for failed cases
Map defects to test cases in RTM
Retest the Defect fixes
Track the defects to closure

 Deliverables

Test cases updated with results

Defect reports

Phase 6: Test Cycle Closure

This is the last phase of the STLC, during which a test result report is prepared. This report
should summarize the entire testing process and provide comparisons between expected results and
actual. These comparisons include objectives met, time taken, total costs, test coverage, and any
defects found.

17
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

 Entry Criteria—test results and logging from all previous phases.

 Exit Criteria—delivered and approved test closure report.
 Activities

Evaluate cycle completion criteria based on Time, Test coverage, Cost, Software,
Critical Business Objectives, Quality
Prepare test metrics
Prepare Test closure report
Qualitative and quantitative reporting of quality of the work product to the customer.
Test result analysis

 Deliverables

Test Closure
report
Test metrics

V-MODEL OF SOFTWARE TESTING

The V-model of SDLC carries out its execution in a sequential manner. This model is also
popularly termed as a Verification and Validation model. Each phase has to be finished before
beginning the next phase. A sequential design progression is followed like that of the waterfall
model.

The Design of the SDLC V-Model

In parallel to the software development phase, a corresponding series of test phase also runs in this
model. Each stage comprises a specific type of testing done, and once that testing is passed, only
then the next phase starts.

18
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Verification: In the concept of verification in the V-Model, static analysis technique is carried out
without executing the code. This evaluation procedure is carried out at the time of development to
check whether specific requirements will meet or not.

Validation: This concept of V-Model comprises of dynamic analysis practice (both functional as
well as non-functional), and testing is done by code execution. The validation of a product is done
once the development is complete for determining if the software meets up the customer hope
needs.

So both verification and validation are combined and work in parallel to make the V- Model fully
functional.

Design Phase
➢ Requirement Analysis: In this stage of SDLC, a detailed conversation with the customer is
made to understand their requirements as well as anticipation. Requirement gathering is
another name of this phase.

➢ System Design or High-level Design: In this phase of SDLC, the system is designed with
the entire hardware & the setup is constructed for product development.

➢ Architectural Design: The breakdown of system design to a more detailed version, i.e.,
into modules which creates different functionalities. Transferring of data and connection
between internal and external modules (i.e., the outside world) is evidently identified.

➢ Low-level design or Module Design: This particular phase breaks down the entire product
development into tiny modules where each intended module is specified. So it is also
termed as Low-Level Design (LLD).

Testing Phase
➢ Unit Testing: During the development of module design, unit testing is carried out. This
plan is executed for eliminating bugs that are found in code at the development of your
software.

➢ Integration Testing: Once the unit testing is done, the integration testing is carried out
where the integration of modules in the system is hardened. This testing is done in the
architecture design phase.

➢ System Testing: This ultimate test is done when the entire product is completed in
conjunction with the functionality, internal dependency requirement and merging of
different modules into a single unit.

➢ User Acceptance Testing: This type of testing is carried out in front of the user or in a user
environment where the product will ultimately set up. The UAT particularly test whether
the product is capable enough to launch in the market or ready to work in the real world.

19
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Program Correctness and Verification

Correctness from software engineering perspective can be defined as the adherence to the
specifications that determine how users can interact with the software and how the software should
behave when it is used correctly.
If the software behaves incorrectly, it might take considerable amount of time to achieve the task or
sometimes it is impossible to achieve it.
The important rules for effective programming which are consequences of the program
correctness theory.
➢ Defining the problem completely.
➢ Develop the algorithm and then the program logic.
➢ Reuse the proved models as much as possible.
➢ Prove the correctness of algorithms during the design phase.
➢ Developers should pay attention to the clarity and simplicity of your program.
➢ Verifying each part of a program as soon as it is developed.

The reasons for program correctness and verification and some of them are as follows

➢ The focus of software testing is to run the program on selected input data and check
whether the program behaves correctly with respect to its specification. The behavior of the
program can be analyzed only if we know what is a correct behavior; hence the study of
correctness is an integral part of software testing.

➢ The study of program correctness leads to analyze candidate programs at arbitrary levels of
granularity; in particular, it leads to make assumptions on the behavior of the program at
specific stages in its execution and to verify (or disprove) these assumptions; the same
assumptions can be checked at run-time during testing, giving us valuable information as
we try to diagnose the program or establish its correctness. Hence to prove program
correctness enable us to be better/more effective testers.

Levels or Stages of Testing

Unit Testing
 Unit Testing is a type of software testing where individual units or components of a
software are tested. The purpose is to validate that each unit of the software code
performs as expected.
 Unit Testing is done during the development (coding phase) of an application by the
developers.
 Unit Tests isolate a section of code and verify its correctness.
 A unit may be an individual function, method, procedure, module, or object.

20
 Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

The key reasons to perform unit testing

 Unit tests help to fix bugs early in the development cycle and save costs.
 It helps the developers to understand the testing code base and enables them to
make changes quickly
 Good unit tests serve as project documentation
 Unit tests help with code re-use. Migrate both your code and your tests to your new
project. Tweak the code until the tests run again.

The workflow of Unit Testing

The workflow of Unit Testing is 1) Create Test Cases 2) Review/Rework 3) Baseline 4) Execute
Test Cases.

Unit Testing Techniques:

There are 3 types of Unit Testing Techniques. They are

 Black Box Testing:

This testing technique is used in covering the unit tests for input, user interface, and
output parts.

 White Box Testing:

This technique is used in testing the functional behavior of the system by giving
the input and checking the functionality output including the internal design structure and
code of the modules.

 Gray Box Testing:

This technique is used in executing the relevant test cases, test methods, test functions,
and analyzing the code performance for the modules.

21
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Advantages of Unit Testing

 Unit testing enables testing parts of the project without waiting for others to
be completed.
 Early Detection of Issues
 Improved Code Quality
 Increased Confidence
 Reduced Time and Cost

Disadvantages of Unit Testing:

 The process is time-consuming for writing the unit test cases.
 It requires more time for maintenance when the source code is changed frequently.
 It cannot cover the non-functional testing parameters such as scalability, the
performance of the system, etc.
 Difficulty in Testing Complex Units
 Difficulty in Testing Interactions

Integration Testing

 Integration testing is known as the second level of the software testing process,
following unit testing. Integration testing involves checking individual components or
units of a software project to expose defects and problems to verify that they work
together as designed.
 The main function or goal of this testing is to test the interfaces between the
units/modules.
 The individual modules are first tested in isolation. Once the modules are unit tested,
they are integrated one by one, till all the modules are integrated, to check the
combinational behavior, and validate whether the requirements are implemented
correctly or not.

Example of Integration Test Case

Sample Integration Test Cases for the following scenario: Application has 3 modules
say ‘Login Page’, ‘Mailbox’ and ‘Delete emails’ and each of them is integrated logically.

Check its integration to the Delete Mails Module.

22
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Test
Case Test Case Objective Test Case Expected Result
ID Description
1 Check the interface link Enter login To be directed to the Mail
between the Login and credentials and click on Box
Mailbox module the Login button
2 Check the interface link From Mailbox select the Selected email should
between the Mailbox and email and click a appear in the
Delete Mails Module delete button Deleted/Trash folder
Types of Integration Testing
Software Engineering defines variety of strategies to execute Integration testing, viz.

1. Big Bang Approach

2. Incremental Approach
a) Top Down Approach
b) Bottom Up Approach
3. Sandwich Approach – Combination of Top Down and Bottom Up

Big Bang Testing

 Big Bang Testing is an Integration testing approach in which all the components or
modules are integrated together at once and then tested as a unit.
 This combined set of components is considered as an entity while testing. If all of the
components in the unit are not completed, the integration process will not execute.

Incremental Testing
 In the Incremental Testing approach, testing is done by integrating two or more
modules that are logically related to each other and then tested for proper functioning
of the application. Then the other related modules are integrated incrementally and the
process continues until all the logically related modules are integrated and tested
successfully.
 Incremental Approach, in turn, is carried out by two different Methods:
 Bottom Up
 Top Down

23
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Stubs and Drivers

Stubs and Drivers are the dummy programs in Integratio facilitaten testing used to a
the software testing activity. These programs act as the missing models in substitutes for
the testing.
 Stub: Is called by the Module under Test.
 Driver: Calls the Module to be tested.

Stubs Driver
 Used in Top down approach Used in Bottom up approach
 Top most module is tested first Lowest modules are tested first.
 Stimulates the lower level of Stimulates the higher level of
components components
 Dummy program of lower Dummy program for Higher level
level components component

Bottom-up Integration Testing

 Bottom-up Integration Testing is a strategy in which modules are the lower level
tested first. These tested modules are then facilitate the testing of further used to
higher level modules.
 The process continues until all modules at top level are tested. Once the lower level
modules are tested and integrated, then the next level of modules are formed.

24
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

Advantages:
 Fault localization is easier.
 No time is wasted waiting for all modules to be developed unlike Big- bang
approach
Disadvantages:
 Critical modules (at the top level of software architecture) which control the flow of
application are tested last and may be prone to defects.
 An early prototype is not possible

Top-down Integration Testing

 Top Down Integration Testing is a method in which integration testing takes place
from top to bottom following the control flow of software system.
 The higher level modules are tested first and then lower level modules are tested and
integrated in order to check the software functionality. Stubs are used for testing if
some modules are not ready.

Advantages:
 Fault Localization is easier.
 Possibility to obtain an early prototype.
 Critical Modules are tested on priority; major design flaws could be found and
fixed first.
Disadvantages:
 Needs many Stubs.
 Modules at a lower level are tested inadequately.

Sandwich Testing
 Sandwich Testing is a strategy in which top level modules are tested with lower
level modules at the same time lower modules are integrated with top modules and
tested as a system.
 It is a combination of Top-down and Bottom-up approaches therefore it is called
Hybrid Integration Testing. It makes use of both stubs as well as drivers.

25
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

System Testing
 System testing, also referred to as system-level testing or system
integration testing, is the process in which a quality assurance (QA)
team evaluates how the various components of an application interact
together in the full, integrated system or application.
 System testing verifies that an application performs tasks as designed.
It's a type of black box testing that focuses on the functionality of an
application rather than the inner workings of a system, which white
box testing is concerned with.

 System testing is the third level of testing in the software

development process. It's typically performed before acceptance testing
and after integration testing.
Importance of system testing
 Improved product quality - A comprehensive system testing
process ultimately boosts the product quality.
 Error reduction - System testing verifies a system's code and functionality
against its requirements, so errors that aren't detected during
integration and unit testing can be exposed during system testing.

26
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

 Cost savings - It can be more time-consuming to fix a system defect

that's detected later in the project lifecycle.
 Security - Well-tested products are reliable. They ensure that the
tested system doesn't contain vulnerabilities.
 Customer satisfaction - System testing offers visibility into the
stability of a product at every stage of development. This builds
customer confidence and improves the overall user experience.
 Easier code modification - System testing can identify code problems
during software development.
 Software performance - Performance-based system tests can help
understand changes in a system's performance and behavior, such as
memory consumption, central processing unit utilization and latency.

System Testing Process

 Test Planning:
The test plan is a document that includes the information of your
testing, like objectives, strategies, entry-exit criteria, software
requirements, testing tools, guidelines, etc.
 Test Case Design and Execution:
Create a test case for every feature with the test scenarios,
description, process, and more. Then perform the tests and execute them.
 Defect Tracking and Defect Management:
Track and record the defects with the defect tracking tools like-
JIRA, Bugzilla, Trello, etc. Also, you must write about them for the
developers to resolve them.
 Reporting and Communication:
Create bug reports about defect reports to send to the developers.
Try to follow an organizational method for this.
System Testing Types
A. Functional Testing
1. Unit Testing
 This testing process checks whether each system unit or component
works accordingly. This is the first testing step performed at the
development stage, and it helps to fix the bugs before the
development cycle.
2. Integration Testing
 This testing aims to validate the different software units working
together to achieve the expected functionality. Thus it establishes a
steady communication between several components and
subsystems of software.

27
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

28
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

29
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

30
Course Code/Title: CS2602/SOFTWARE TESTING Unit: I

31
 Course Code/Title:CS2602/Software Testing Unit: II

Unit II: TESTING TECHNIQUES, TEST PLANNING AND MANAGEMENT 9

Dynamic Testing Techniques- Black-box testing, white-box testing, gray-box testing, Test Planning- Creating a
test plan, defining test objectives, scope, and resources, Test Monitoring and Control- Tracking progress, managing
changes, and controlling the testing process.
Software Testing
Software testing is a process to evaluate the functionality of a software application with the intent to determine
whether the developed software meets the specified requirements. It aims to identify defects to ensure the product
is defect-free and delivers quality.
Definition
Software Testing Definition (ANSI/IEEE 1059 Standard): A process of analyzing a software item to detect the
differences between existing and required conditions (i.e., defects) and to evaluate the features of the software item.
Software Testing Types
1. Manual Testing
o Manual testing is the process of testing software by hand to learn more about it and identify what
works and what doesn’t.
o It includes verifying all features specified in requirements documents and considering the end
user’s perspective.
o Manual test plans can range from fully scripted test cases (with detailed steps and expected results)
to high-level guides for exploratory testing.
o Tools like Testpad can be helpful for manual testing.
2. Automation Testing
o Automation testing involves using tools to execute test scripts and generate results automatically.
o Testers use automation tools to identify defects efficiently.
o Popular automation tools for functional testing include QTP/UFT and Selenium.
Testing Methods
1. Static Testing
o Also known as Verification in Software Testing.
o It is a static method of checking documents and files.
o Ensures that the product is being built correctly by verifying requirements and development
processes.
o Activities involved: Inspections, Reviews, Walkthroughs.
2. Dynamic Testing
o Also known as Validation in Software Testing.
o A dynamic process that tests the actual product to ensure it meets requirements.
o Focuses on validating the developed product’s correctness.
Testing Approaches
1. White Box Testing
o Also known as Glass Box, Clear Box, or Structural Testing.
o Based on the application’s internal code structure.
o Requires programming skills and internal system knowledge to design test cases.
o Usually performed at the unit level.
2. Black Box Testing
o Also known as Behavioral, Specification-Based, or Input-Output Testing.
o Evaluates software functionality without examining the internal code structure.
3. Grey Box Testing
o Combines White Box and Black Box Testing approaches.
o Requires access to design documents to create better test cases.

Testing Levels
1. Unit Testing
o Tests individual modules of the source code to ensure they work properly.
2. Integration Testing
o Tests the interfaces and interactions between integrated units or modules.
3. System Testing
o Validates the complete and fully integrated software application.
4. Acceptance Testing
1
 Course Code/Title:CS2602/Software Testing Unit: II
o Ensures the software meets business requirements and is ready for customer sign-off.
o Types of Acceptance Testing: Alpha Testing, Beta Testing, Gamma Testing.

Black Box Testing

 Black box testing involves testing a system with no prior knowledge of its internal workings.
 A tester provides an input, and observes the output generated by the system under test. This makes
it possible to identify how the system responds to expected and unexpected user actions, its
response time, usability issues and reliability issues.
 Black box testing is a powerful testing technique because it exercises a system end-to-end.

Black box testing checks that the system as a whole is working as expected.

Types of Black Box Testing

1. Functional Testing
o Verifies that each function of the software behaves as specified in the requirement document.
o Focuses on testing functionalities by providing appropriate input and verifying that the actual
output matches the expected output.
2. Non-functional Testing
o Tests how well the system performs.
o Evaluates aspects such as performance, load, stress, scalability, security, and compatibility.

Focuses on improving the user experience, including how

fast the system responds to requests.

2
 Course Code/Title:CS2602/Software Testing Unit: II

Black Box Testing Techniques

1. Equivalence Partitioning:
The word Equivalence means the condition of being equal or equivalent in value, worth, function, etc. The
synonyms for the word are equal, same, identical etc. Equivalence Partitioning is a black box technique to
identify test cases systematically and is often the first technique to be applied when designing test cases.
Equivalence Partitioning is based on the idea that it in many cases the inputs/outputs to a program can be
chunked into groups or classes which have the same behaviour. Eg. Alphabets, Numbers, range of numbers etc
Example: Let us consider a program that separates integers into positive or negative. And accepts any number
between -5 and + 5.
The range of input integers can be split into the following partitions :

 Negative Integers: Values between -5 and -1

 Zero (neither positive nor negative)
 Positive Integers: Values between 1 and 5
 Values > 5 (Invalid)
 Values < -5 (Invalid)

Valid Valid Valid Invalid Invalid

-5 -1 0 1 5 >5 < -5

Each of these is known as an ‘equivalence partition’ because every value inside the partition is exactly
equivalent to any other value as far as the program is concerned. So -3 is exactly the same as -2, -1, -4, -5 and
1 is the same as 2,3,4,5. And testing with any one of these values is representative of the entire partition. Thus
equivalence partitioning takes advantage of the properties of equivalence partitions to reduce the number of test
cases. Each equivalence partition covers a large set of other tests.
The first three partitions are called Valid partitions because they are within the range accepted by the
program. The last two are called Invalid partitions because they are outside the range. We can add more to
the invalid partitions: decimal number partitions, alphabets etc.
The above are all examples of Input partitions because the partitions are based on the inputs to the program.
Output partitions:

Just as the inputs to a program can be partitioned, the outputs of a program could be partitioned.
Let us consider a bank account program that offers 0.5 percent interest for the first $1000 savings, 1 percent for
the next $1000 and 1.5 percent for the rest.
The outputs can be identified as: 0.5 % , 1 %, 1.5 %

Invalid Valid – 0.5% Valid – 1% Valid 1.5%

-0.01 $, alphabets etc 0.00 1000.00 1000.01 2000.00 2000.01

3
 Course Code/Title:CS2602/Software Testing Unit: II

Though the program mentions three partitions, we have identified four, 3 valid and one invalid condition. The
Invalid partition will be used to test for proper error messages.
By identifying the partitions with cents eg 1000 .01, the test cases add to the clarity of the program.
Steps to identify the test cases:
1. Identify the inputs/outputs from the specification eg. input fields in a form, inputs to command line programs,
outputs-messages, calculations etc.
2. Identify the equivalence partitions or classes for the inputs/outputs identified

 For a boundary value – 1 valid equivalence partition (within the boundary) and one 1 invalid equivalence
partition (outside the boundary).
 For a Boolean, 1 valid equivalence partition (true) and 1 invalid equivalence partition (false)
 For a range, 1 valid equivalence partition (within the range) and two invalid equivalence partitions(one
outside each end of the range)
 If the input is a set of valid values, 1 valid equivalence partition (from within the set) and 1
invalid equivalence partition (outside the set)
 For a mandatory input, empty(invalid) and valid inputs.
3. Write test cases for the valid partitions followed by invalid partitions. There could be an overlap sometimes
and new partitions identified as the test case design progresses.

2. Boundary Value Analysis:

Boundary value analysis is one of the best testing techniques in the software industry for testing software functions.
It tests and detects if the software functions perfectly with the boundary values. The above technique tests values on,
inside and outside particular boundaries. Testers detect major issues by analyzing the boundary conditions and
ensuring the software works perfectly.
Boundary Value Analysis(BVA) comes from the understanding that programmers tend to make errors around the
boundaries eg. when using equal to(=), greater than, less than, greater than-equal to, less than-equal to or the
number of times a loop should be run. Boundaries are quite common in any program. For example, consider the
driving license application: age of applicant should be greater than or equal to 16 for driving license. In this
example, the most likely errors would be around the boundaries : ages equal to 15, 16, 17.
This idea of boundaries works well with equivalence partitioning because partitions must have
boundaries. Boundary Value Analysis is based on testing at the boundaries between partitions, and can be treated
as an extension to the Equivalence Partitioning(EP). Both EP and BVA work on range of numbers, values.
The rule is that we use the boundary value itself and one value(as close as you can get) on either side of the
boundary. This is called ‘three-value BVA’ or the ‘full boundary value analysis’.
Eg. The boiling point of water is at 100 degrees Celsius, so the boundary values will be at 99, 100 and 101 degrees
Two-value Boundary value analysis: In this analysis, only the boundary value and the invalid value are
considered. So, for the boiling point example, only 2 values 100 and 101 will be considered.
Steps to identify the test cases:

1. Identify the Equivalence partitions – valid and invalid partitions.

4
 Course Code/Title:CS2602/Software Testing Unit: II

2. Identify the boundaries for each of the partitions and write test cases for the boundaries identified using
BVA.

Example
Assume, we have to test a field which accepts Age 18 – 56

Minimum boundary value is 18

Maximum boundary value is 56

Valid Inputs: 18,19,55,56

Invalid Inputs: 17 and 57

Test case 1: Enter the value 17 (18-1) = Invalid

Test case 2: Enter the value 18 = Valid

Test case 3: Enter the value 19 (18+1) = Valid

Test case 4: Enter the value 55 (56-1) = Valid

Test case 5: Enter the value 56 = Valid

Test case 6: Enter the value 57 (56+1) =Invalid

3. Decision Table Testing

Decision table technique is one of the widely used case design techniques for black box testing. This is a systematic
approach where various input combinations and their respective system behavior are captured in a tabular form.

That's why it is also known as a cause-effect table. This technique is used to pick the test cases in a systematic
manner; it saves the testing time and gives good coverage to the testing area of the software application.

Decision table technique is appropriate for the functions that have a logical relationship between two and more than
two inputs.

This technique is related to the correct combination of inputs and determines the result of various combinations of
input. To design the test cases by decision table technique, we need to consider conditions as input and actions as
output.

5
 Course Code/Title:CS2602/Software Testing Unit: II

Example:If both email and password are correctly matched, the user will be directed to the email account's
homepage; otherwise, it will come back to the login page with an error message specified with "Incorrect Email" or
"Incorrect Password."

Now, let's see how a decision table is created for the login function in which we can log in by using email and
password. Both the email and the password are the conditions, and the expected result is action.

In the table, there are four conditions or test cases to test the login function. In the first condition if both email and
password are correct, then the user should be directed to account's Homepage.

In the second condition if the email is correct, but the password is incorrect then the function should display
Incorrect Password. In the third condition if the email is incorrect, but the password is correct, then it should
display Incorrect Email.

Now, in fourth and last condition both email and password are incorrect then the function should display Incorrect
Email.

In this example, all possible conditions or test cases have been included, and in the same way, the testing team also
includes all possible test cases so that upcoming bugs can be cured at testing level.

In order to find the number of all possible conditions, tester uses 2n formula where n denotes the number of inputs;
in the example there is the number of inputs is 2 (one is true and second is false).

Number of possible conditions = 2^ Number of Values of the second condition

Number of possible conditions =2^2 = 4

While using the decision table technique, a tester determines the expected output, if the function produces expected
output, then it is passed in testing, and if not then it is failed. Failed software is sent back to the development team
to fix the defect.

4. State Transition Testing

 In some systems, significant responses are generated when the system transitions from one state to
another.
 A common example is a login mechanism which allows users to authenticate, but after a specific
number of login attempts, transition to a different state, locking the account.
The general meaning of state transition is, different forms of the same situation, and according to the meaning, the
state transition method does the same. It is used to capture the behavior of the software application when different
input values are given to the same function.

Example: In ATMs, when we withdraw money from it, it displays account details at last. Now we again do another
transaction, then it again displays account details, but the details displayed after the second transaction are different
from the first transaction, but both details are displayed by using the same function of the ATM. So the same
function was used here but each time the output was different, this is called state transition. In the case of testing of
a software application, this method tests whether the function is following state transition specifications on entering
different inputs.

6
 Course Code/Title:CS2602/Software Testing Unit: II

This applies to those types of applications that provide the specific number of attempts to access the application
such as the login function of an application which gets locked after the specified number of incorrect attempts. Let's
see in detail, in the login function we use email and password, it gives a specific number of attempts to access the
application, after crossing the maximum number of attempts it gets locked with an error message.

There is a login function of an application which provides a maximum three number of attempts, and after
exceeding three attempts, it will be directed to an error page.

State transition table

STATE LOGIN VALIDATION REDIRECTED

S1 First Attempt Invalid S2

S2 Second Attempt Invalid S3

S3 Third Attempt Invalid S5

S4 Home Page

S5 Error Page
In the above state transition table, we see that state S1 denotes first login attempt. When the first attempt is invalid,
the user will be directed to the second attempt (state S2). If the second attempt is also invalid, then the user will be
directed to the third attempt (state S3). Now if the third and last attempt is invalid, then the user will be directed to
the error page (state S5).

But if the third attempt is valid, then it will be directed to the homepage (state S4).

7
 Course Code/Title:CS2602/Software Testing Unit: II

Let's see state transition table if third attempt is valid:

STATE LOGIN VALIDATION REDIRECTED

S1 First Attempt Invalid S2

S2 Second Attempt Invalid S3

S3 Third Attempt Valid S4

S4 Home Page

S5 Error Page
By using the above state transition table we can perform testing of any software application. We can make a state
transition table by determining desired output, and then exercise the software system to examine whether it is
giving desired output or not.

[Link] Guessing:
 This technique involves testing for common mistakes developers make when building similar
systems.
 For example, testers can check if the developer handled null values in a field, text in a numeric
field or numbers in a text-only field, and sanitization of inputs—whether it is possible to submit
user inputs that contain executable code, which has security significance.
 A specific type of error guessing is testing for known software vulnerabilities
that can affect the system under test.

[Link]-pairs Testing:
All-pairs testing technique is also known as pairwise testing. It is used to test all the possible discrete combinations
of values. This combinational method is used for testing the application that uses checkbox input, radio button input
(radio button is used when you have to select only one option for example when you select gender male or female,
you can select only one option), list box, text box, etc.

Suppose, you have a function of a software application for testing, in which there are 10 fields to input the data, so
the total number of discrete combinations is 10 ^ 10 (100 billion), but testing of all combinations is complicated
because it will take a lot of time.

So, let's understand the testing process with an example:

Assume that there is a function with a list box that contains 10 elements, text box that can accept 1 to 100
characters, radio button, checkbox and OK button.

The input values are given below that can be accepted by the fields of the given function.

1. Check Box - Checked or Unchecked

2. List Box - 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
3. Radio Button - On or Off
4. Text Box - Number of alphabets between 1 to 100.
5. OK - Does not accept any value, only redirects to the next page.

Calculation of all the possible combinations:

. Check Box = 2
. List Box = 10
. Radio Button = 2
. Text Box = 100
8
 Course Code/Title:CS2602/Software Testing Unit: II

. Total number of test cases = 2*10*2*100

. = 4000
The total number of test cases, including negative test cases, is 4000.

Testing of 4000 positive and negative test cases, is a very long and time-consuming process. Therefore, the task of
the testing team is to reduce the number of test cases, to do this, the testing team considers the list box values in
such a way that the first value is 0, and the other value can be any numeric number, neither positive nor negative.
Ten values are now converted into 2 values.

Values of checkbox and radio button cannot be reduced because each has a combination of only 2 values. At last,
the value of the text box is divided into three input categories valid integer, invalid integer, and alpha-special
character.

Now, we have only 24 test cases, including negative test cases.

2*2*2*3 = 24

Now, the task is to make combinations for all pair technique, into which each column should have an equal number
of values, and the total value should be equal to 24.

In order to make text box column, put the most common input on the first place that is a valid integer, on the
second place put the second most common input that is an invalid integer, and at the last place put the least
common input that is an Alpha Special Character.

Then start filling the table, the first column is a text box with three values, the next column is a list box that has 2
values, the third column is a checkbox that has 2 values, and the last one is a radio button that also has 2 values.

Text box List Box Check Box Radio Button

Valid Integer 0 Check ON

Invalid Integer Other Uncheck OFF

Valid Integer 0 Check ON

Invalid Integer Other Uncheck OFF

AlphaSpecialCharacter 0 Check ON

AlphaSpecialCharacter Other Uncheck OFF

In the table, we can see that the conventional software method results in 24 test cases instead of 4000 cases, and the
pairwise testing method only in just 6 pair test cases.

9
Course Code/Title:CS2602/Software Testing Unit: II

Black Box Testing Pros and Cons

Pros Cons

 Testers do not require technical  Difficult to automate

knowledge, programming or IT skills
 Testers do not need to learn  Requires prioritization, typically
implementation details of the system infeasible to test all user paths
 Tests can be executed by crowd sourced  Difficult to calculate test coverage
or outsourced testers  If a test fails, it can be difficult to
 Low chance of false positives understand the root cause of the issue
 Tests have lower complexity, since they simply  Tests may be conducted at low scale or on
model common user behavior a non-production-like
environment

White Box Testing

 White box testing is an approach that allows testers to inspect and verify the inner workings of a
software system—its code, infrastructure, and integrations with external systems.
 White box testing provides inputs and examines outputs, considering the inner workings of the
code.

White box testing can uncover structural problems, hidden errors and problems with specific components.

Process of performing White box Testing

The process of performing White box Testing is divided into the following steps;

Step 1 - Understand the Source Code

 The first thing a tester will often do is learn and understand the source code of the application.
 Since white box testing involves the testing of the inner workings of an application, the tester must
be very knowledgeable in the programming languages used in the applications they are testing.

Step 2 - Creating and Executing Test Cases

The second step includes the real development of test cases based on Statement/Decision/Condition/Branch
coverage, as well as the actual execution of test cases to ensure that the software has been tested
completely.

 Statement coverage will include those statements that are executed at least once during the
execution of the program.
10
Course Code/Title:CS2602/Software Testing Unit: II

 Branch coverage will include the outcome for every code module
(statement or loop).
 Conditional coverage is used to test the variables used in different types of conditional statements
like IF / ELSE, SWITCH etc.

 Decision coverage will include reports for each boolean expression present in the source code. An
expression is said to be boolean if it evaluates to either TRUE or FALSE.

TestingTechniques

Code Coverage
 One of the main goals of white box testing is to cover the source code as comprehensively as
possible. Code coverage is a metric that shows how much of an application’s code has unit tests
checking its functionality.
 Within code coverage, it is possible to verify how much of an application’s logic is actually
executed and tested by the unit test suite, using concepts like statement coverage, branch coverage,
and path coverage. These concepts are discussed in more detail below.

1. Statement Coverage
 Statement coverage is a white box testing technique that ensures all executable statements in the
code are run and tested at least once.
 For example, if there are several conditions in a block of code, each of which is used for a certain
range of inputs, the test should execute each and every range of inputs, to ensure all lines of code
are actually executed.
Example:

11
Course Code/Title:CS2602/Software Testing Unit: II

Path Coverage
 Path coverage is concerned with linearly independent paths through the code.
 Control flow diagram used to design tests in a path coverage approach.
 Testers draw a control flow diagram of the code, such as the example below.

In this example, there are several possible paths through the code:
 1, 2

12
 Course Code/Title:CS2602/Software Testing Unit: II

 1, 3, 4, 5, 6, 8
 1, 3, 4, 7, 6, 8 ,….etc.
In a path coverage approach, the tester writers unit tests to execute as many as possible of the paths through
the program’s control flow. The objective is to identify paths that are broken, redundant, or inefficient

13
Course Code/Title:CS2602/Software Testing Unit: II

3 PATH TESTING TERMINOLOGIES

14
Course Code/Title:CS2602/Software Testing Unit: II

15
Course Code/Title:CS2602/Software Testing Unit: II

16
Course Code/Title:CS2602/Software Testing Unit: II

Example:

(a) Draw the DD graph for the program

17
Course Code/Title:CS2602/Software Testing Unit: II

18
 Course Code/Title:CS2602/Software Testing Unit: II

White Box Testing Pros and Cons

Pros Cons

 Ability to achieve complete code coverage  Requires a large effort to automate

 Easy to automate  Sensitive to changes in code base, automation
 Reduces communication overhead requires expensive maintenance
between testers and developers  Cannot test expected functionality that does not
 Reduces communication overhead exist in the codebase
between testers and developers  Cannot test from the user’s
perspective

Grey Box Testing

Grey Box Testing is a technique to test the application with limited knowledge of the internal workings of an
application. In software testing, the term “the more you know, the better” carries significant weight when
testing an application.
Mastering the domain of a system always gives the tester an edge over someone with limited domain
knowledge. Unlike black box testing, where the tester only tests the application’s user interface, in grey box
testing, the tester has access to design documents and the database. With this knowledge, the tester can better
prepare test data and test scenarios while creating the test plan.
Advantages:
 Offers combined benefits of black box and white box testing wherever possible.
 Grey box testers don’t rely on the source code; instead, they rely on interface definition and functional
specifications.
 Based on the limited information available, a grey box tester can design excellent test scenarios, especially
around communication protocols and data type handling.
 The test is done from the point of view of the user and not the designer.
Disadvantages:
 Since access to the source code is not available, the ability to go over the code and test coverage is limited.
 The tests can be redundant if the software designer has already run a test case.
 Testing every possible input stream is unrealistic because it would take an unreasonable amount of time;
therefore, many program paths will go untested.
Techniques of Grey box Testing

Matrix Testing

This testing technique comes under Grey Box testing. It defines all the used variables of a particular program. In
any program, variable are the elements through which values can travel inside the program. It should be as per
requirement otherwise, it will reduce the readability of the program and speed of the software. Matrix technique is a
method to remove unused and uninitialized variables by identifying used variables from the program.

Regression Testing

Regression testing is used to verify that modification in any part of software has not caused any adverse or
unintended side effect in any other part of the software. During confirmation testing, any defect got fixed, and that
part of software started working as intended, but there might be a possibility that fixed defect may have introduced
a different defect somewhere else in the software. So, regression testing takes care of these type of defects by
testing strategies like retest risky use cases, retest within a firewall, retest all, etc.

19
 Course Code/Title:CS2602/Software Testing Unit: II

Orthogonal Array Testing or OAT

The purpose of this testing is to cover maximum code with minimum test cases. Test cases are designed in a way
that can cover maximum code as well as GUI functions with a smaller number of test cases.

Pattern Testing

Pattern testing is applicable to such type of software that is developed by following the same pattern of previous
software. In these type of software possibility to occur the same type of defects. Pattern testing determines reasons
of the failure so they can be fixed in the next software.

Usually, automated software testing tools are used in Greybox methodology to conduct the test process. Stubs and
module drivers provided to a tester to relieve from manually code generation.

Test Planning:
The goals of Test Planning
 Test Plan is needed for designing test cases and test documentation. To reach the purpose of 100%
correct code, both black box and white box testing techniques will be conducted.

 Using such techniques will enable to design test cases that validate the correctness of the
System/Module with respect to the requirements specification.

 Test Plan helps us determine the effort needed to validate the quality of the application under test.

 The test plan serves as a blueprint to conduct software testing activities as a defined process,
which is monitored and controlled by the test manager.

Software Test Plan Goals:

 To reach 100% correct code
 To identify the test methodologies for Unit and System Testing
20
Course Code/Title:CS2602/Software Testing Unit: II

 To provide a procedure for Unit and System Testing

 To ensure all Functional and Design Requirements are implemented as clarified in the
documentation
 To identify the documentation process for Unit and System Testing

Test Plan
A Test Plan is a detailed document that catalogs the test strategies, objectives, schedule, estimations,
deadlines, and resources required to complete that project. Think of it as a blueprint for running the
tests needed to ensure the software is working correctly – controlled by test managers.

 A well-crafted test plan is a dynamic document that changes according to progressions in the
project and stays current at all times.
 It is the point of reference based on which testing activities are executed and coordinated
among a QA team.
 The test plan is also shared with Business Analysts, Project Managers, Dev teams, and anyone
associated with the project. This mainly offers transparency into QA activities so that all
stakeholders know how the software will be tested.

Importance of Test Plans

 They help individuals outside the QA teams (developers, business managers, customer-facing
teams) understand exactly how the website or app will be tested.
 They offer a clear guide for QA engineers to conduct their testing activities.
 They detail aspects such as test scope, test estimation, strategy, etc.
 Collating all this information into a single document makes it easier to review by management
personnel or reuse for other projects.
Components of a Test Plan

 Scope: Details the objectives of the particular project. Also, it details user scenarios to be used in
tests. The scope can specify scenarios or issues the project will not cover if necessary.
 Schedule: Details start dates and deadlines for testers to deliver results.
 Resource Allocation: Details which tester will work on which test.
 Environment: Details the test environment‘s nature, configuration, and
availability.
 Tools: Details what tools will be used for testing, bug reporting, and other relevant activities.
 Defect Management: Details how bugs will be reported, to whom, and what each bug report
needs to be accompanied by. For example, should bugs be reported with screenshots, text logs, or
videos of their occurrence in the code?
 Risk Management: Details what risks may occur during software testing and what risks the
software itself may suffer if released without sufficient testing.
 Exit Parameters: Details when testing activities must stop. This part describes the expected
results from the QA operations, giving testers a benchmark to compare actual results.

The five most important components of a test plan are:

1. Test Objectives & Strategy:
This defines the overall goals and objectives of the testing effort, including what features and
functionality of the software will be tested, and what quality standards the software must meet before
it can be released. Test strategy outlines the overall approach to testing, including the types of tests

21
Course Code/Title:CS2602/Software Testing Unit: II

that will be performed, the tools and resources that will be used, and the personnel responsible for
executing the tests.
2. Scope of testing:
This defines the boundaries of the testing effort and what will be included and excluded from the
testing process. It also identifies the various levels of testing (such as unit, integration, system, and
acceptance testing) that will be performed.
3. Test deliverables & estimates:
This defines the documents and artifacts that will be produced as part of the testing effort, such as test
cases, test plans, test scripts, and test reports. Parallely, cost estimates is also crucial for planning and
budgeting, and thus provides a basis for measuring progress and identifying potential issues.
4. Test environment:
This defines the hardware and software environment in which the testing will be performed, including
the operating system, hardware, and software configurations. It also includes information on the test
data that will be used and the test tools that will be employed.
5. Roles and Responsibilities:
This defines the roles and responsibilities of the team members involved in the testing effort,
including who will be responsible for creating test cases, executing tests, and reporting defects. It also
outlines the communication channels that will be used to keep stakeholders informed about the testing
progress.
Steps to create a Test Plan
Creating an effective Test Plan involves the following steps:

 Product Analysis
 Designing Test Strategy
 Defining Objectives
 Establish Test Criteria
 Planning Resource Allocation
 Planning Setup of Test Environment
 Determine test schedule and estimation
 Establish Test Deliverables

1. Product Analysis
Start with learning more about the product being tested, the client, and the end- users of similar
products.
Ideally, this phase should focus on answering the following questions:
 Who will use the product?
 What is the primary purpose of this product?
 How does the product work?
 What are the software and hardware specifications?
22
Course Code/Title:CS2602/Software Testing Unit: II

2. Designing Test Strategy

The Test Strategy document is developed by the test manager following:
and defines the

 Project objectives
a an d h ow t o achieve them.
 The amount of effort and cost required for testing.

More specifically, the document

c must detail out:
 Scope of Testing: Contains the software components (hardware,
software, middleware) to be tested and those that will not be tested.
 Type of Testing: Describes the tests to be used in the project. This
is necessary since each test identifies specific types of bugs.
 Risks and Issues: Describes all possible risks that may occur during testing
– tight deadlines, poor management, inadequate or erroneous budget
estimate – and the effect of these risks on the product or business.
 Test Logistics: Mentions the names of testers (or their skills) and the tests to
be run by them. This section also includes the tools and the schedule laid out
for testing.

[Link] Objectives
 This phase defines the goals and expected results of test execution. Since all
testing intends to identify as many defects as possible, the objects must
include:
 A list of all software features – functionality, GUI, performance standards-
must be tested.
 The ideal result or benchmark for every aspect of the software that needs
testing. This is the benchmark to which all actual results will be compared.

4. Establish Test Criteria

Test Criteria refers to standards or rules governing all activities in a testing
project. The two main test criteria are:

 Suspension Criteria: Defines the benchmarks for suspending all tests. For
example, if QA team members find that 50% of all test cases have failed,
then all testing is suspended until the developers resolve all of the bugs that
have been identified so far.
 Exit Criteria: Defines the benchmarks that signify the successful
completion of a test phase or project. The exit criteria are the expected
results of tests and must be met before moving on to the next stage of
development. For example, 80% of all test cases must be marked successful
before a feature or portion of the software can be considered suitable for
public use.

5. Planning Resource Allocation

23
Course Code/Title:CS2602/Software Testing Unit: II

 This phase creates a detailed breakdown of all resources required for project
completion. Resources include human effort, equipment, and all
infrastructure needed for accurate and comprehensive testing.
 This part of test planning decides the project’s required measure of
resources (number of testers and equipment). This also helps test managers
formulate a correctly calculated schedule and estimation for the project.
[Link] Setup of Test Environment
 The test environment refers to the software and hardware setup on which
QAs run their tests.
 Ideally, test environments should be real devices so testers can monitor
software behavior in real user conditions.
 Whether it is manual testing or automation testing, nothing beats real
devices, installed with real browsers and operating systems are non-
negotiable as test environments.
[Link] Test Schedule and Estimation
 For test estimation, break down the project into smaller tasks and allocate
the time and effort required for each.
 Then, create a schedule to complete these tasks in the designated time with a
specific amount of effort.
 Creating the schedule, however, does require input from multiple perspectiv
 Employee availability, number of working days, project deadlines,
and daily resource availability.
 Risks associated with the project which has been evaluated in
an earlier stage.
[Link] Test Deliverables
 Test Deliverables refer to a list of documents, tools, and other equipment
that must be created, provided, and maintained to support testing activities
in a project.
 A different set of deliverables is required before, during, and after testing.
 Deliverables required before testing
Documentation on
 Test Plan
 Test Design
 Deliverables required during testing
Document
ation on
 Test
Scripts
 Simulators or Emulators (in early stages)
 Test Data
 Error and execution logs
 Deliverables required after testing
Documentation on
 Test Results
 Defect Reports

24
Course Code/Title:CS2602/Software Testing Unit: II

 Release Notes

Test Strategy

 Test strategy is a high-level plan consisting of principles that guide the

overall software testing process.
 It provides a structured approach to the entire QA team, guiding them toward
achieving testing objectives in the most efficient way.

Test Strategy Document

 The test strategy document is a well-written document that outlines the
precise methodology and goals of the testing project. It is an important
document for QA teams and is based on actual business requirements.
 The test strategy document addresses all the questions about what you want
to achieve and how you plan to do it in the project.

Need a Test Strategy

 Guides the testing effort by providing focus, clarity, and effective
risk management.
 Ensures efficiency, effectiveness, and adherence to standards in
testing practices.
 Promotes better collaboration between members of the QA team.
 Ensures that all members are aligned on the overall vision of the project.
 Acts as reference for resource planning and allocation for optimal utilization.
 Allows you to track progress more efficiently.

Test Strategy Document Includes

Scope and Overview
 Project overview along with information on who should use this document.
Also, include details like who will review and approve this document.
 Define testing activities and phases to be carried out with timelines
with respect to overall project timelines defined in the test plan.
 It defines parameters like
 Who will review the document?
 Who will approve this document?
 Software Testing activities carried out with timelines

Test Approach
 Define the testing process, level of testing, roles, and responsibilities of
every team member.
 Also, define the change management process. This includes defining change
request submissions, templates to be used, and processes to handle the
request.
 It defines parameters like
 Process of testing
 Testing levels

25
Course Code/Title:CS2602/Software Testing Unit: II

 Roles and responsibilities of each team member

 Types of Testing (Load and Security testing, Performance testing etc.)
 Testing approach & automation tool if applicable
 Adding new defects, re-testing, Defect triage, Regression Testing
and test sign off.

Test Environment
 The test environment setup should outline information about the number of
environments and the required setup for each environment.
 Define the number of users supported in each environment, access roles for
each user, software and hardware requirements like operating system,
memory, free disk space, number of systems, etc.
 Define test data backup and restore strategy that who will take backups,
when to take a backup, what to include in backup, when to restore the
database, who will restore it.
 It defines parameters like
 Define the number of requirement and setup required for each
environment
 Define backup of test data and restore strategy
Testing Tools
 Define test management and automation tools required for test execution.
For performance, load and security testing, describe the test approach and
tools required.
 Mention whether it is an open source or commercial tool and how many
users are supported on it and plan accordingly.
 It defines parameters like
 Automation and Test management tools needed for test execution
 Figure out a number of open-source as well as commercial tools
required, and determine how many users are supported on it and plan
accordingly

Release Control
 Release Control is a crucial component of the test strategy document. It’s
used to make sure that test execution and release management strategies
are established in a systematic way.
 The release management plan with proper version history will ensure test
execution of all modifications in that release.
 It specifies the following information-
 Different software versions in test and UAT(User Acceptance test)
environments can occur from unplanned release cycles.
 All adjustments in that release will be tested using the release
management strategy, which includes a proper version history.

26
 Course Code/Title:CS2602/Software Testing Unit: II

Risk Analysis
 List all the risks that you envision. Provide a clear plan to mitigate
these risks along with a contingency plan in case you see these risks in
reality.
 It defines parameters like
 List all risks that you can estimate
 Give a clear plan to mitigate the risks also a contingency plan

Review and Approvals

 When all these activities are defined in the test strategy plan,
 It defines parameters like
 All these activities are reviewed and signed off by the business
team, project management, development team, etc.
 Summary of review changes should be traced at the beginning of
the document along with an approved date, name, and comment.
 Also, it’s a living document meaning this should be continuously
reviewed and updated with testing process enhancements.

Comparison between the Test Plan and Test Strategy

Test Plan Test Strategy
Test Plan is a document that describes the scope, Test Strategy describes how testing needs to be
objective and weight on software testing task. done.

Test Plan is used at the project level. Test Strategy is used at the
organization level.
Test Plan has the primary goal of how Test Strategy has the primary goal of
to test, when to test and who will verify. what technique to follow and which module to
check.
Test Plan can be changed. Test Strategy can’t change.
Test Plan is carried out by the test The Test Strategy is carried out by the
manager. project manager.
Focused on Detailed test objectives, Focused on Testing approach, test
levels, types, and techniques
test cases, test data, and expected
results.
Specific phase, feature, or component Entire testing effort across the project
of the software.
Highly detailed, specifying test Less detailed and more abstract
scenarios, cases, scripts, and data
The test plan is performed by a lead or A test strategy is performed by the
testing manager. project manager.

27
Course Code/Title:CS2602/Software Testing Unit: II

It describes when to test, who will test, It says which module to test and what
how to test, and what to test. kind of method to follow.
The test plan is mainly derived from Test strategy is derived from BRS (business
requirement specification).
SRS (software requirement
specification).
Test Phases
 Software Testing Life Cycle consists of 6 phases, each with defined
entry and exit criteria and associated activities and deliverables.
 Entry and exit criteria define when a phase can start and when it can end.
 Activities and deliverables define what actions are performed and what the
expected result is.
6 Key Phases of Testing
1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure

Requirement Analysis
During this phase, feature requirements collected in the SDLC process are
evaluated to identify testable aspects. If necessary, testing teams may need to
consult with stake holders to clarify requirements. These requirements can
either be functional or non-functional, defining what a feature can do or it’s
characteristics respectively. The ability to automate testing is also evaluated
during this phase.

Activities involved
 Identify types of tests to be performed.
 Gather details about testing priorities and focus.
 Prepare Requirement Traceability Matrix (RTM).

Test Planning
During this phase, the test strategy is outlined in a test plan document. This
strategy includes tools needed, testing steps, and roles and responsibilities. Part
of determining this strategy is a risk and cost analysis and an estimated timeline
for testing.
Activities involved
 Preparation of test plan/strategy
 Test tool selection
 Test effort estimation

28
Course Code/Title:CS2602/Software Testing Unit: II

 Resource planning and

determining roles and
responsibilities.
 Training requirement

Test Case Development

During this phase, test cases are created. Each case defines test inputs,
procedures, execution conditions, and anticipated results. Test cases should
be transparent, efficient, and adaptable. Once all test cases are created, test
coverage should be 100%. Any necessary automation scripts are also
created during this phase.
Activities involved
 Create test cases, automation scripts (if applicable)
 Review and baseline test cases and scripts
 Create test data

Test Environment Setup

During this phase, testing environments are configured and deployed. This
phase may include a variety of testing tools, including TestComplete, Selenium,
Appium, or Katalon Studio. Sometimes, this phase also includes setting up test
servers. Once environments are deployed, smoke tests are performed to ensure
that environments are working as expected with all intended functionality.
Activities involved
 Understand the required architecture, environment set-up and
prepare hardware/software requirement list for the Test Environment.
 Setup test Environment and test data
 Perform smoke test on the build

Test Execution
During this phase, features are tested in the deployed environment, using the
established test cases. Expected test results are compared to actual and results
are gathered to report back to development teams.
Activities
 Execute tests as per plan
 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the Defect fixes
 Track the defects to closure

Test Cycle Closure

This is the last phase of the STLC, during which a test result report is prepared.
This report should summarize the entire testing process and
provide
comparisons between expected results and actual. These comparisons include
objectives met, time taken, total costs, test coverage, and any defects found.

29
Course Code/Title:CS2602/Software Testing Unit: II

Activities
 Evaluate cycle completion criteria based on Time, Test
coverage, Cost, Software, Critical Business Objectives, Quality
 Prepare test metrics
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work product to
the customer.
 Test result analysis

Resource Requirement of Test Plan

 Resource requirement is a detailed summary of all types of resources
required to complete project task. Resource could be human, equipment and
materials needed to complete a project.
 The resource requirement and planning is important factor of the test
planning because helps in determining the number of resources (employee,
equipment…) to be used for the project.
 Therefore, the Test Manager can make the correct schedule & estimation for
the project.

Some of the following factors need to be considered:

 Machine configuration (RAM,processor,disk)needed to run the
product under test.
 Overheads required by test automation tools, if any
 Supporting tools such as compilers, test data generators,
configuration management tools.
 The different configurations of the supporting software(e.g. OS)that
must be present
 Special requirements for running machine-intensive tests such as
load tests and performance tests.
 Appropriate number of licenses of all the software

Human Resource: The following table represents various members in your project
team

No. Member Tasks

1. Test Manager Manage the whole project Define project

directions Acquire appropriate resources

30
Course Code/Title:CS2602/Software Testing Unit: II

2. Tester Identifying and describing appropriate test

techniques/tools/automation architecture
Verify and assess the Test Approach Execute the tests, Log results,
Report the defects.

No. Member Tasks

3. Developer in Implement the test cases, test program, test suite etc.
Test

4. Test Administrator Builds up and ensures test environment and assets are managed and
maintained Support Tester to use the test environment for test execution

5. SQA Take in charge of quality assurance Check to confirm whether the testing
process is meeting specified requirements
members

System Resource: For testing, a web application, you should plan the resources
as following tables:

No. Resources Descriptions

1. Server Install the web application under test This includes a separate web server,
database server, and application server if applicable

2. Test tool The testing tool is to automate the testing, simulate the user operation,
generate the test results There are tons of test tools you can use for this
project such as Selenium, QTP…etc.

3. Network A Network include LAN and Internet to simulate the real business and
user environment

4. Computer The PC which users often use to connect the web server

31
Course Code/Title:CS2602/Software Testing Unit: II

Test Metrics Life Cycle

The various stages of the test metrics lifecycle are:

ANALYSIS

REPORT COMMUNICATION

EVALUATION

Analysis
 The metrics must be recognized.
 Define the QA metrics that have been identified.

Communicate
 Stakeholders and the testing team should be informed about the
requirement for metrics.
 Educate the testing team on the data points that must be collected in order
to process the metrics.

Evaluation
 Data should be captured and verified.
 Using the data collected to calculate the value of the metrics

Report
 Create a strong conclusion for the paper.
 Distribute the report to the appropriate stakeholder and representatives.
 Gather input from stakeholder representatives.

Formula for Test Metrics

To get the percentage execution status of the test cases, the following formula
can be used:

Percentage test cases executed = (No of test cases executed / Total no of test
cases written) x 100

Similarly, it is possible to calculate for other parameters also such as test cases
that were not executed, test cases that were passed, test cases that were failed,
test cases that were blocked, and so on. Below are some of the formulas:

1. Test Case Effectiveness:

Test Case Effectiveness = (Number of defects detected / Number of test cases
run) x 100

32
 Course Code/Title:CS2602/Software Testing Unit: II

2. Passed Test Cases Percentage: Test Cases that Passed Coverage is a metric
that indicates the percentage of test cases that pass.
Passed Test Cases Percentage = (Total number of tests ran / Total number of
tests executed) x 100

3. Failed Test Cases Percentage: This metric measures the proportion of

all failed test cases.
Failed Test Cases Percentage = (Total number of failed test cases / Total
number of tests executed) x 100

4. Blocked Test Cases Percentage: During the software testing process,

this parameter determines the percentage of test cases that are blocked.
Blocked Test Cases Percentage = (Total number of blocked tests / Total number
of tests executed) x 100

5. Fixed Defects Percentage: Using this measure, the team may determine the
percentage of defects that have been fixed.
Fixed Defects Percentage = (Total number of flaws fixed / Number of defects
reported) x 100

6. Rework Effort Ratio: This measure helps to determine the rework

effort ratio.
Rework Effort Ratio = (Actual rework efforts spent in that phase/ Total actual
efforts spent in that phase) x 100

7. Accepted Defects Percentage: This measures the percentage of defects that

are accepted out of the total accepted defects.

Accepted Defects Percentage = (Defects Accepted as Valid by Dev Team /

Total Defects Reported) x 100

8. Defects Deferred Percentage: This measures the percentage of the defects

that are deferred for future release.
Defects Deferred Percentage = (Defects deferred for future releases / Total
Defects Reported) x 100

Test Effectiveness
Test effectiveness finds a solution to “how good are the tests?” It evaluates the bug-finding
quality and ability of a test set. Test effectiveness measures generally express the difference
between the total number of defects reported by the QA team and the overall defects found in
terms of percentage.

Test effectiveness using defect containment efficiency: The

higher the test effectiveness, the better the test set and the lesser the long-term
maintenance effort will be. For instance, if the test effectiveness is 70%, it
concludes that 20% of the defects are removed from the testing operation.

33
 Course Code/Title:CS2602/Software Testing Unit: II

Context-based test effectiveness using team assessment: Defect

containment efficiency metrics do not come in handy in the following cases:

 Already mature product

 Buggy and unstable product
 Lacking enough tests due to constraints of time or resource

Test Schedule
A test schedule includes the testing steps or tasks, the target start and end dates,
and responsibilities. It should also describe how the test will be reviewed,
tracked, and approved.

It is used to explain the timing to work, which needs to be don e or

this attribute
covers when exactly each testing activity should start and end? And the exact
data is also mentioned for every testing activity for the particular date.

 For the particular activity such as Writing test case, Execution process, there
will be a starting date and ending date; for each testing to a specific build,
f
there will be the specified date.
 Test Schedule is created to complete these tasks.
 Making schedule is a common term in software project management. By
u
creating a solid schedule in the Test Planning, the Test Man ger cana use it as
tool for monitoringeth project progress, control the cost overruns.

To create the project schedule, the Test Manager needs several types of input as
below:

 Employee and project deadline: The working days, the project deadline,

34
Course Code/Title:CS2602/Software Testing Unit: II

resource availability are the factors which affected to the schedule.

 Project estimation:B ase on the estimation, the Test Manager knows how
long it takes to complete the project. So he can make the appropriate project
schedule.
 Project Risk : Understanding the risk helps Test Manager add enough extra
time to the project schedule to deal with the risks.

Creating Test Schedule

Test Schedule ID: Describe the Test Schedule ID Start End

Date Date
Product ID / Describe the Name of the Product / Project
Name:

Product Version or Build: Describe the Current Version or Build of the

Product
Present Owner : Describe the Name of the owner of the Test
Schedule Document at present.

Created On: Describe the Date on which Test Schedule

Document was created initially
Review On: Describe the Date on which Test Schedule
Document was last Reviewed & Updated
Review By: Describe the Name & Position of the Reviewer.

Review Comments: Describe the Comments if any, whether

comments have been incorporated or Not
Current Version: Describe the Current Version of the Test
Schedule Document
Change Details: Describe the Description of Change,
Affected Section of the Test Plan
Current Status: Draft / In Process / Approved

Signing Off Name Position Signatur

Authority: e, Date
Describe E.g. QA
the Name Manager, Dev.
Manager, Product
Manager,
Release Team
Manager

35
 Course Code/Title:CS2602/Software Testing Unit: II

Test Monitoring and Test Control

In order to ensure that test suites are running smoothly, QA managers and other senior
personnel must implement management methodologies such as Test Monitoring and Test
Control. These are essentially management practices that have to be put in place so that
managers can monitor test progress and align it for maximum accuracy and efficiency.
Test Monitoring
Test Monitoring in test execution is a process in which the testing activities and testing efforts
are evaluated in order to track current progress of testing activity, finding and tracking test
metrics, estimating the future actions based on the test metrics and providing feedback to the
concerned team as well as stakeholders about current testing process.
Test Monitoring involves:
 Offering feedback to the QA team and other stakeholders regarding the progress of
sprint test cycles.
 Conveying test results achieved so far to all relevant parties.
 Identifying and tracking relevant test metrics.
 Planning and estimation to determine the future course of action based on the metrics
being tracked.
Relevant Test Metrics to be tracked:
 Test Coverage.
 Test Execution Metrics: Number of test cases that have passed, failed, been blocked,
or are on hold.
 Defect Metrics.
 The cost of the project so far.
 Resources consumed by the project so far.
 Status of each task: on schedule, lagging, or ahead of schedule.
 Requirement Traceability.

What Do We Monitor?
The following metrics will be monitored during the testing process,

 Cost
 Schedule
 Resources
 Quality

Cost
It is crucial to monitor and control project costs. You have to estimate and keep track of the
costs involved. Making sure the project stays within its budget is crucial and requires getting
the estimations right from the start.
As the project progresses, it’s vital to watch these expenses closely. To handle all these tasks
effectively, you need to oversee and manage the project budget. Keeping an eye on the budget
is a must for successfully finishing a project on target.
Schedules
Maintaining proper schedules is also vital. Think of it like driving a car without knowing how
long the trip will be. Just like you need a plan to know when you’ll reach your destination,
projects need schedules too. No matter how big or small the project is, having a schedule is
crucial.
Planned schedules will help you tell the following,

36
 Course Code/Title:CS2602/Software Testing Unit: II

 What is the best time to finish each task?

 Are any tasks already completed?
 The right order to complete tasks

Resources
Resources for a project include everything that is required to do the tasks. They can be people
or tools, depending on the job. Resources can slow down a project. Sometimes, plans change
– people quit, or money gets less. If you find out about these problems early, you can fix
them.
Quality
Monitoring Quality means checking specific work items to see if they meet the expected
standards. If they don’t meet the standards, you have to come up with possible ways to fix the
issues.

When to collect data for Test Monitoring?

The frequency with which data should be collected for monitoring purposes depends on the
nature of the project. For example:
 If the project is slated to be completed in one month, it makes sense to collect
monitoring data weekly.
 If the test suites are especially complicated and require close supervision, data might
have to be accrued twice a week or more.
How to Do Test Monitoring?
Multiple stages come under the test monitoring process. Most of which are influenced by
factors, such as project timeline, goals, available resources for testing, and possible
roadblocks.
However, there are a set of general steps that you can follow to perform test monitoring:

 Create a test monitoring plan

Similar to any other process in testing, start with creating a test monitoring plan. Your
objective should be to clearly define the goals of test monitoring along with the necessary
points it should capture. Decide what metrics to capture, when to record them, and how to
assess them. For instance, cost, time, and resources used could be metrics important to your
test monitoring plan. You can collect these data bi-weekly and use them to formulate better
decisions to improve the quality and delivery of testing.

 Update and report the progress

Next up is to keep the report updated with changing scenarios. You have jotted down the
points to capture in the plan. Then, you would just need to keep updating the test control data
and make adjustments to the testing process to get optimum output.

 Analyze the progress reports to make the right decisions

As mentioned, after updating the records regularly, use the newly added data. Compare the
original or old data with the new data to analyze. It will help you to understand if the progress
is in the positive direction or the negative direction. For example, you can see how much time

37
 Course Code/Title:CS2602/Software Testing Unit: II

you initially spent on individual tasks and what resources were spent on it. Then, compare it
to the updated information to assess the testing project direction.

 Present the report

Lastly, make it understandable for stakeholders and other team members to read the report
and make informed decisions in their projects (if any).

How to evaluate progress through collected data?

It is best to establish the evaluation process in the monitoring plan laid out to teams at the
beginning of the project so that they know exactly how their work will be judged. Two easy
methods to define progress would be:
1. Compare the progress in the plan with the actual progress made by the team.
2. Look at the previously defined criteria to evaluate the project’s progress. For example,
if the effort to complete a task was 20% higher than it was meant to be (according to
the plan), that is a marker of how the project is progressing

Test Control
Test Control occurs based on the results of Test Monitoring. It refers to taking corrective
action based on test monitoring reports to improve quality and efficiency. Some examples of
test control activities would be:
 Prioritize testing efforts in a different way.
 Reorganize test schedules and deadlines.
 Restructure the test environment.
 Reprioritize the test cases and conditions.
Test Control is essentially modifying the testing process so that it becomes better suited for
meeting the defined objectives. This may require adding extra resources, reducing the scope
of release, or splitting the release into multiple releases, etc. The specific test control activities
implemented depend on various factors, including stakeholders’ opinions, budget, project
complexity, and tester availability.
Test Control goes hand-in-hand with Test Monitoring. Once Monitoring identifies any
bottlenecks that may prevent a test cycle from meeting its goals, Control activities come into
play to ensure objectives are met.
What is Test Control?
While test monitoring gives a clear perspective on the ongoing testing tasks, test control helps
teams to take corrective measures based on the observations gained from test monitoring. In
simple words, it is the practice of actively managing and regulating the testing process to
ensure that it aligns with project goals, is effective, and delivers reliable results.
Test control is a crucial aspect of software testing that involves managing and regulating
the testing process to ensure it is effective and efficient.
It involves making decisions based on the information gained from the test monitoring
process. Here, the tests will be prioritized, the test schedules will be revised, changes will be
made to the test environment, and other refinements related to testing activities might be done
to enhance the efficiency and quality of the future testing process.
Why do you Need Test Control?
If you are a tester, project manager, or a developer, you would know how the testing (or even
developing) process can easily go astray if not managed properly. For such reasons, having a
test control in place for software testing is a necessity not a want.

38
 Course Code/Title:CS2602/Software Testing Unit: II

Some problems you can expect to encounter revolve around product functionality,
performance, UI, and usability. The challenges can become an issue for timely release of the
product and customer satisfaction.
Test control helps in identifying these roadblocks and effectively managing the software
quality.
Executing Test Control Activities
These steps are critical for test control activities:

 Monitor the process: Monitor the progress of testing activities against the predefined
plan and objectives. Use testing metrics and progress reports to track the execution of
test cases, defect discovery, and resolution.
 Identify the deviations: Discover any deviations from the planned testing activities,
quality standards, or project objectives.
 Assess the risks: Evaluate the impact of identified deviations on project timelines,
budget, quality objectives, and overall testing goals.
 Prioritize the issues: Consider the severity and potential consequences of deviations
on the project’s success criteria to prioritize deviations’ impact on project goals, and
urgency for resolution.
 Take corrective actions: Determine the root causes of issues to develop specific
corrective actions required to address each identified deviation effectively.
 Monitor progress: Continuously monitor the progress of implementing corrective
actions and resolving identified issues. Track key performance indicators (KPIs) to
assess the effectiveness of corrective measures and their impact on the testing process.

Corrective Measures in Test Control

Once your team has identified the issues and variation from the plan, follow the below
corrective measures:

 Prioritize the testing efforts: Based on issue criticality and area of application,
choose which tests to perform before another.
 Review the testing schedules: If you are behind schedule due to whatever reason, it
is time to review and revise the timeline to keep on track.
 Manage the resource allocation: Not every testing activity will require the same
amount of resources, be it workers or tools. You will have to identify how much
resources different testing processes require to do the allocation accordingly.
 Change the testing scope: Lastly, take a different route if test coverage is inadequate
or if updates/modifications are introduced in the testing process.

39
 Course Code/Title:CS2602/Software Testing Unit:III
Unit III: TEST CASE DESIGN 9

Test Case Specification- Writing effective test cases, Traceability matrix, Test Data Generation- Generating test
data for different scenarios.
Test Case Specification:
Test Case
“A test case has components that describe input, action, and an expected response, in order to
determine if a feature of an application works correctly.”
 Once the test cases are created from the requirements, it is the job of the testers to execute those
test cases.
 The testers read all the details in the test case, perform the test steps, and then based on the
expected and actual result, mark the test case as Pass or Fail.

Test Case Attributes

The different attributes of a test case that comprise a test case and make them more reliable, clear, and
concise avoiding or reducing any sort of redundancy.
Test Case
Attributes Explanation

TestCaseId A unique identifier of the test case.

It is a mandatory field that uniquely identifies a test case.
Example: TC_01 or TId01

Test Summary One-liner summary of the test case. This is an

optional field.
Normally the test cases either have the ‘Test Summary’
field or the ‘Description’ field.

Description Detailed description of the test case.

This field defines the purpose of the test case. Example: Verify that
the user can login with a valid username and valid password.

Prerequisite or A set of prerequisites that must be followed before executing the test
Pre-condition steps.
Example: While testing the functionality of the application
after login, we can have the pre-requisite field as “User should be logged in to
the application”.

Test Steps Detailed steps for performing the test case.

This is the most important field of a test case.
Test Data The value of the test data used in the test case.
Example: While testing the login functionality, the test data
field can have the actual value of the username and password to be used
during test execution.

1
Course Code/Title:CS2602/Software Testing Unit:III
Expected result The expected result in order to pass the test.
Example: The user should successfully login and navigated to home page.

Actual result The actual result after executing the test steps.
This field is filled during test execution only. The actual result observed
during the test case execution.
Test Result Pass/Fail status of the test execution.
Based on the expected result and the actual result, the test case is marked as
passed or Failed.
Apart from Pass/Fail, the other values are
Deferred, when the test case is marked to be executed later, for some reason.
Blocked, when the test case execution is blocked due to
some other issue in the application).

Automation Status Identifier of automation – whether the application is automated or not.

This is an optional field used only when we have
automation in the project.

Date The test execution date.

This field helps in keeping track of multiple test execution cycles.

Executed by Name of the person executing the test case.

This field helps when there are multiple team members working on the test
execution activity.

To write test cases:

 Test cases are the blueprints that testers will follow, so it must be clear, thorough, and accurate.
The outlined 10 steps for writing new test cases or revisiting and evaluating existing test cases.
1. Define the area you want to cover from the test scenario.
2. Ensure the test case is easy for testers to understand and execute.
3. Understand and apply relevant test designs.
4. Use a unique test case ID.
5. Use the requirements traceability matrix in testing for visibility.
6. Include a clear description in each test.
7. Add proper pre-conditions and post-conditions.
8. Specify the exact expected result.
9. Utilize suitable testing techniques.
10. Get your test plan peer-reviewed before moving forward.

Examples for Test Case: Online Shopping Application

Module 1: Registration
2
Course Code/Title:CS2602/Software Testing Unit:III
Module 2: Login
Module 3: Add a Product

Module 1: Registration
Test Test Pre- condition Test Data Expected Actual Pass/
CaseId Result Result Fail
Description/
Objectives
TD01 Register new User need to Email-ID: All the New User Pass
user provide valid xyz@gma Required registration
details. [Link] fields need completed.
to be filled
Ph no : with Valid
Eg: Email ID,
01234567 inputs.
Ph no
89

TD02 Register new User need to Email-ID: Email ID Not Registered Fail
user provide valid xyz@gma & Ph no.
details. [Link] are incorrect.
Invalid
Ph no : inputs
Eg: Email ID,
01234567
Ph no 891

Module 2: Login
Test Test Description/ Pre- condition Test Data Expected Actual Pass/
CaseId Objectives Result Result Fail

TD01 Verify user Enter Valid Email-ID: Redirecte d Login Pass

login with Email-ID xyz@gma to login Successful.
Valid Inputs and [Link] page.
Password.
Password:
1234

TD02 Verify user Enter Invalid Email-ID: Email ID & Logi Fail
login with Email-ID xyz@gma Ph no. Are n
Invalid Inputs and [Link] incorrect. Faile
Password. d.
Password:
123456 Redirected
to

3
Course Code/Title:CS2602/Software Testing Unit:III

Log
in Page.

TD03 Forget Enter Email-ID: User Set As Pass

Password Registered xyz@gma new password Expected,
/Valid [Link] after verifying
Email-ID OTP.
OTP:
1212 Password
Changed
Password: Successfully.
Name
Redirect to login
Page.

Module 3: Add/Delete a Product

Test Test Pre- condition Test Data Expected Actual Pass/
CaseId Description/ Result Result Fail

Objectives
TD01 User should User ItemName: Item added to As Expected, Pass
select the item Should AB123 cart.
and add to the Logged ItemId:#01
cart. in. ItemCost: 100 Increment the
Amount and
Count
of item

TD02 Show total Item must Total Displays As Pass

4
Course Code/Title:CS2602/Software Testing Unit:III

amount of present in the Amount: the details Expected,

items in cart. cart. 100 and the
total amount
in the
cart.

Proceed to
Order.

TD03 Remove item Atleast one ItemName: Item removed As Expected, Pass
from item AB123 from cart.
the cart must be
present in the ItemId:#01 Decrement the
cart. Amount and
Count
Click on of item

remove from
cart.

TD04 Proceed to Items Must ItemName: Display the Payment Pass

Checkout. present in AB123 details and successful
the cart. the total .
ItemId:#01 amount and
Click Proceed shipping Order
to Checkout. Shipping address. Placed.
Address: Plat
Enter no, Street,City Proceed to
Shipping State,Count ry. payment.

Address.

TD05 Proceed to Items Must ItemName: Display the Payment Fail

Checkout. present in AB123 details and the Unsuccess ful.
the cart. total amount
ItemId:#01 and Order
shipping

5
Course Code/Title:CS2602/Software Testing Unit:III

Click Proceed Shipping address. Cancelled.

to Checkout. Address: Plat
no, Street,City Proceed to
Enter State,Count ry. payment.
Shipping
Address.

Test Plan vs. Test Case

Test Plan Test Case

A large detailed document that covers Specific and precise document for a
management aspects and particular testing feature that covers only testing
testing aspects in the entire testing aspects.
project.
Testers, test leaders, managers, Only testing teams and test leaders.
stakeholders, and other departments need
to be updated about the testing
process.
Both testing and project managing Only testing aspects such as test steps, test data, test
aspects like schedule, scope, potential environment, intended test results, real test results, test
risks, staff responsibilities, bugs status,
reporting, and more. etc.

The duration of the test plan is until The duration of test case is until the
the end of the whole testing project. end of the particular testing process.
An up-to-date document used till the end Ensures testers are equipped with all required step-by-
of the project. step processes and details to test the intended
functionality.
Control whole testing process. Allows identifying unexpected bugs.

Contain the testing history. Providing an example to the desired results.

Keeps everyone aligned. Ensure testers aren’t missing important

steps.

Types of Software Test Case Design Techniques

 Course Code/Title:CS2602/Software Testing Unit:III

The various types of test case design techniques are listed below −

Requirement Based Techniques

It is also known as the black box testing technique that validates the features of the software without considering its

internal working. It consists of the procedures listed below −

Boundary Value Analysis − In this methodology, the verification is done around the boundary values of the valid
and invalid data sets. The behavior of the software at the edge of the equivalence partitions has a higher
probability of finding errors.
 Equivalence Partitioning − This methodology allows the testers to segregate input data into groups. It reduces
 the total count of tests without compromising the test coverage.
 Decision Table − This methodology allows building of test cases from the decision tables created using
 various combinations of input data and their outcomes which originate from different situations and use cases.
 State Transition Diagram − This methodology is used to test the change in the states of a software using different
 inputs. If the conditions under which the input are updated, then there are changes to the states of the software.
 Use Case Testing − This methodology is focussed on verifying the test scenarios involving the entire software.

Structure Based Techniques

It is also known as the white box testing technique that validates the internal working of the software by the developers.

It consists of the procedures listed below −

Statement Coverage Testing − This methodology validates every executable line in the program source code at least
once.
Decision Coverage Testing − This methodology tests all decision outcomes in the program.
Condition Coverage Testing − This methodology primarily verifies all the conditions in the program source code.
 Multiple Condition Testing − This methodology is used to verify different circumstances to get a very
 good test coverage. It relies on multiple test scripts, hence requires more time for completion.
 Path Testing - This methodology uses the control flow graph to calculate a group of linearly independent paths.
 Moreover, the cyclomatic complexity of the code is calculated to obtain the number of the linearly independent paths,
 and finally the test cases are built from those paths.

Experience Based Techniques

It consists of the procedures listed below −

 Error Guessing − This methodology is an informal testing where the testers use their knowledge, experience,
 expertise, and domain understanding to identify potential defects in the software. Those defects may not have been
 found by the formal test cases or by simply analyzing the requirements.
 Exploratory Testing − This methodology is an informal testing technique practiced on the software to determine bugs.
 It is an unsystematic approach.

Traceability Matrix

Traceability matrix is a table type document that is used in the development of software
Course Code/Title:CS2602/Software Testing Unit:III

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.

This document is designed to make sure that each requirement has a test case, and the test case is written
based on business needs, which are given by the client. It will be performed with the help of the test cases if
any requirement is missing, which means that the test case is not written for a
particular need, and that specific requirement is not tested because it may have some bugs. The traceability
Course Code/Title:CS2602/Software Testing Unit:III

is written to make sure that the entire requirement is covered.

We can observe in the below image that the requirement number 2 and 4 test case names are not mentioned
that's why we highlighted them, so that we can easily understand that we have to write the test case for
them.

Generally, this is like a worksheet document, which contains a table, but there are also many user- defined
templates for the traceability matrix. Each requirement in the traceability matrix is connected with its
respective test case so that tests can be carried out sequentially according to specific requirements.
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
Course Code/Title:CS2602/Software Testing Unit:III

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:
Course Code/Title:CS2602/Software Testing Unit:III

1. Forward traceability

2. Backward or reverse traceability

3. 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.

Backward or reverse traceability

The reverse or backward traceability is used to check that 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 into the backward direction to the test cases.
Course Code/Title:CS2602/Software Testing Unit:III

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.

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 Data Generation

Test Data Generation is the process of collecting and managing a large volume of data from various resources to
implement test cases and ensure the functional soundness of the system under test. These generated datasets act as input
for the test cases, allowing the behavior of the system to be verified. Test datasets are designed for both positive testing
and negative testing.

Generating rational and relevant datasets can be a complex task because poorly framed datasets might leave
significant test cases unchecked. The commonly used techniques for generating datasets are outlined below:

1) Manual Test Data Generation

In this technique, all datasets are manually created by the tester based on experience and the specific requirements of
the test cases.
 Course Code/Title:CS2602/Software Testing Unit:III

Pros:

 Easy to implement; no additional tools are required.

 Increases tester confidence by ensuring control over the process.

Cons:

1. Accuracy of the datasets is often questionable.

2. It is a time-consuming process.

2) Automated Test Data Generation

This technique leverages automated tools to quickly generate datasets by analyzing large volumes of data in a short
time.

Pros:

 Highly accurate datasets.

 Fast data generation.

Cons:

 Expensive to implement due to tool costs.

 Tools may take time to understand the system.

3) Backend Data Injection Approach

This method uses SQL queries to inject relevant data directly into the database. Testers write queries to populate the requir ed
datasets, which can generate large amounts of data efficiently.

Pros:

 Time-efficient technique.
 Requires less expertise compared to automated tools; writing correct queries is the primary skill needed.

Cons:

 Incorrect or invalid queries may generate illogical datasets or cause database failures.
 Requires careful attention to detail when injecting queries.

4) Third-Party Tools

Third-party tools available in the market can generate datasets tailored to business needs. These tools analyze the system and
produce datasets based on the requirements.

Pros:
Course Code/Title:CS2602/Software Testing Unit:III

 Highly accurate as the tools first analyze the system and then generate datasets accordingly.
 Customizable to suit specific business needs.

Cons:

 Expensive compared to other techniques.

 Limited coverage in heterogeneous testing environments as the tools are not always generic in nature.

Sample test cases for e-commerce application:

1. Login Module

Test Expected
User Action Input Actual Output Remark
case Output
Id
Redirect to same Redirect to same
Invalid Login Wrong User
1 page with error page with error Pass
Credential Id/Password
message message
Clicked Login Redirect to same page Redirect to same page
2 with Blank Form None with error message with error message Pass

Redirect to Main Redirect to Main

Valid Login Valid User Id
3 Home page of Home page of Pass
Credential Password
system system

2. Registration Module

Test
case User Action Input Expected Actual Remark
Id Output Output

Click ‘Register’
Click Redirect to same Redirect to
button with out
1 entering journey REGISTE R page with error same page Pass
Information Button message with error
message

Clicked Register Click Redirect to same Redirect to

2 with unscheduled REGISTE R page with error same page Pass
Train information Button message with error
message
Clicked Register with Click Redirect to Redirect to
Valid journey Details REGISTE R Payment Payment
3 Pass
Button with valid Gateway page Gateway page
details of system of system

[Link] Gate Way Module

Course Code/Title:CS2602/Software Testing Unit:III

Should display
Clicked Pay Now Should display
Clicked PAY the error
1 without filling all the error message Pass
NOW button message ‘Fill all
required fields ‘Fill all Fields’
Fields’
Clicked Pay Now Payment Receipt Payment
Clicked PAY
2 with filling all Should be Receipt Should Pass
NOW button
required fields Generate be Generate
Course Code/Title:CS2602/Software Testing Unit:III

16
 Course Code/Title:CS2602/Software Testing Unit:IV

Unit IV: AUTOMATED TESTING

Introduction to Automated Testing- Benefits, challenges, and types of automated testing, Test
Automation Tools- Selenium, JUnit etc.
Introduction to Automated Testing
AUTOMATED SOFTWARE TESTING
Automated software testing is the method of automatically reviewing and validating software products, such as
web and mobile applications. This process ensures that they meet all predefined quality standards for code style,
functionality, and user experience. Test automation replaces manual human activity with systems. Even though tests, like
regression or functional testing, can be done manually, automating the process will reduce the time taken to perform the
tests. Moreover, it takes less time to perform exploratory tests and more time to maintain test scripts, thus, increasing the
overall test coverage.

Difference Between Manual Testing vs Automated Testing

Below are some of the differences between manual testing and automated testing:

Parameters Manual Testing Automated Testing

Reliability Manual testing is not accurate at all Since it is performed by third-

times due to human error, thus it is party tools and/or scripts,

less reliable. therefore it is more reliable.

Investment Heavy investment in human Investment in tools rather than

resources. human resources.

Time Manual testing is time-consuming Automation testing is time-

efficiency due to human intervention where test saving as due to the use of the
cases are generated manually.
tools the execution is faster in
comparison to manual testing.

Programming There is no need to have It is important to have

knowledge
programming knowledge to write the programming knowledge to
test cases. write test cases.

Regression There is a possibility that the test When there are changes in the
testing cases executed the first time will not code, regression testing is done
be able to catch the regression bugs to catch the bugs due to changes
in the code.
due to the frequently changing
requirements.

Purpose of Automation Testing:

Automation testing serves several important purposes in the software development lifecycle. Let's explore some key
reasons why organizations embrace automation testing:

1. Increased Test Coverage: Automation testing enables a broader scope of test coverage. Organizations can leverage a
test automation platform and use it to design test scripts to cover various scenarios and test cases, ensuring thorough
validation of software functionality. With automated tests, organizations can achieve higher levels of test coverage,
resulting in improved software reliability.
2. Consistency and Reusability: Automation testing ensures consistent test execution by removing the element of
human error. Using test automation platform to automate testing, you can reuse test scripts across multiple test cycles and
different software versions. This reusability not only saves time but also promotes consistency in testing, enabling
accurate comparison of results over time.
Early Detection of Defects: Automation testing enables early detection issues. By running automated tests at different
stages, such as during integration or regression testing, potential bugs can be identified and addressed promptly. Early
defect detection helps in reducing the costs.

Kinds of Tests should be Automated:

While testing an application/software, testers cannot automate all processes involved in the testing cycle. Some tests
need human supervision and involvement to get better results. Using test automation platforms to automate testing is
not an alternative to manual testing but helps and supports the entire testing team by reducing the workload.

In order to determine whether a test is suitable for automation, testers can check if it fits the following criteria:

1
 Course Code/Title:CS2602/Software Testing Unit:IV

• The tests should be highly repetitive and take a long period of time to perform if it is done manually
• The testing path must be predictable, as it has been verified earlier through manual testing
• The tests that involve the testing of frequently used features that introduce high-risk conditions
• The tests that require multiple datasets and run on several different hardware or software platforms and
configurations
• Tests that are not possible for human manual testing, e.g., thousands of concurrent users trying to log in at the same
time
If a test meets all these criteria mentioned above, you can consider leveraging test automation platforms for automation.

Various Types of Automated Software Testing:

1. Unit Testing:
The testing of each unit of the software application is known as unit testing. As it is the first level of testing, you can
use test automation platforms to automate it. This type of testing is used to validate unit components with their
performance. Primarily, unit testing is performed during the development phase.

2. Smoke Testing:
Smoke testing is usually done on a build software received from the development team. The focus of the smoke tests is
to check whether the build software is stable or not. If the software passes this test, then testers can proceed with
further testing.

3. Integration Testing:
Integration testing is the testing process that is performed after unit testing. This test ensures that units or individual
components of the software are tested in a group and work well as a whole. This test is used to detect defects at the
time of interaction between integrated components or units.

4. Regression Testing
Regression testing is both functional and non-functional type of testing. It verifies the code changes that do not impact
the software's existing functionality. This testing ensures that the software works fine with new functionality, bug fixes,
or code changes in the existing feature. With HeadSpin’s test automation platform, testing teams can perform
regression automation testing for their apps/websites. HeadSpin's Regression Intelligence is a powerful comparison
tool for analyzing degradation across new app builds, OS releases, feature additions, locations, and more. Using the test
automation platform, testers can also compare build over build, location over location, network over network, and
device over device performance of their apps/websites.

5. API Testing
The application programming interface (API) is the connection between all the other systems that software needs to
function. This testing verifies all APIs. API testing is mainly used to test the programming interfaces ' functionality,
reliability, performance, and [Link] executing API testing with the HeadSpin Platform, the API usage
monitoring feature will help testers keep track of how their APIs are being used by applications or track the impact of
3rd party APIs on application performance.

6. Security Testing
Security testing is also functional and non-functional in nature. It detects the weaknesses and threats in the software. This
testing can block the attacks from hackers and ensure the security of the software.

7. Performance Testing
Performance testing records the system performance of the software in terms of responsiveness and stability under a
specific workload. The main parameters checked under this testing include the software's speed, robustness, an d
reliability.

8. Acceptance Testing
Acceptance testing is used to check how end users will respond to the final software product. Usually, this is the last type
of testing used before a software/application is released.

9. UI Testing
UI testing checks and verifies visual elements of apps/web pages to validate proper functionality and expected
performance. This testing is done after the complete development of the application/software.

With global device infrastructure and quality of experience (QoE) insights, HeadSpin enables organizations to deliver
flawless UI experiences. Organizations can use the HeadSpin Platform to perform UI testing on real devices and record test
sessions. This feature will give them real- time insights into the performance of their applications.

Automated Software Testing Tools

In software development, ensuring the quality and reliability of software through testing is a crucial step. Automated
testing tools have become indispensable in achieving this goal efficiently. These tools speed up the testing process and
enhance its accuracy. Below, we introduce a selection of prominent automated software testing tools, each with its
unique features and capabilities:

2
 Course Code/Title:CS2602/Software Testing Unit:IV

Selenium - A staple in the automated testing tool arsenal, Selenium supports multiple languages and browsers, focusing
on web application testing. It allows for creating complex test scripts that can mimic a wide range of user actions.

TestComplete - Offering a comprehensive testing solution, TestComplete supports desktop, mobile, and web
applications. It's known for its robust record and playback feature, making it accessible to testers without extensive
scripting knowledge.

JUnit - A fixture in the Java ecosystem, JUnit facilitates unit testing with simplicity and ease of use. Its annotations and
assertions make it a go-to for developers looking to implement test- driven development (TDD).

Cypress - A modern web testing tool designed to work exclusively with web applications. Cypress offers a unique
testing experience by running tests in the same run-loop as the application, leading to faster and more reliable tests.

Appium - Focused on mobile application testing, Appium supports automation on iOS and Android platforms. It works
well for applications written in any framework, making it a versatile choice for mobile testing.

Robot Framework - An open-source, keyword-driven test automation framework, Robot Framework is designed for
acceptance testing and acceptance test-driven development (ATDD). It's easy to use for those new to automated testing
while still powerful enough for complex test scenarios.

Postman - While primarily known as an API development tool, Postman also offers automated testing capabilities for
RESTful APIs. Its user-friendly interface allows for easy creation, management, and execution of API tests.

Automation Testing Process

Test Tool Selection: There will be some criteria for the Selection of the tool. The majority of the criteria include: Do
we have skilled resources to allocate for automation tasks, Budget constraints, and Do the tool satisfies our needs?

Define Scope of Automation: This includes a few basic points such as the Framework should support Automation Scripts,
Less Maintenance must be there, High Return on Investment, Not many complex Test Cases.

Planning, Design, and Development: For this, we need to Install particular frameworks or libraries, and start designing
and developing the test cases such as NUnit, JUnit, QUnit,or required Software Automation Tools

Test Execution: Final Execution of test cases will take place in this phase and it depends on Language to Language for
.NET, we’ll be using NUnit, for Java, we’ll be using JUnit, for JavaScript, we’ll be using QUnit or Jasmine, etc.

Maintenance: Creation of Reports generated after Tests and that should be documented to refer to that in the future for
the next iterations.

Benefits of automated software testing:

Increased speed: Automated tests can be run much faster than manual tests, which can save a lot of time.

Reduced cost: Automated tests can help to reduce the cost of software testing by freeing up manual testers
to focus on other tasks.

Improved quality: Automated tests can help to improve the quality of software by catching bugs that
would otherwise be missed.

Increased confidence: Automated tests can help to increase confidence in the quality of software by
providing evidence that the software has been thoroughly tested.

Challenges of automated software testing:

Initial investment: Automated testing can require a significant initial investment in time and resources.

Maintenance: Automated: tests need to be maintained and updated as the software changes.

Complexity: Automated testing can be a complex process and it can be difficult to get right.

Different Types of Automated Testing:

1. Code-Based Testing:

Definition:
Involves writing code (often in a scripting language like Python or Java) to automate test execution. This approach offers
flexibility and control over testing scenarios.

3
 Course Code/Title:CS2602/Software Testing Unit:IV

Popular Tools:

Selenium: A widely used open-source tool for web application testing, offering support for multiple browsers and languages.
Appium: Primarily focused on testing native and mobile applications on Android and iOS.
Cypress: An end-to-end testing framework for web applications with a focus on speed and ease of use.
Playwright: A cross-browser testing framework designed to automate web applications and mobile apps.

Advantages:
Flexibility: Allows for highly customized and complex test scenarios.
Automation: Automates repetitive tasks, such as UI interactions, reducing the need for manual testing.
Integration: Can be easily integrated with other tools and frameworks, enabling seamless testing workflows.
Reusability: Test scripts can be reused across different parts of the application, improving test efficiency.

2. GUI-Based Testing:
Definition: Uses a visual interface to automate tests, reducing the need for extensive coding. These tools often rely on record-
and-playback features or visual scripting.

Popular Tools:
TestComplete: A comprehensive tool that supports testing web, desktop, and mobile applications with a user -friendly GUI.
Ranorex: A commercial tool focused on automating GUI testing for various platforms, including web, desktop, and mobile
applications.
AutoIt: A free and open-source tool specifically designed for automating Windows GUI applications.
Squish: A cross-platform tool designed for testing GUIs on various platforms and devices, including web applications, mobile,
and desktop applications.

Advantages:
Simplicity: Requires less coding knowledge, making them accessible to non-programmers.
Ease of Use: Visual scripting and record-and-playback features simplify test creation.
Rapid Prototyping: Enables quick creation of automated tests for various scenarios.
Cost-Effectiveness: Can reduce development time and cost of automated testing by reducing the need for expert
programmers.

3. Framework Approach:

In the test automation process, testing frameworks play a crucial role. These frameworks include guidelines for
testers/developers in coding standards, repository management, and handling of test data. The main focus of these
frameworks is to reduce maintenance costs and testing efforts and achieve a high return on investment for the testing
teams.

Let's look at the different types of automated software testing frameworks that many organizations use to achieve a
good testing environment.

1. Linear Automation Framework

The linear test automation framework guides testers to create functions without writing codes, and the steps in this
framework are given in sequential order. While testing with this framework, testers record every step and play the
script back automatically to repeat the test.

2. Modular-based Testing Framework

In the modular-based testing framework, testers need to divide the application/software under test into separate units or
sections. These separate units or sections are tested in isolation. Individual test scripts are created for each part, and
after testing, all parts are combined to build larger tests that represent various test cases. The most important step in this
framework is creating an abstraction layer, which avoids changes in individual sections affecting the overarching
module.

3. Data-driven Framework
In the data-driven framework, the test data are separated from script logic, and testers can store all the data externally.
With this framework, whenever testers need to test application/software multiple times with different data sets, they can
use the data stored in external data sources. The main external data sources used in this framework are Excel
Spreadsheets, Text Files, CSV files, SQL Tables, or ODBC repositories.

4. Keyword-driven Framework
While using the keyword-driven framework for automated testing, all functions of the application/software
undergoing the test are written out in the table with specific instructions in the order of the test that needs to be
performed. In this framework also, test data are separated from script logic. Keywords are also stored in the external

4
 Course Code/Title:CS2602/Software Testing Unit:IV

data table. These keywords represent the various actions that are being performed to test the GUI of an application.
This framework requires a shared object repository to navigate the objects to their associated actions.

5. Hybrid Testing Framework

The hybrid framework is a combination of the already mentioned frameworks. This type of framework is used to
leverage some frameworks' advantages and mitigate others' weaknesses.

Test Automation Tools: Selenium, JUnit

Selenium:

Advantages:

 It is the most versatile automated software testing tool.

 This tool is open-source and widely supports all languages and frameworks.
 It comes with heavy library packages.
 It supports cross-browser automation, API automation, and database automation.
 Testers can use it for regression, exploratory testing, and quick reproduction of bugs.
 It can be beneficial in parallel test execution techniques.
 It is highly known for its flexibility with ease of implementation.
 Its integration with gauge automation framework, Galen framework, lambda test, etc., is trending nowadays.

Disadvantages:

 Test Maintenance in selenium can become cumbersome and even expensive sometimes.
 Selenium requires coding skills, if not exceptional but above average, though.
 It is only supported for web applications, though.
 Technical support and its reliability can cause problems, though.
 Flaky tests can be a big problem as they generate false negatives and false positives or vice versa.

SELENIUM: INTRODUCING WEB DRIVER AND WEB ELEMENTS

Selenium Testing Tools
Selenium 3.0 offers three important tools, Selenium WebDriver, Selenium Server, and Selenium IDE. Each of these
tools provides features to create, debug, and run tests on supported browsers and operating systems. Let's explore each
of them in detail.

1. Selenium WebDriver
Selenium WebDriver is the successor of Selenium RC (Remote Control), which has been officially deprecated.
Selenium WebDriver accepts commands using the JSON-Wire protocol (also called Client API) and sends them to a
browser launched by the specific driver class (such as ChromeDriver, FirefoxDriver, or IEDriver). This is implemented
through a browser- specific browser driver. It works with the following sequence:

1. It converts these commands into the browser's native API

2. The driver takes the result of native commands and sends the result back to Selenium.

5
Course Code/Title:CS2602/Software Testing Unit:IV

We can use Selenium WebDriver to do the following:

 Create robust, browser-based regression automation

 Scale and distribute scripts across many browsers and platforms
 Create scripts in your favourite programming language.
2. Selenium Server
Selenium Server allows us to run tests on browser instances running on remote machines and in parallel, thus
spreading a load of testing across several machines. We can create a Selenium Grid, where one server runs as the Hub,
managing a pool of Nodes. We can configure our tests to connect to the Hub, which then obtains a node that is free and
matches the browser we need to run the tests. The hub has a list of nodes that provide access to browser instances, and lets
tests use these instances similarly to a load balancer.

Selenium Grid enables us to execute tests in parallel on multiple machines by managing different types of browsers,
their versions, and operating system configurations centrally.

3. Selenium IDE
Selenium IDE is a Firefox add-on that allows users to record, edit, debug, and play back tests captured in the Selenese
format, which was introduced in the Selenium Core version. It also provides us with the ability to convert these tests into
the Selenium RC or Selenium WebDriver format. We can use Selenium IDE to do the following:

 Create quick and simple scripts using record and replay, or use them in exploratory testing
 Create scripts to aid in automation-aided exploratory testing
 Create macros to perform repetitive tasks on Web pages

Web Elements
A web page is composed of many different types of HTML elements, such as links, textboxes, dropdown buttons, a body,
labels, and forms. These are called WebElements in the context of WebDriver. Together, these elements on a web page
will achieve the user functionality. For example, let's look at the HTML code of the login page of a website:

<html>

<body>

<form id="loginForm">

<label>Enter Username: </label>

<input type="text" name="Username"/>

<label>Enter Password: </label>

<input type="password" name="Password"/>

<input type="submit"/>

</form>

<a href="[Link]">Forgot Password ?</a>

</body>

</html>

6
Course Code/Title:CS2602/Software Testing Unit:IV

In the preceding HTML code, there are different types of WebElements, such as <html>,

<body>, <form>, <label>, <input>, and <a>, which together make a web page provide the Login feature for the user.
Let's analyze the following WebElement:

<label>Enter Username: </label>

Here, <label> is the start tag of the WebElement label. Enter Username: is the text present on the label element.
Finally, </label> is the end tag, which indicates the end of a WebElement. Similarly, take another WebElement:

<input type="text" name="Username"/>

In the preceding code, type and name are the attributes of the WebElement input with the text and Username values,
respectively.

UI-automation using Selenium is mostly about locating these WebElements on a web page and executing user
actions on them.

LOCATING WEB ELEMENTS

Let's start by automating the Search feature from the Homepage of the demo application, [Link] which
involves navigating to the homepage, typing the search text in the textbox, and executing the search. The code is as
follows:

import [Link];

import [Link];

import [Link];

public class SelTest {

public static void main(String[] args) throws InterruptedException {

[Link]("[Link]","C:\\selenium webdriver\\chromedriver-
win64\\[Link]");

WebDriver driver=(WebDriver) new ChromeDriver();

[Link]("[Link] [Link]().window().maximize();
[Link](4000);

[Link]([Link]("twotabsearchtextbox")).sendKeys("apple iphone"); [Link](4000);

WebElement subbtn = [Link]([Link]("nav-search-submit- button"));

[Link]();

//[Link]([Link]("nav-search-submit-button")).click();

//[Link]([Link]("nav-input")).click();
[Link]([Link]("Get It Today")).click(); [Link](4000);
[Link]().to("[Link] [Link](4000);

[Link]().back();

//[Link]([Link]());

//[Link]([Link]());

[Link](4000); [Link]();

As you can see, there are three new things that are highlighted, as follows:

WebElement subbtn = [Link]([Link]("nav-search-submit-button")); They are the findElement()

method, the [Link]() method, and the WebElement interface. The findElement() and By() methods instruct WebDriver to
locate a WebElement on a web page, and once found, the findElement() method returns the WebElement instance of that

7
Course Code/Title:CS2602/Software Testing Unit:IV

element. Actions, such as click and type, are performed on a returned WebElement using the methods declared in the
WebElement interface.

The findElement method

In UI automation, locating an element is the first step before executing any user actions on it. WebDriver's
findElement() method is a convenient way to locate an element on the web page. According to WebDriver's Javadoc, the
method declaration is as follows:

WebElement findElement(By by)

So, the input parameter for the findElement() method is the By instance. The By instance is a WebElement-locating
mechanism.

The return type of the findElement() method is the WebElement instance that represents the actual HTML
element or component of the web page. The method returns the first WebElement that the driver comes across that
satisfies the locating-mechanism condition. This WebElement instance will act as a handle to that component from then
on.

Appropriate actions can be taken on that component by the test-script developer using this returned WebElement
instance. If WebDriver doesn't find the element, it throws a runtime exception named NoSuchElementException, which
the invoking class or method should handle.

The findElements method

For finding multiple elements matching the same locator criteria on a web page, the findElements() method can be used.
It returns a list of WebElements found for a given locating mechanism. The method declaration of the findElements()
method is as follows:

[Link] findElements(By by)

The input parameter is the same as the findElement() method, which is an instance of the By class. The difference lies in
the return type. Here, if no element is found, an empty list is returned and if there are multiple WebElements present that
satisfy the locating mechanism, all of them are returned to the caller in a list.

Using the By locating mechanism

By is the locating mechanism passed to the findElement() method or the findElements() method to fetch the
respective WebElement(s) on a web page. There are eight different locating mechanisms; that is, eight different ways
to identify an HTML element on a web page. They are located by ID, Name, ClassName, TagName, LinkText,
PartialLinkText,

XPath, and CSS Selector.

1. The [Link]() method

consider the HTML code of the Search box:

<input id="search" type="search" name="q" value="" class="input-textrequired- entry" maxlength="128"

placeholder="Search entire store here..." autocomplete="off">

In the preceding code, the id attribute value of the search box is search. WebElement searchBox =
[Link]([Link]("search"));

In preceding code, we used the [Link]() method and the search box's id attribute value to find the element.

2. The [Link]() method:

WebElement searchBox = [Link]([Link]("q"));

3. The [Link]() method:

For instance, a style attribute for a button can be declared in a CSS file as follows:

.buttonStyle{ width: 50px; height: 50px;

border-radius: 50%;

margin: 0% 2%;

Now, this style can be applied to the button element in a web page as follows:

8
 Course Code/Title:CS2602/Software Testing Unit:IV

<button name="sampleBtnName" id="sampleBtnId" class="buttonStyle">I'm Button</button>

WebElement searchButton = [Link]([Link]("buttonStyle "));

4. The [Link]() method:

A typical anchor tag looks like this:

<a href="[Link] title="My Account">My Account</a>

[Link]([Link]("My Account"));

5. The [Link]() method:

WebElement orderAndReturns = [Link]([Link]("My"));

6. The [Link]() method

List<WebElement> links = [Link]([Link]("a"));

7. The [Link]() method

WebDriver uses XPath to identify a WebElement on the web page. Before we see how it does that, let's quickly look at
the syntax for XPath. XPath is a short name for the XML path, the query language used for searching XML
documents. The HTML for our web page is also one form of the XML document. So, in order to identify an element
on an HTML page, we need to use a specific XPath syntax:

 The root element is identified as //.

 To identify all the div elements, the syntax will be //div.
 To identify the link tags that are within the div element, the syntax will be //div/a.
 To identify all the elements with a tag, we use *. The syntax will be //div/*.
 To identify all the div elements that are at three levels down from the root, we can use
//*/*/div.

 To identify specific elements, we use attribute values of those elements, such as

//*/div/a[@id='attrValue'], which will return the anchor element. This element is at the third level from the root
within a div element and has an id value of attrValue.

So, we need to pass the XPath expression to the [Link] locating mechanism to make it identify our target element.

Now, let's see the code example and how WebDriver uses this XPath to identify the element: WebElement searchBox =
[Link]([Link]("//*[@id='search']")); [Link]("Bags");

[Link]();

8. The [Link]() method

The [Link]() method is similar to the [Link]() method in its usage, but the difference is that it is slightly faster
than the [Link] locating mechanism. The following are the commonly used syntaxes to identify elements:

 To identify an element using the div element with the #flrs ID, we use the #flrs syntax
 To identify the child anchor element, we use the #flrs > a syntax, which will return the link element
 To identify the anchor element with its attribute, we use the #flrs >
a[a[href="/intl/en/[Link]"]] syntax
Let's try to modify the previous code, which uses the XPath locating mechanism to use the cssSelector mechanism:

WebElement searchBox = [Link]([Link]("#search"));

ACTIONS ON WEB ELEMENTS

Different WebElements will have different actions that can be taken on them. For example, in a textbox element,
we can type in some text or clear the text that is already typed in it. Similarly, for a button, we can click on it, get the
dimensions of it, and so on, but we cannot type into a button, and for a link, we cannot type into it.

So, though all the actions are listed in one WebElement interface, it is the test script developer's responsibility to
use the actions that are supported by the target element. In case we try to execute the wrong action on a WebElement, we
don't see any exception or error thrown and we don't see any action get executed; WebDriver ignores such actions
silently.

Getting element properties and attributes

There are various methods to retrieve value and properties from the WebElement interface.

1. The getAttribute() method

9
Course Code/Title:CS2602/Software Testing Unit:IV

The getAttribute method can be executed on all the WebElements. The HTML attributes are modifiers of HTML
elements. They are generally key-value pairs that appear in the start tag of an element. For example:

<label name="Username" id="uname">Enter Username: </label>

In the preceding code, name and id are the attributes or attribute keys and Username and uname are the attribute values.

The API syntax of the getAttribute() method is as follows:

[Link] getAttribute([Link] name)

In the preceding code, the input parameter is String, which is the name of the attribute. The return type is again Str ing,
which is the value of the attribute.

Now let's see how we can get all the attributes of a WebElement using WebDriver. Here, we will make use of the
Search box from the example application. This is what the element looks like:

<input id="search" type="search" name="q" value="" class="input-text required-entry"

maxlength="128" placeholder="Search entire store here..." autocomplete="off">

We will list all the attributes of this WebElement using WebDriver. The code for that is as follows:

WebElement searchBox = [Link]([Link]("q")); [Link]("Name of the box is: " +

[Link]("name")); [Link]("Id of the box is: " +[Link]("id"));
[Link]("Class of the box is: " + [Link]("class"));

[Link]("Placeholder of the box is: " + [Link]("placeholder"));

In the preceding code, the last four lines of code use the getAttribute() method to fetch the attribute values of the name,
id, class, and placeholder attributes of the WebElement search box. The output of the preceding code will be following:

Name of the box is: q Id of the box is: search

Class of the box is: input-text required-entry Placeholder of the box is: Search
entire store here...

Going back to the [Link]() method of the previous section, if the search by a locating mechanism,
[Link], results in more than one result, you can use the getAttribute() method to further filter the results and get
to your exact intended element.

2. The getText() method:

The getText method can be called from all the WebElements. It will return visible text if the element contains any text
on it, otherwise it will return nothing. The API syntax for the getText() method is as follows:

[Link] getText()

There is no input parameter for the preceding method, but it returns the visible innerText string of the
WebElement if anything is available, otherwise it will return an empty string. The following is the code to get the text
present on the Site notice element present on the example application Homepage:

WebElement siteNotice = [Link](By .className("global-site-notice"));

[Link]("Complete text is: " + [Link]());

The preceding code uses the getText() method to fetch the text present on the Site notice element, which
returns the following:

Complete text is: This is a demo store. Any orders placed through this store will not be honored or fulfilled.

3. The getCssValue() method

The getCssValue method can be called on all the WebElements. This method is used to fetch a CSS property value
from a WebElement. CSS properties can be fontfamily, background- color, color, and so on. This is useful when you
want to validate the CSS styles that are applied to your WebElements through your test scripts.

[Link]("Font of the box is: " + [Link]("font-family")); The preceding code uses the
getCssValue() method to find font-family of the text visible in the Search box. The output of the method is shown
here:

Font of the box is: Raleway, "Helvetica Neue", Verdana, Arial, sans-serif

4. The getLocation() method

The getLocation method can be executed on all the WebElements. This is used to get the relative position of an
element where it is rendered on the web page. This position is calculated relative to the top-left corner of the web page

10
Course Code/Title:CS2602/Software Testing Unit:IV

of which the (x, y) coordinates are assumed to be (0, 0). This method will be of use if your test script tries to validate
the layout of your web page.

[Link]("Location of the box is: " + [Link]());

The output for the preceding code is the (x, y) location of the Search box, as shown in the following screenshot:

Location of the box is: (873, 136)

5. The getSize() method

The getSize method can also be called on all the visible components of HTML. It will return the width and height of
the rendered WebElement.

The code for that is as follows:

[Link]("Size of the box is: " + [Link]());

The output for the preceding code is the width and height of the Search box, as shown in the following screenshot:

Size of the box is: (281, 40)

6. The getTagName() method

The getTagName method can be called from all the WebElements. This will return the HTML tag name of the
WebElement. For example, in the following HTML code, the button is the tag name of the HTML element:

<button id="gbqfba" class="gbqfba" name="btnK" aria-label="Google Search"> In the preceding code, the
button is the tag name of the HTML element.

The code for that is as follows:

WebElement searchButton = [Link]([Link]("searchbutton")); [Link]("Html tag of

the button is: " + [Link]());

The preceding code uses the getTagName() method to get the tag name of the Search button element. The output of the
code is as expected:

Html tag of the button is: button

Performing actions on WebElements

Let's explore the various methods available in the WebElement interface.

1. The sendKeys() method

The sendKeys action is applicable for textbox or textarea HTML elements. This is used to type text into the textbox. This
will simulate the user keyboard and types text into WebElements exactly as a user would. The API syntax for the
sendKeys() method is as follows:

void sendKeys([Link]...keysToSend)

The input parameter for the preceding method is CharSequence of text that has to be entered into the element. This
method doesn't return anything. Now, let's see a code example of how to type a search text into the Search box using the
sendKeys() method:

WebElement searchBox = [Link]([Link]("q")); [Link]("Phones");

[Link]();

In the preceding code, the sendKeys() method is used to type the required text in the textbox element of the web page.
This is how we deal with normal keys, but if you want to type in some special keys, such as Backspace, Enter, Tab, or
Shift, we need to use a special enum class of WebDriver, named Keys. Using the Keys enumeration, you can simulate
many special keys while typing into a WebElement.

Now let's see some code example, which uses the Shift key to type the text in uppercase in the Search Box:

[Link]([Link]([Link],"phones"));

In the preceding code, the chord() method from the Keys enum is used to type the key, while the text specified is being
given as an input to be the textbox.

2. The clear() method

The clear action is similar to the sendKeys() method, which is applicable for the textbox and textarea elements. This is
used to erase the text entered in a WebElement using the sendKeys() method. This can be achieved using the
Keys.BACK_SPACE enum, but WebDriver has given us an explicit method to clear the text easily.

11
Course Code/Title:CS2602/Software Testing Unit:IV

The code for that is as follows:

WebElement searchBox = [Link]([Link]("q"));

[Link]([Link]([Link],"phones")); [Link]();

We have used the WebElement's clear() method to clear the text after typing phones into the Search box.

3. The submit() method

The submit() action can be taken on a Form or on an element, which is inside a Form element. This is used to submit a
form of a web page to the server hosting the web application.

[Link]();

Checking the WebElement state

There are methods to check whether the WebElement is displayed in the Browser window, whether it is editable, and if
the WebElement is Radio Button of Checkbox, we can determine whether it's selected or unselected. Let's see how we
can use the methods available in the WebElement interface.

1. The isDisplayed() method

The isDisplayed action verifies whether an element is displayed on the web page and can be executed on all the
WebElements. The API syntax for the isDisplayed() method is as follows: boolean isDisplayed()

The preceding method returns a Boolean value specifying whether the target element is displayed on the web
page. The following is the code to verify whether the Search box is

displayed, which obviously should return true in this case:

WebElement searchBox = [Link]([Link]("q")); [Link]("Search box is displayed: " +

[Link]());

The preceding code uses the isDisplayed() method to determine whether the element is displayed on a web page. The
preceding code returns true for the Search box:

Search box is displayed: true

2. The isEnabled() method

The isEnabled action verifies whether an element is enabled on the web page and can be executed on all the
WebElements. The API syntax for the isEnabled() method is as follows:

boolean isEnabled()

[Link]("Search box is enabled: " + [Link]());

3. The isSelected() method

The isSelected method returns a boolean value if an element is selected on the web page and can be executed only on a
radio button, options in select, and checkbox WebElements. When executed on other elements, it will return false.

[Link]("Search box is selected: " + [Link]());

DIFFERENT WEB DRIVERS

Let us explore the WebDriver implementation for Mozilla Firefox, Google Chrome, Microsoft Internet Explorer,
Microsoft Edge, and Safari. With WebDriver becoming a W3C specification, all of the major browser vendors now
support WebDriver natively.

1. Firefox Driver
The new driver for Firefox is called Geckodriver. The Geckodriver provides the HTTP API described by the
W3C WebDriver Protocol to communicate with Gecko browsers, such as Firefox. It translates calls into the Firefox
Remote Protocol (Marionette) by acting as a proxy between the local and remote ends.

Using GeckoDriver:

First of all, we need to download the Geckodriver executable from [Link]

mozilla/geckodriver/releases. Download the appropriate version of Geckodriver based on the Firefox version installed
on your computer as well as the operating system. Copy the executable file into the /src/test/resources/drivers folder.

Provide the path of the Geckodriver binary in the [Link] property, and instantiate the
FirefoxDriver class:

WebDriver driver; [Link]("[Link]","./src/test/resources/drivers/geckodriver

.exe");

driver = new FirefoxDriver();

12
Course Code/Title:CS2602/Software Testing Unit:IV

[Link]("[Link]

Using Headless Mode

Headless mode is a very useful way to run Firefox for automated testing with Selenium WebDriver. In headless mode,
Firefox runs as normal only you don't see the UI components. This makes Firefox faster and tests run more efficiently,
especially in the CI (Continuous Integration) environment.

We can run Selenium tests in headless mode by configuring the FirefoxOptions class, as shown in the following code
snippet:

WebDriver driver;

[Link]("[Link]", "./src/test/resources/drivers/geckodriver 2"); FirefoxOptions

firefoxOptions = new FirefoxOptions(); [Link](true);

driver = new FirefoxDriver(firefoxOptions);

During the execution, you will not see the Firefox window on the screen but the test will be executed in headless mode.

2. Chrome Driver
The ChromeDriver works similar to the Geckodriver and implements the W3C WebDriver protocol. First of all,
we need to download the chrome driver executable from [Link] Download the
appropriate version of chromedriver based on the Chrome version installed on computer as well as the operating system.
Copy the executable file into the /src/test/resources/drivers folder.

Provide the path of the chromedriver binary in the [Link] property, and instantiate the
ChromeDriver class: [Link]("[Link]","C:\\seleniumwebdriver\\chromedrive r-in64
\\[Link]");

WebDriver driver=(WebDriver) new ChromeDriver(); [Link]("[Link]

Using Headless Mode

Similar to Firefox, we can run tests in headless mode with ChromeDriver. This makes Chrome tests run faster and tests run
more efficiently, especially in the CI (Continuous Integration) environment.

We can run Selenium tests in headless mode by configuring the ChromeOptions class as shown in the following code
snippet:

WebDriver driver; [Link]("[Link]","./src/test/resources/drivers/chromedriver");

ChromeOptions chromeOptions = new ChromeOptions(); [Link](true);

driver = new ChromeDriver(chromeOptions); [Link]("[Link]

[Link]/");

In the preceding code, we first created an instance of the ChromeOptions class, called the setHeadless() method, that
passes the value as true to launch the Chrome browser in headless mode. During the execution, you will not see the
Chrome window on the screen but the test will be executed in headless mode.

3. Internet Explorer Driver:

In order to execute your test scripts on the Internet Explorer browser, you need WebDriver's InternetExplorerDriver.
Similar to Google Chrome and Firefox, we need to download the IEDriver Server executable from
[Link] for Internet Explorer.

The IEDriver server then uses its IEThreadExplorer class, which is written in C++, to drive the IE browser using the
Component Object Model framework. The following is the code that instantiates InternetExplorerDriver:

WebDriver driver; [Link]("[Link]","./src/test/resources/drivers/IEDriverServer. exe");

driver = new InternetExplorerDriver(); [Link]("[Link]

[Link]/");

4. Edge Driver
Microsoft Edge is the latest web browser launched with Microsoft Windows 10. Microsoft Edge was one of the first
browsers to implement the W3C WebDriver standard and provides built-in support for Selenium WebDriver.

Similar to Internet Explorer, in order to execute test scripts on the Microsoft Edge browser, we need to use the
EdgeDriver class and a standalone Microsoft WebDriver Server executable. The Microsoft WebDriver Server is

13
 Course Code/Title:CS2602/Software Testing Unit:IV

maintained by the Microsoft Edge development team. You can find more information at
[Link] gb/microsoft-edge/webdrive.

We need to download and install Microsoft WebDriver Server on Windows 10

([Link]

WebDriver driver; [Link]("[Link]","./src/test/resources/drivers/MicrosoftWe

[Link]");

EdgeOptions options = new EdgeOptions();

[Link]("eager"); driver = new
EdgeDriver(options);

[Link]("[Link]

5. Safari Driver
With Selenium 3.0 and WebDriver becoming the W3C standard, Apple now provides SafariDriver built into the
browser. We do not have to download it separately. However, in order to work it with Selenium WebDriver, we have to
set a Develop | Allow Remote Automation option from Safari's main menu. This is as straight forward. The following
is the test script using the Safari Driver:

WebDriver driver;

driver = new SafariDriver();

[Link]("[Link]

JUNIT:

What is JUnit ?

JUnit is a unit testing framework for Java programming language. It plays a crucial role test-driven development,
and is a family of unit testing frameworks collectively known as xUnit.

JUnit promotes the idea of "first testing then coding", which emphasizes on setting up the test data for a piece of
code that can be tested first and then implemented. It increases the productivity of the programmer and the
stability of program code, which in turn reduces the stress on the programmer and the time spent on debugging.

Features of JUnit
 JUnit is an open source framework, which is used for writing and running tests.

 Provides annotations to identify test methods.

 Provides assertions for testing expected results.

 Provides test runners for running tests.

 JUnit tests allow you to write codes faster, which increases quality.

 JUnit is elegantly simple. It is less complex and takes less time.

 JUnit tests can be run automatically and they check their own results and provide immediate feedback. There's no need to
manually comb through a report of test results.

 JUnit tests can be organized into test suites containing test cases and even other test suites.

 JUnit shows test progress in a bar that is green if the test is running smoothly, and it turns red when a test fails.

JUNIT Environment Setup

JUnit is a framework for Java, so the very first requirement is to have JDK installed in your machine.

System Requirement

14
 Course Code/Title:CS2602/Software Testing Unit:IV

JDK 1.5 or above.

Memory No minimum requirement.

Disk Space No minimum requirement.

Operating System No minimum requirement.

Step 1: Verify Java Installation in Your Machine

First of all, open the console and execute a java command based on the operating system you are working on.

OS Task Command

Windows Open Command Console c:\> java -version

Linux Open Command Terminal $ java -version

Mac Open Terminal machine:~ joseph$ java -version

Let's verify the output for all the operating systems −

OS Output

java version "1.8.0_101"

Windows
Java(TM) SE Runtime Environment (build 1.8.0_101)

java version "1.8.0_101"

Linux
Java(TM) SE Runtime Environment (build 1.8.0_101)

java version "1.8.0_101"

Mac
Java(TM) SE Runtime Environment (build 1.8.0_101)

If you do not have Java installed on your system, then download the Java Software Development Kit (SDK) from the following
link [Link] We are assuming Java 1.8.0_101 as the installed version for this tutorial.

Explore our latest online courses and learn new skills at your own pace. Enroll and become a certified expert to boost your
career.

Step 2: Set JAVA Environment

Set the JAVA_HOME environment variable to point to the base directory location where Java is installed on your machine. For
example.

OS Output

Windows Set the environment variable JAVA_HOME to C:\Program Files\Java\jdk1.8.0_101

Linux export JAVA_HOME = /usr/local/java-current

Mac export JAVA_HOME = /Library/Java/Home

Append Java compiler location to the System Path.

OS Output

Append the string C:\Program Files\Java\jdk1.8.0_101\bin at the end of the system

Windows
variable, Path.

15
 Course Code/Title:CS2602/Software Testing Unit:IV

Linux export PATH = $PATH:$JAVA_HOME/bin/

Mac not required

Verify Java installation using the command java -version as explained above.

Step 3: Download JUnit Archive

Download the latest version of JUnit jar file from [Link] At the time of writing this tutorial, we have downloaded
[Link] and copied it into C:\>JUnit folder.

OS Archive name

Windows [Link]

Linux [Link]

Mac [Link]

Step 4: Set JUnit Environment

Set the JUNIT_HOME environment variable to point to the base directory location where JUNIT jar is stored on your machine.
Let’s assuming we've stored [Link] in the JUNIT folder.

[Link] OS & Description

Windows
1
Set the environment variable JUNIT_HOME to C:\JUNIT

2 Linux
export JUNIT_HOME = /usr/local/JUNIT

Mac
3
export JUNIT_HOME = /Library/JUNIT

Step 5: Set CLASSPATH Variable

Set the CLASSPATH environment variable to point to the JUNIT jar location.

[Link] OS & Description

Windows
1
Set the environment variable CLASSPATH to %CLASSPATH%;%JUNIT_HOME%\[Link];.;

Linux
2
export CLASSPATH = $CLASSPATH:$JUNIT_HOME/[Link]:.

3 Mac
export CLASSPATH = $CLASSPATH:$JUNIT_HOME/[Link]:.

Step 6: Test JUnit Setup

Create a java class file name TestJunit in C:\>JUNIT_WORKSPACE

import [Link];import static [Link];

public class TestJunit {
@Test

public void testAdd() {

String str = "Junit is working fine";
assertEquals("Junit is working fine",str);
}}

16
 Course Code/Title:CS2602/Software Testing Unit:IV

Create a java class file name TestRunner in C:\>JUNIT_WORKSPACE to execute test case(s).

import [Link];import [Link];import [Link];

public class TestRunner {
public static void main(String[] args) {
Result result = [Link]([Link]);

for (Failure failure : [Link]()) {

[Link]([Link]());
}

[Link]([Link]());
}}

Step 7: Verify the Result

Compile the classes using javac compiler as follows −

C:\JUNIT_WORKSPACE>javac [Link] [Link]

Now run the Test Runner to see the result as follows −

C:\JUNIT_WORKSPACE>java TestRunner

Verify the output.

True

Features of JUnit Test Framework

JUnit test framework provides the following important features −

1. Fixtures
2. Test suites
3. Test runners
4. JUnit classes
Fixtures:
Fixtures is a fixed state of a set of objects used as a baseline for running tests. The purpose of a test fixture is to ensure that th ere
is a well-known and fixed environment in which tests are run so that results are repeatable. It includes −
setUp() method, which runs before every test invocation.
tearDown() method, which runs after every test method.

Let's check one example −

import [Link].*;
public class JavaTest extends TestCase {
protected int value1, value2;

// assigning the values

protected void setUp(){
value1 = 3;
value2 = 3;
}

// test method to add two values

public void testAdd(){
double result = value1 + value2;
assertTrue(result == 6);
}}

Test Suites

A test suite bundles a few unit test cases and runs them together. In JUnit, both @RunWith and @Suite annotation are used to
run the suite test. Given below is an example that uses TestJunit1 & TestJunit2 test classes.

17
 Course Code/Title:CS2602/Software Testing Unit:IV

import [Link];import [Link];

//JUnit Suite Test@RunWith([Link])
@[Link]({
[Link] ,[Link]})
public class JunitTestSuite {}
import [Link];import [Link];import static [Link];
public class TestJunit1 {

String message = "Robert";

MessageUtil messageUtil = new MessageUtil(message);

@Test
public void testPrintMessage() {
[Link]("Inside testPrintMessage()");
assertEquals(message, [Link]());
}}
import [Link];import [Link];import static [Link];
public class TestJunit2 {

String message = "Robert";

MessageUtil messageUtil = new MessageUtil(message);

@Test
public void testSalutationMessage() {
[Link]("Inside testSalutationMessage()");
message = "Hi!" + "Robert";
assertEquals(message,[Link]());
}}

Test Runners

Test runner is used for executing the test cases. Here is an example that assumes the test class TestJunit already exists.

import [Link];import [Link];import [Link];

public class TestRunner {
public static void main(String[] args) {
Result result = [Link]([Link]);

for (Failure failure : [Link]()) {

[Link]([Link]());
}

[Link]([Link]());
}}

JUnit Classes

JUnit classes are important classes, used in writing and testing JUnits. Some of the important classes are −

Assert − Contains a set of assert methods.

TestCase − Contains a test case that defines the fixture to run multiple tests.

TestResult − Contains methods to collect the results of executing a test case.

18
 Course Code/Title:CS2602/Software Testing Unit:IV

JUNIT ANNOTATIONS

19
 Course Code/Title:CS2602/Software Testing Unit:IV

JUNIT ASSERTIONS:

20
Course Code/Title:CS2602/Software Testing Unit:IV

21
 Course Code/Title:CS2602/Software Testing Unit:IV

Creating suite test:

[Link]

22
 Course Code/Title:CS2602/Software Testing Unit:IV

Creating Parameterized Test:

23
Course Code/Title:CS2602/Software Testing Unit:IV

24
 Course Code/Title:CS2602 / Software Testing Unit: V

Unit V: PERFORMANCE TESTING AND SECURITY TESTING

Performance Testing Concepts-Load testing, stress testing, scalability testing, Performance Testing
Tools-JMeter, LoadRunner, etc. Introduction to Security Testing-Common security vulnerabilities,
Security Testing Tools-OWASP ZAP, Burp Suite, etc.

PERFORMANCE TESTING CONCEPTS

Performance Testing is a type of software testing that ensures software applications perform
properly under their expected workload. It is a testing technique carried out to determine system
performance in terms of sensitivity, reactivity, and stability under a particular workload.
Performance Testing is the process of analysing the quality and capability of a product. It is a
testing method performed to determine the system’s performance in terms of speed, reliability, and
stability under varying workloads. Performance testing is also known as Perf Testing.

Performance Testing Attributes:

• Speed: It determines whether the software product responds rapidly.

• Scalability: It determines the amount of load the software product can handle at a time.
• Stability: It determines whether the software product is stable in case of varying
workloads.

Objective of Performance Testing:

• The objective of performance testing is to eliminate performance congestion.

• It uncovers what needs to be improved before the product is launched in the market.
• The objective of performance testing is to make software rapid.
• The objective of performance testing is to make software stable and reliable.
• The objective of performance testing is to evaluate the performance and scalability of a
system or application under various loads and conditions. It helps identify bottlenecks,
measure system performance, and ensure that the system can handle the expected number of
users or transactions. It also helps to ensure that the system is reliable, stable, and can
handle the expected load in a production environment.
Types of Performance Testing:

Load testing: It checks the product’s ability to perform under anticipated user loads. The objective is
to identify performance congestion before the software product is launched in the market.
Stress testing: It involves testing a product under extreme workloads to see whether it handles high
traffic or not. The objective is to identify the breaking point of a software product.

Spike testing: It is a type of load testing that tests the system’s ability to handle sudden spikes in
traffic. It helps identify any issues that may occur when the system is suddenly hit with a high number
of requests.
Soak testing: Soak testing is a type of load testing that tests the system’s ability to handle a sustained
load over a prolonged period. It helps identify any issues that may occur after prolonged usage of the
system.

Endurance testing: This type of testing is similar to soak testing, but it focuses on the long- term
behaviour of the system under a constant load.

Volume testing: In volume testing, large number of data is saved in a database and the overall
software system’s behaviour is observed. The objective is to check the product’s performance under
varying database volumes.

LOAD TESTING
Load testing determines the behavior of the application when multiple users use it at the same
time. It is the response of the system measured under varying load conditions.

• The load testing is carried out for normal and extreme load conditions.

1
 Course Code/Title:CS2602 / Software Testing Unit: V

• Load testing is a type of performance testing that simulates a real-world load on a system or
application to see how it performs under stress.
• The goal of load testing is to identify bottlenecks and determine the maximum number of
users or transactions the system can handle.
• It is an important aspect of software testing as it helps ensure that the system can handle the
expected usage levels and identify any potential issues before the system is deployed to
production.
During load testing, various scenarios are simulated to test the system’s behavior under different
load conditions. This can include simulating a high number of concurrent users, simulating numerous
requests, and simulating heavy network traffic. The system’s performance is then measured and
analyzed to identify any bottlenecks or issues that may occur.

Load Testing Techniques:

Stress testing: Testing the system’s ability to handle a high load above normal usage levels.

Spike testing: Testing the system’s ability to handle sudden spikes in traffic.

Soak testing: Testing the system’s ability to handle a sustained load over a prolonged period of time.
Tools for Performance Testing: Make use of specialized load testing tools like Locust, Gatling,
JMeter, LoadRunner, and Apache Benchmark. These tools assist in gathering performance
measurements and simulating a large number of users.
Specify the Test Objectives: Clearly state what your load test’s goals are. Recognize the required
response times, transaction volumes and expected user behavior.

Determine Crucial Situations: Determine the essential user scenarios that correspond to common
usage patterns. A variety of actions, including user logins, searches, form submissions and other
significant interactions, should be covered by these scenarios.
Objectives of Load Testing:

Evaluation of Scalability: Assess the system’s ability to handle growing user and transaction
demands. Find the point at which the system begins to function badly.
Planning for Capacity: Describe the system’s ability to accommodate anticipated future increases in
the number of users, transactions and volume of data. Making well-informed decisions regarding
infrastructure upgrades is made easier by this.
Determine bottlenecks: Identify and localize bottlenecks in the application or infrastructure’s
performance. Finding the places where the system’s performance can suffer under load is part of this.

Analysis of Response Time: For crucial transactions and user interactions, track and evaluate
response times. Make that the system responds to changes in load with reasonable response times.
Finding Memory Leaks: Find and fix memory leaks that may eventually cause a decline in
performance. Make sure the programme doesn’t use up too many resources when it’s running.
Load Testing Process:

1. Test Environment Setup: Firstly create a dedicated test environment setup for performing
the load testing. It ensures that testing would be done in a proper way.
2. Load Test Scenario: In second step load test scenarios are created. Then load testing
transactions are determined for an application and data is prepared for each transaction.
3. Test Scenario Execution: Load test scenarios that were created in previous step are now
executed. Different measurements and metrices are gathered to collect the information.
4. Test Result Analysis: Results of the testing performed is analyzed and various
recommendations are made.
5. Re-test: If the test is failed then the test is performed again in order to get the result in
correct way.

2
 Course Code/Title:CS2602 / Software Testing Unit: V

Metrics of Load Testing:

Metrics are used in knowing the performance of load testing under different circumstances.
It tells how accurately the load testing is working under different test cases. It is usually carried out
after the preparation of load test scripts/cases. There are many metrics to evaluate the load testing.
Some of them are listed below.

1. Average Response Time

It tells the average time taken to respond to the request generated by the clients or customers
or users. It also shows the speed of the application depending upon the time taken to respond to the
all requests generated.

2. Error Rate
The Error Rate is mentioned in terms of percentage denotes the number of errors occurred
during the requests to the total number of requests. These errors are usually raised when the
application is no longer handling the request at the given time or for some other technical problems.
It makes the application less efficient when the error rate keeps on increasing.

3. Throughput
This metric is used in knowing the range of bandwidth consumed during the load scripts or tests and
it is also used in knowing the amount of data which is being used for checking the request that flows
between the user server and application main server. It is measured in kilobytes per second.

4. Requests Per Second

It tells that how many requests are being generated to the application server per second. The requests
could be anything like requesting of images, documents, web pages, articles or any other resources.

5. Concurrent Users
This metric is used to take the count of the users who are actively present at the particular time or at
any time. It just keeps track of count those who are visiting the application at any time without
raising any request in the application. From this, we can easily know that at which time the high
number of users are visiting the application or website.

6. Peak Response Time

Peak Response Time measures the time taken to handle the request. It also helps in finding the
duration of the peak time(longest time) at which the request and response cycle is handled and
finding that which resource is taking longer time to respond the request.
Load Testing Tools: Apache Jmeter, WebLoad, NeoLoad, LoadNinja, HPPerformance, Tester, LoadUI
Pro, LoadView.

3
 Course Code/Title:CS2602 / Software Testing Unit: V

STRESS TESTING
Stress Testing is a software testing technique that determines the robustness of software by
testing beyond the limits of normal operation. Stress testing is particularly important for critical
software but is used for all types of software. Stress testing emphasizes robustness, availability, and
error handling under a heavy load rather than what is correct behavior under normal situations.

Stress testing is defined as a type of software testing that verifies the stability and reliability
of the system. This test particularly determines the system on its robustness and error handling under
extremely heavy load conditions. It even tests beyond the normal operating point and analyses how
the system works under extreme conditions. Stress testing is performed to ensure that the system would
not crash under crunch situations. Stress testing is also known as Torture Testing.

Characteristics of Stress Testing:

1. Identification of Risk: Stress testing’s main objective is to locate and evaluate a system’s
possible hazards and weaknesses.
2. Quantitative and Qualitative Analysis: While numerical data are crucial, it’s also critical
to comprehend the qualitative characteristics of the system’s response and potential weak
points

3. Variable Parameters: Stress testing include changing variables including interest rates,
market conditions, transaction volumes and outside influences that could have an impact on
the system.
4. Cross-Functional Involvement: Many departments within an organization must work
together and participate in stress testing. This cross-functional strategy makes sure that the
stress testing procedure benefits from a variety of viewpoints and specialties.
5. Open and Honest Communication: Stress testing necessitates open and honest
communication regarding the goal, approach, and outcomes of the testing procedure.
Need for Stress Testing:

• To accommodate the sudden surges in traffic: It is important to perform stress testing to

accommodate abnormal traffic spikes. For example, when there is a sale announcement on
the e-commerce website there is a sudden increase in traffic. Failure to accommodate such
needs may lead to a loss of revenue and reputation.
• Display error messages in stress conditions: Stress testing is important to check whether
the system is capable to display appropriate error messages when the system is under stress
conditions.
• The system works under abnormal conditions: Stress testing checks whether the system
can continue to function in abnormal conditions.
• Prepared for stress conditions: Stress testing helps to make sure there are sufficient
contingency plans in case of sudden failure due to stress conditions. It is better to be
prepared for extreme conditions by executing stress testing.
Purpose of Stress Testing:

• Analyze the behavior of the application after failure: The purpose of stress testing is to
analyze the behavior of the application after failure and the software should display the
appropriate error messages while it is under extreme conditions.
• System recovers after failure: Stress testing aims to make sure that there are plans for
recovering the system to the working state so that the system recovers after failure.
• Uncover Hardware issues: Stress testing helps to uncover hardware issues and data
corruption issues.
• Uncover Security Weakness: Stress testing helps to uncover the security vulnerabilities
that may enter into the system during the constant peak load and compromise the system.

4
 Course Code/Title:CS2602 / Software Testing Unit: V

• Ensures data integrity: Stress testing helps to determine the application’s data integrity
throughout the extreme load, which means that the data should be in a dependable state even
after a failure.
Stress Testing Process:

The stress testing process is divided into 5 steps:

1. Planning the stress test: This step involves gathering the system data, analyzing the system,
and defining the stress test goals.
2. Create Automation Scripts: This step involves creating the stress testing automation
scripts and generating the test data for the stress test scenarios.
3. Script Execution: This step involves running the stress test automation scripts and storing
the stress test results.
4. Result Analysis: This phase involves analyzing stress test results and identifying the
bottlenecks.
5. Tweaking and Optimization: This step involves fine-tuning the system and
optimizing the code with the goal meet the desired benchmarks.

Types of Stress Testing:

1. Server-client Stress Testing: Server-client stress testing also known as distributed stress
testing is carried out across all clients from the server.
2. Product Stress Testing: Product stress testing concentrates on discovering defects related to
data locking and blocking, network issues, and performance congestion in a software
product.
3. Transactional Stress Testing: Transaction stress testing is performed on one or more
transactions between two or more applications. It is carried out for fine-tuning and
optimizing the system.
4. Systematic Stress Testing: Systematic stress testing is integrated testing that is used to
perform tests across multiple systems running on the same server. It is used to discover
defects where one application data blocks another application.
5. Analytical Stress Testing: Analytical or exploratory stress testing is performed to test the
system with abnormal parameters or conditions that are unlikely to happen in a real scenario.
It is carried out to find defects in unusual scenarios like a large number of users logged at
the same time or a database going offline when it is accessed from a website.
6. Application Stress Testing: Application stress testing also known as product stress testing
is focused on identifying the performance bottleneck, and network issues in a software
product.

Stress Testing Tools:

1. Jmeter: Apache JMeter is a stress testing tool is an open-source, pure Java-based software
that is used to stress test websites. It is an Apache project and can be used for load testing for
analyzing and measuring the performance of a variety of services.

5
 Course Code/Title:CS2602 / Software Testing Unit: V

2. LoadNinja: LoadNinja is a stress testing tool developed by SmartBear that enables users to
develop codeless load tests, substitutes load emulators with actual browsers, and helps to
achieve high speed and efficiency with browser-based metrics.
3. WebLoad: WebLoad is a stress testing tool that combines performance, stability, and
integrity as a single process for the verification of mobile and web applications.
4. Neoload: Neoload is a powerful performance testing tool that simulates large numbers of
users and analyzes the server’s behavior. It is designed for both mobile and web applications.
Neoload supports API testing and integrates with different CI/ CD applications.
5. SmartMeter: SmartMeter is a user-friendly tool that helps to create simple tests without
coding. It has a graphical user interface and has no necessary plugins. This tool automatically
generates advanced test reports with complete and detailed test results.
Metrics of Stress Testing:

Metrics are used to evaluate the performance of the stress and it is usually carried out at the end of the
stress scripts or tests. Some of the metrics are given below.

1. Pages Per Second: Number of pages requested per second and number of pages loaded per
second.
2. Pages Retrieved: Average time is taken to retrieve all information from a particular page.
3. Byte Retrieved: Average time is taken to retrieve the first byte of information from the page.
4. Transaction Response Time: Average time is taken to load or perform transactions
between the applications.
5. Transactions per Second: It takes count of the number of transactions loaded per
second successfully and it also counts the number of failures that occurred.
6. Failure of Connection: It takes count of the number of times that the client faced
connection failure in their system.
7. Failure of System Attempts: It takes count of the number of failed attempts in the system.
8. Rounds: It takes count of the number of test or script conditions executed by the clients
successfully and it keeps track of the number of rounds failed.

Scalability Testing:
Scalability Testing is a type of non-functional testing in which the performance of a software
application, system, network or process is tested in terms of its capability to scale up or scale down
the number of user request load or other such performance attributes. It can be carried out at a
hardware, software or database level. Scalability Testing is defined as the ability of a network,
system, application, product or a process to perform the function correctly when changes are made in
the size or volume of the system to meet a growing need. It ensures that a software product can
manage the scheduled increase in user traffic, data volume, transaction counts frequency and many
other things. It tests the system, processes or database’s ability to meet a growing need.
Scalability Testing is to measure at what point the software product or the system stops scaling and
identify the reason behind it. The parameters used for this testing differs from one application to
another. For example, scalability testing of a web page depends on the number of users, CPU usage,
network usage while scalability testing of a web server depends on the number of requests processed.
Objective of Scalability Testing:
The objective of scalability testing is:
 To determine how the application scales with increasing workload.
 To determine the user limit for the software product.
 To determine client-side degradation and end user experience under load.
 To assess the system’s performance under various network circumstances, such as latency and
bandwidth fluctuations, in order to guarantee dependable operation in a range of settings.
 To determine whether the system is capable of withstanding scenarios of high usage, making
sure that unexpected spikes in traffic can be accommodated without causing performance issues.
 To guarantee that the system’s scalability prevents performance decline and maintains
acceptable response times, both of which improve user experience.
 To determine server-side robustness and degradation.

6
 Course Code/Title:CS2602 / Software Testing Unit: V

 To help developers improve the system design or code by pointing out locations that could
become bottlenecks when the load grows.
 To evaluate the effective use of system resources, including CPU, memory and network
bandwidth, in relation to the system’s increasing load, in order to guarantee resource
management.
 To make that the system satisfies performance criteria and offers a satisfying user experience,
assess the system’s response time under various loads.

Scalability Testing Attributes:

Response Time: Response time is the time consumed between the user’s request and the
application’s response. Response time may increase or decrease based on different user load on the
application. Basically, the response time of an application decreases as the user load increases.
Application having the lesser response time is considered as the higher performance application.
Throughput: Throughput is the measurement of number of requests processed in a unit time by the
application. It differs from one application to another as in web application it is measured in number
of user requests processed in a unit time whereas in database application it is measured in number of
queries processed in a unit time.
Performance measurement with number of users: Depending on the application type, it is always
tested for the number of users that it can support without its breakdown or busy standby situation.
Threshold load: Threshold load is the number of requests or transactions the application can process
with desired throughput.
CPU Usage: CPU Usage is the measurement of the CPU utilization while executing application code
instructions. It is basically measured in terms of the unit Megahertz.
Memory Usage: Memory usage is the measurement of the memory consumed for performing a task
by an application. It is basically measured in terms of the unit bytes.
Network Usage: Network usage is the measurement of the bandwidth consumed by an application
under test. It is measured in terms of bytes received per second, frames received per second, segments
received and sent per second etc.

Steps of Scalability Testing:

Following are the steps involve in the scalability testing:
1. Define a process that is repeatable for executing scalability test.
2. Determine the criteria for scalability test.
3. Determine the software tools required to carry out the test.
4. Set the testing environment and configure the hardware required to execute a scalability test.

5. Create and verify visual script.

6. Create and verify the load test scenarios.
7. Execute the test.
8. Evaluate the result.
9. Generate required report.

Advantages of Scalability Testing:

 It provides more accessibility to the product.
 It detects issues with web page loading and other performance issues.
 It finds and fixes the issues earlier in the product which saves a lot of time.
 It ensures the end user experience under the specific load. It provides customer satisfaction.
 It helps in effective tool utilization tracking.

Disadvantages of Scalability Testing:

 Sometimes, it fails to find the functional errors or issues in the product.
 Some automation tools used for Scalability testing is costlier which ultimately increases the
budget of the product.
 Team members involve in this testing technique should have high level of testing skills.
 The time spent on testing some parts of product may consume more time than expected time.
 Unexpected results may also be raised after launching the product in the customer environment.

7
 Course Code/Title:CS2602 / Software Testing Unit: V

Scalability testing is a type of software testing that verifies a system’s ability to scale up or down as
the workload increases or decreases. This testing is important for ensuring that the system can handle
increasing amounts of traffic, data, or users without degrading performance or stability.
Some tools that can be used for scalability testing include Apache Meter, HP Roadrunner, and
Gatling. These tools can simulate different levels of traffic and workload and measure the system’s
performance metrics.

Performance Testing Tools:

Introduction to Apache JMeter

JMeter also known as 'Apache JMeter' is an open source, 100% java based
application with a graphical interface. It is designed to analyse and measure the
performance and load functional behaviour of web application and variety of
services.

JMeter is mainly used for testing Web application or FTP application but
currently, it is applicable in functional testing, JDBC database connections, Web
services, generic TCP connections and OS native processes. You can perform
various testing activities like Performance, Load, Stress, Regression and
Functional testing, in order to get accurate performance metrics against your web
server.

JMeter was originally written and developed by Stefano Mazzocchi of the

Apache Software Foundation. It was primarily written to test the performance of
Apache JServ(currently known as Apache Tomcat project).Apache redesigned
JMeter to enhance the GUI, to add more features and functional testing
capabilities.

JMeter is not a browser and it doesn't render html pages like any browser does,
rather it works on protocol level.

Following is a list of protocols supported by JMeter:

o Web Services - SOAP / XML-RPC

o Web - HTTP, HTTPS sites 'web 1.0' web 2.0 (ajax, 昀氀 ex and 昀氀 ex-ws-amf)
o Database via JDBC drivers
o Directory - LDAP
o Messaging oriented service via JMS
o Service - POP3, IMAP, SMTP

A web server carries a lot number of applications and users, so it is necessary to

know that how capable a web server is to handle simultaneous users or
applications. For example; how "javaTpoint" supporting server will perform
when a number of users simultaneously access the javaTpoint website - basically
have to do performance testing using performance testing tools like JMeter.

8
 Course Code/Title:CS2602 / Software Testing Unit: V

JMeter Features

Some of the most important features of JMeter are listed below:

o Open source application: JMeter is a free open source application

which facilitatesusers or developers to use thesource code for
developmentof other applications.
o User-friendly GUI: JMeter comes with simple and interactive GUI.
o Support various testing approach: JMeter supports various testing
approach like Load Testing, Distributed Testing, and Functional Testing,
etc.
o Platform independent: JMeter is written and developed using java, so
it can run on any environment / workstation that accepts a Java virtual
machine, for example - Windows, Linux, Mac, etc.
o Support various server types: JMeter is highly extensible and capable
to load the performance test in different server types:

o Web: HTTP, HTTPS, SOAP,

o Database: JDBC, LDAP, JMS, and

o Mail: POP3.

o Support multi-protocol: JMeter supports protocols such as HTTP,

JDBC, LDAP, SOAP, JMS, and FTP.
o Simulation: JMeter can simulate multiple users by using virtual users or
unique users in order to generate heavy load against web application
under test.
o Framework: JMeter is a multi-threading framework which allows
concurrent and simultaneous sampling of different functions by many or
separate thread groups.
o Remote distributed testing: JMeter has Master-Slave concept for
distributed testing where master will distribute tests among all slaves and
slaves will execute scripts against your server.
o Test result visualization: Test results can be viewed in different formats
like graph, table, tree, and report etc.

Working of JMeter

JMeter sends requests to a target server by simulating a group of users.

Subsequently, data is collected to calculate statistics and display performance
metrics of the target server through various formats.

9
 Course Code/Title:CS2602 / Software Testing Unit: V

JMeter work flow Diagram:

JMeter Installation

We assume that you have already installed 'jdk 1.6' or above on your machine and
successfully configured the environment variables required to run and compile java
programs.

However, to verify whether you have Java installed on your system. Open your
console and execute the following java commands as per the operating system
you are working on.

Operating System Task Command

Windows Open Command Console c:\> java -version

Linux Open Command Terminal $ java -version

Mac Open Terminal machine: ~ javaTpoint$ java -

version

The latest version of JMeter can be downloaded from

Download Latest version of JMeter

o There are two versions of JMeter available. Download according to the

operating system you are working on.

File Description

[Link] JMeter for Linux/Unix.

[Link] JMeter for Windows

o After downloading JMeter, you need to extract the files at a convenient directory.
o The following image shows the structure of the directories and files -

10
 Course Code/Title:CS2602 / Software Testing Unit: V

To launch JMeter in GUI mode - go to the bin directory and double click on
the respective executable file as per the operating system you are working on.

For example:

Operating System Task

Windows Click on [Link]

Linux Click on [Link]

Mac Click on [Link]

JMeter Test Plan Elements

JMeter comprises of various elements which co-relates with each other but
designed for different purposes. Before you start working on JMeter, it is good to
know some of the major elements of JMeter with full detail description.

Following are some of the major components of JMeter:

o Test Plan
o Thread Group
o Controllers
o Listeners
o Timers
o Configuration Elements
o Pre-Processor Elements
o Post-Processor Elements

Please refer to the below flow diagram to understand each component and their
relation to specific modules of JMeter.

11
 Course Code/Title:CS2602 / Software Testing Unit: V

Test Plan

A test plan can be visualized as your JMeter script for running tests. A test plan
consists of test elements such as thread groups, logic controllers, sample-
generating controllers, listeners, timers, assertions, and configuration elements.

A test plan consists of all steps which execute the script. Everything which is
included in a test plan is executed in a sequence which is top to bottom or as per the
designed sequence in the test plan. The figure given below shows the directory level
of a test plan.

Important points regarding a Test Plan -

o The test plan should be saved before running the entire test plan.
o JMeter files or test plans are saved in form of .JMX extension files. JMX is
an open test based format, it enables the test plan to be launched in a text
editor.
o You can also save parts of test plan as the different selection. For example,if
you want to save HTTP request sampler with listener, you can save it as
test fragment so that it can be used in other test scenarios as well.

Thread Group

As the name implies, thread group represents the group of threads JMeter will
use during the test. Thread group elements are the beginning points of any test
plan. The controls provided by a thread group allow you to:

o Set the number of threads.

o Set the ramp-up period.
o Set the number of times to execute the test.

The steps to add a thread group in your test plan had been explained earlier in the
Add/Remove test elements portion.

The Thread Group Control Panel includes:

o Itsname.
o Number of threads (the number of users you are testing).
o Ramp-up time (how much time you want to allow the Thread Group to
go from 0 to 3 users).
o Loop count (How many times the test should be looped).
o Scheduler checkbox (The checkbox at the bottom of the Thread Group
panel is used to enable/disable extra fields in which you can enter the
duration of test, the startup delay, the start and end times of the run).

Controllers

Controllers can be divided into two broad categories:

o Samplers
o Logical Controllers

Samplers

Samplers are the components which allow JMeter to send specific types of
requests to a [Link] simulates a user's request for a page to the target server.

12
 Course Code/Title:CS2602 / Software Testing Unit: V

Samplers are a must to add component to a test plan as only it can let JMeter
know what type of request need to go to a server. Requests could be HTTP,
HTTP(s), FTP, TCP, SMTP, SOAP etc.

Given below is the list of requests serviced by JMeter samplers:

o FTP Request
o HTTP Request (can be used for SOAP or REST Webservice also)
o JDBC Request
o Java object request
o JMS request
o JUnit Test request
o LDAP Request
o Mail request
o OS Process request
o TCP request
Logical Controllers

Logic Controllers help you to control the flow the order of processing of samplers in
a thread. It can also change the order of requests coming from their child elements.

Following is the list of all Logic Controllers in JMeter:

o Runtime Controller
o IF Controller
o Transaction Controller
o Recording Controller
o Simple Controller
o While Controller
o Switch Controller
o ForEach Controller
o Module Controller
o Include Controller
o Loop Controller
o Once Only Controller
o Interleave Controller
o Random Controller
o Random Order Controller
o Throughput Controller

Listeners

Performance testing is all about analysing server responses in various

forms and then presenting the same to the client.

Listeners provide pictorial representation of data gathered by JMeter about those

test cases as a sampler component of JMeter is executed. It facilitates the user to
view samplers result in the form of tables, graphs, trees or simple text in some log
file.

13
 Course Code/Title:CS2602 / Software Testing Unit: V

Listeners can be adjusted anywhere in the test, including directly under the test
plan. There are around 15 listeners provided by JMeter but mostly used ones are
table, tree, and Graph.

Following is the list of all Listeners in JMeter:

o Graph Results
o Spline Visualizer
o Assertion Results
o Simple Data Writer
o Monitor Results
o Distribution Graph (alpha)
o Aggregate Graph
o Mailer Visualizer
o BeanShell Listener
o Summary Report
o Sample Result Save Configuration
o Graph Full Results
o View Results Tree
o Aggregate Report
o View Results in Table

Timers

When you perform any operation on a website or app, they naturally have pauses
and delays. These can be simulated with Timers.

JMeter sends requests without applying any delay between each sampler/request.
If you perform load/stress testing on your server without any delay, it will be
overloaded. This not exactly what you want. You can add a timer element which
will permit you to define a period to wait between each request.

Given below is the list of all the Timer elements provided by JMeter:

o Synchronizing Timer
o JSR223 Time
o BeanShell Time
o Gaussian Random Timer
o Uniform Random Timer
o Constant Throughput Timer
o BSF Time
o Poisson Random Time

Configuration Elements

Working of configuration elements is quite similar to those of [Link],

it does not send requests but it allows you to modify the requests made by the
samplers.

It is a simple element where you can collects the corporate configuration values of all
samplers like webserver's hostname or database url etc.

14
 Course Code/Title:CS2602 / Software Testing Unit: V

A configuration element is accessible from only inside the branch where you place the element.

Given below is the list of some of the most commonly used configuration elements
provided by JMeter:

o Java Request Defaults

o LDAP Request Defaults
o LDAP Extended Request Defaults
o Keystore Configuration
o JDBC Connection Configuration
o Login Config Element
o CSV Data Set Config
o FTP Request Defaults
o TCP Sampler Config
o User Defined Variables
o HTTPAuthorization Manager
o HTTP Cache Manager
o HTTP Cookie Manager
o HTTP Proxy Server
o HTTP Request Defaults
o HTTP Header Manager
o Simple Config Element
o Random Variable

Pre-processor Elements

A Pre-Processor element is executed just before the request made by the sampler.
If a Pre- processor is attached to a sampler element then it will execute just prior
to that sampler element running.

A Pre-processor element is used to modify the settings of a sample request just

before it runs, or to update variables that are not extracted from response text.

Following is a list of all Pre-processor elements provided by JMeter:

o JDBC Pre-processor
o JSR223 Pre-processor
o RegEx User Parameters
o BeanShell Pre-processor
o BSF Pre-processor
o HTML Link Parser
o HTTP URL Re-writing Modifier
o HTTP User Parameter Modifier
o User Parameters

Post-processor Elements

A Post-processor element is executed after a sampler request has been made. If a

Post- Processor is attached to a Sampler element then it will execute just after that
sampler element runs.

15
 Course Code/Title:CS2602 / Software Testing Unit: V

A Post-processor is most often used to process the response data, for example, to
extract a particular value for future purpose.

Given below is the list of all Post-processor elements provided by JMeter:

o CSS/JQuery Extractor
o BeanShell Post-processor
o JSR223 Post-processor
o JDBC Post-processor
o Debug Post-processor
o Regular Expression Extractor
o XPath Extractor
o Result Status Action Handler
o BSF Post-processor
Build JMeter Test Plan

Atest plan can be visualized as your JMeter script for running tests. A test plan
consists of test elements such as thread groups, logic controllers, sample-
generating controllers, listeners, timers, assertions, and configuration elements.

There should be at least one thread group in every test plan. We can add or
remove elements as per our requirement.

Let's start building a Test plan by following these simple steps:

Step 1: Launch the JMeter window.

o Go to your JMeter bin folder and double click on the [Link]

file to launch JMeter interface.

o The default JMeter interface contains a Test Plan node where the real test
plan is kept.
o The Test Plan node contains Name of the test plan and user defined variables.
o User defined variables provides flexibility when you have to repeat any
value in several parts of the test plan.

Step 2: Add/Remove test plan elements.

o Once you have created a test plan for JMeter, the next step is to
add and remove elements to JMeter test plan.
o Select the test plan node and right click on the selected item.
o Mouse hover on "Add" option, then elements list will be displayed.
o Mouse hover on desired list element, and select the desired option by clicking.
o To remove an element, select the desired element.
o Right click on the element and choose the "Remove" option.

Step 3: Load and save test plan elements.

o To load elements to JMeter test plan tree, select and right click on any
Tree Element on which you want to add the loaded element.
o Select "Merge" option.
o Choose the .jmx file where you save the elements.

16
 Course Code/Title:CS2602 / Software Testing Unit: V

o Elements will be merged into the JMeter test plan tree.

o To save tree elements, right click on the element.
o Choose "Save Selection As" option.
o Save file on desired location

Step 4: Configuring the tree elements.

Elements in the test plan can be configured by using controls present on JMeter’s
right hand side frame. These controls allow you to configure the behaviour of the
selected element. For example, a thread group can be configured by-

o Itsname.
o Number of threads (the number of users you are testing).
o Ramp-up time (how much time you want to allow the Thread Group to
go from 0 to 3 users).
o Loop count (How many times the test should be looped).

Step 5: Save JMeter test plan

o Till now we are done with creating a test plan, adding an element and
configuring a Tree.
o Now, you can save the entire test plan by choosing the "Save" or "Save
Test Plan As" from file menu.

Step 6: Run JMeter test plan.

o You can run the test plan by clicking on the Start (Control + r) from the
Run menu item or you can simply click the green play button.
o When the test plan starts running, the JMeter interface shows a green
circle at the right- hand end of the section just under the menubar.
Step 7: Stop JMeter test plan.

o You can stop the test plan by using Stop (Control + '.') - It stops the
threads immediately if possible.
o You can also use Shutdown (Control + ',') - It requests the threads to
stop at the end of any on-going task.

Step 8:Check JMeter test plan execution logs.

o JMeter stores the test run details, warnings and errors to [Link] file.
o You can access JMeter logs by clicking on the exclamation sign present
at the right-hand side of the section just under the menubar.

LoadRunner:
IntroductiontoLoadRunner

A software testing tool called LoadRunner is used to measure system performance and behavior
under load, it is used to test applications.

Overview of LoadRunner

The idea behind LoadRunner is to record and repeat user actions to create the appropriate load
on the server. Creating a virtual load merely mimics the actions of a real user and aids in
determining how well a software program or system performs.

17
 Course Code/Title:CS2602 / Software Testing Unit: V

The Primary functions of the LoadRunner are

Recording/Scripting: Using a script to record user action.

Test Execution: To replicate a real-world scenario in the test environment, repeat the script in tandem
with the virtual load.
Result Analysis: To give precise findings regarding the application’s responsiveness and ability to
handle loads.

 LoadRunner creates virtual users to execute scripts that mimic actual user activity. “Vusers” is
the term for these virtual users.
 The traffic on the server is produced by Vusers running concurrently throughout the execution of
performance tests.
 After the test is over, LoadRunner gathers the data and stores it in a file called raw results.
 The Microfocus Analysis tool can be used to open this file and undertake additional analysis of
the test result.
 The analysis tool ultimately produces a report that summarizes the test outcome.

Components of Load Runner

Major components of LoadRunner include the following:

Virtual User Generator or VuGen: It is a tool that captures business processes used by end users and
builds an automated test script that looks like a programming language. The created script is referred to
as a “Test Script” or “VuGen Script.”
Load Generators: These are devices that create virtual loads following specifications. Every user in the
scenario is assigned to a load generator by the Controller during test execution. To replicate the users’
geographic location, a load generator is also employed.
Controller: It plans, directs, oversees, and keeps an eye on the load test. Workload modeling also
makes use of a controller. The process of creating a test scenario by NFR (non-functional requirement)
is known as workload modeling.
Agent: The LoadRunner agent establishes contact between the load generator and the controller.
Analysis: To check the test result against the specified NFRs (non-functional requirements) and
identify the bottleneck (performance problems), the analysis tool shows graphs and statistics of the test
results. Based on the test result, the analysis tool also produces a report.

Steps Involved in Performance Test Using Load Runner

LoadRunner goes through five main processes. Almost all of the performance testing products on the
market adhere to the same procedures as LoadRunner.

 Script Creation
 Scenario Creation
 Test Execution and Monitoring
 Result Gathering and Analysis
 Reporting

Script Creation

To capture the business flows, LoadRunner features a special component called “VuGen,” or “Virtual
User Generator.” The actual user’s website
navigation is captured by VuGen, which then translates it into a script.

The ANSI C scripting language is supported by VuGen and is simple to learn and comprehend. The C
programming language makes it simple to define variables and functions, write custom code, and apply
new logic, which makes scripting in LoadRunner simple.

Three main steps go into creating a LoadRunner script:

18
 Course Code/Title:CS2602 / Software Testing Unit: V

Protocol Identification: You must be aware of the application’s technology and platform to write a
script.
Script Recording: LoadRunner’s greatest benefit is its recording feature. It eliminates the need for a
performance tester to spend time and energy writing manual code and supports recording for 90%–95%
of protocols.
Script Enhancement: LoadRunner creates a simple script of sophisticated correlation, parametrization,
etc. Upon recording completion, script enhancement fully automates the VuGen script. The steps in
script enhancement are as follows:
 Parameterization
 Correlation
 Insert Transactions
 Add Rendezvous Points
 Insert Basic Function
 Insert Comments
 Enable log messages
 Insert synchronization points
 Set up the run-time setting.

Scenario Creation

A scenario outlines the test’s objectives and methodology. A load runner scenario includes the test time,
a list of machines, a defined workload model, and the script.

Performance testing is necessary under NFR(non-functional requirements) for the set of business flows
as they relate to the LoadRunner script.
The Performance Center’s “Test Plan” or the load runner’s “Controller” generates a scenario. The
configuration and scheduling of the scenario, which dictates the behavior of all load generators and
Vusers during the test, are set during scenario design.
Proper NFRs, the anticipated TPS (transaction per second), and user count are necessary before
creating a scenario.

The scenario must be created in a way that allows for the achievement of the desired metrics (TPS and
user load). To get the desired results, you may occasionally need to adjust the script’s thought time and
pacing. Consult the following calculators to assist you in generating the appropriate scenario:

 Pacing
 Think Time
 No. of Users
 TPS
 No. of required LGs
Test Execution and Monitoring

To begin monitoring the graphs, you just need to “run” the scenario that has been constructed. You can
be sure that the performance test is running as planned and that every Vuser is adhering to the same
business processes that were addressed in the scripts.
The transactions of the Vuser script are measured, recorded, and shown on the dashboard by
LoadRunner during the test execution process.
There are numerous monitoring graphs available in LoadRunner that display client-side data.
There are several of them, including response time, TPS, running Vuser, throughput, system
performance, etc.
Monitoring server-side statistics is another advantage that comes with integrating some external
monitors, such as SiteScope.

Result Gathering and Analysis

Following the test, the controller compiles and aggregates the results. The raw format contains the
compiled result.

The test result can also be obtained in HTML format if you operate in the Performance Center and
select the “Collate and Analysis” option.

19
 Course Code/Title:CS2602 / Software Testing Unit: V

These files with the test results can be downloaded to your local computer.
The “Analysis” tool, a feature exclusive to LoadRunner, is used to analyze the outcome.
The analysis tool offers the ability to view the raw result file, which is produced following the test and
shown in a tabular and graphical format.
The analysis tool is equipped with numerous features that provide an in-depth examination of the
obtained data and identify the real bottlenecks.
To finish diagnosing the problems, you can also add filters, correlation, merging, and overlay options
to the graphs.

Reporting

An analysis tool offers multiple report formats. After the test analysis is finished, you can create a
summary of the test results, identify the bottleneck and describe it, select the graphs you want to be
included in the report, and generate it in the format you want (.doc,.docx,.pdf,.html, etc.).

To let the client or project know who was involved in the testing, report generation also includes an
option to add the organization’s logo, the name of the author, the name of the tester, etc.

SECURITY TESTING
Security testing is an integral part of software testing, which is used to discover the
weaknesses, risks, or threats in the software application and also help us to stop the nasty attack from
the outsiders and make sure the security of our software applications.
The primary objective of security testing is to find all the potential ambiguities and
vulnerabilities of the application so that the software does not stop working. If we perform security
testing, then it helps us to identify all the possible security threats and also help the programmer to
fix those errors.
It is a testing procedure, which is used to define that the data will be safe and also continue
the working process of the software.
Principle of Security testing:

Availability: In this, the data must be retained by an official person, and they also guarantee that the
data and statement services will be ready to use whenever we need it.
Integrity: In this, we will secure those data which have been changed by the unofficial person. The
primary objective of integrity is to permit the receiver to control the data that is given by the system.

The integrity systems regularly use some of the similar fundamental approaches as
confidentiality structures. Still, they generally include the data for the communication to create the
source of an algorithmic check rather than encrypting all of the communication. And also verify that
correct data is conveyed from one application to another.

20
 Course Code/Title:CS2602 / Software Testing Unit: V

Authorization: It is the process of defining that a client is permitted to perform an action and also
receive the services. The example of authorization is Access control.

Confidentiality: It is a security process that protracts the leak of the data from the outsider's because
it is the only way where we can make sure the security of our data.
Authentication: The authentication process comprises confirming the individuality of a person,
tracing the source of a product that is necessary to allow access to the private information or the
system.

Non-repudiation: It is used as a reference to the digital security, and it a way of assurance that the
sender of a message cannot disagree with having sent the message and that the recipient cannot
repudiate having received the message.
The non-repudiation is used to ensure that a conveyed message has been sent and received
by the person who claims to have sent and received the message.
Key Areas in Security Testing:
While performing the security testing on the web application, we need to concentrate on the
following areas to test the application:

System software security: In this, we will evaluate the vulnerabilities of the application based on
different software such as Operating system, Database system, etc.
Network security: In this, we will check the weakness of the network structure, such as policies and
resources.
Server-side application security: We will do the server-side application security to ensure that the
server encryption and its tools are sufficient to protect the software from any disturbance.

Client-side application security: In this, we will make sure that any intruders cannot operate on any
browser or any tool which is used by customers.

21
 Course Code/Title:CS2602 / Software Testing Unit: V

Types of Security testing:

As per Open Source Security Testing techniques, we have different types of security testing
which as follows:

Security Scanning: Security scanning can be done for both automation testing and manual testing.
This scanning will be used to find the vulnerability or unwanted file modification in a web-based
application, websites, network, or the file system. After that, it will deliver the results which help us
to decrease those threats. Security scanning is needed for those systems, which depends on the
structure they use.
Risk Assessment: To moderate the risk of an application, we will go for risk assessment. In this, we
will explore the security risk, which can be detected in the association. The risk can be further
divided into three parts, and those are high, medium, and low. The primary purpose of the risk
assessment process is to assess the vulnerabilities and control the significant threat.

Vulnerability Scanning: It is an application that is used to determine and generates a list of all the
systems which contain the desktops, servers, laptops, virtual machines, printers, switches, and
firewalls related to a network. The vulnerability scanning can be performed over the automated
application and also identifies those software and systems which have acknowledged the security
vulnerabilities.
Penetration testing: Penetration testing is a security implementation where a cyber-security
professional tries to identify and exploit the weakness in the computer system. The primary objective
of this testing is to simulate outbreaks and also finds the loophole in the system and similarly save
from the intruders who can take the benefits.
Security Auditing: Security auditing is a structured method for evaluating the security measures of
the organization. In this, we will do the inside review of the application and the control system for
the security faults.

Ethical hacking: Ethical hacking is used to discover the weakness in the system and also helps the
organization to fix those security loopholes before the nasty hacker exposes them. The ethical
hacking will help us to increase the security position of the association because sometimes the ethical
hackers use the same tricks, tools, and techniques that nasty hackers will use, but with the approval of
the official person.
The objective of ethical hacking is to enhance security and to protect the systems from malicious
users' attacks.
Posture Assessment: It is a combination of ethical hacking, risk assessments, and security scanning,
which helps us to display the complete security posture of an organization.

22
 Course Code/Title:CS2602 / Software Testing Unit: V

Common Security Vulnerablities:

The acronym OWASP refers to the Open Web Application Security Project. It is a non-profit
organization whose primary objective is to strengthen software security through the implementation of
community-developed open-source programs, the formation of local chapters throughout the globe
with participants, learning and meetings, forums, and conferences.
The following are the top 10 vulnerabilities:
1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging and Monitoring Failures
10. Server-Side Request Forgery

A01:2021—Broken Access Control

This vulnerability allows bad actors to bypass authentications and gain access to sensitive data and
systems. They can exploit this vulnerability simply by modifying the URL or by changing the
parameter within the browser.
And it occurs due to the lack of proper access control configuration.
Impacts of Broken Access Control:
 Admin privilege even without being logged in
 Add, modify, or remove the data from the user record
 Reputational loss
How to prevent Broken Access Control:
 Implement deny-by-default for resources that are not to be made public
 Minimize Cross-Origin Resource Sharing (CORS)
 Implement monitoring and alert for admins for suspicious user access
 Implement rate limiting to prevent brute forcing
 Ensure metadata and backup files are not present in web roots

A02:2021—Cryptographic Failures
This vulnerability enables bad actors to bypass encryptions implemented over sensitive data such as
passwords, financial records, credit card numbers, health records, personal information, and even
business-related classified information.
This vulnerability is exploited in scenarios in which either automatic database encryption is used or a
lack of proper encryption of network requests or when simple or unsalted hashes are used for
encryption for data storage.
Impacts of Cryptographic Failures
 Sensitive data breach
 Hefty fines from legal authorities due to lack of data privacy compliance
How to prevent Cryptographic Failures
 Encrypt sensitive data in transit and storage with secure protocols and standards
 Delete sensitive data that is stored unnecessarily
 Ensure cryptographic randomness wherever possible and ensure it is not predictable
 Store passwords with strong and adaptive hashing functions
 Avoid outdated cryptographic mechanisms

A03:2021 — Injection
This vulnerability allows attackers to exploit an application or even gain access to its infrastructure
when it does not properly sanitize user input.

23
 Course Code/Title:CS2602 / Software Testing Unit: V

It can be executed by uploading unintended data or pieces of code along with the web request, which
makes the interpreter output sensitive information stored in the database server.
Also, injection is a group of vulnerabilities that contains:
 SQL/NoSQL Injection
 Command Injection
 Cross-Site Scripting (XSS)
 LDAP Injection
Impacts of Injection attacks?
 Data leak
 Partial or complete access to the server
 Response manipulation
 Loss of user integrity
How to prevent Injection attacks?
 Source code review
 User input sanitation and filtering
 Output encoding
 Implementing limit over output and connection timeout

A04:2021 — Insecure Design

Secure design is a process for evaluating threats continually and ensuring that code is robustly built and
tested to prevent known attack methods.
A lack of inefficient control design leads to this vulnerability and it fails to choose the level of security
architecture for the application or the organization.
Impacts of Insecure Design
 Access to sensitive data stored in the vulnerable system or server
 Altering the functionality of the application
How to prevent insecure design
 Implementing security checks from the initial phase of SDLC(Software Development Lifecycle)
 Validate all important flows that are immune to the threat model and create use-cases and misuse-
cases for each layer of your application.
 For important authentication, access control, business logic, and key flows, use threat modeling.
 Implement and use secure design patterns and libraries

A05:2021—Security Misconfiguration
Indeed we must configure security measures in our systems and applications. But what if they are not
properly configured?
It can be misconfigured or unchanged default (common) credentials, enable unnecessary features such
as (ports, services, privileges, pages, etc.), outdated software, etc.
Impacts of Security Misconfiguration
 Complete access over the server or the system and the data stored
 Functionality manipulation of the application, which affects the user
How to prevent Security Misconfiguration
 Make the application minimal with just the necessary features and frameworks used
 Share security practices and directives with the clients
 Implement separate credentials for each phase of development (development, QA, production)
environments

A06:2021-Vulnerable and Outdated Components

Software service providers fix vulnerabilities in their products with each software security upgrade.
This includes the operating system, web and application servers, database management systems,
runtime environments, libraries, and all APIs and related parts.

24
 Course Code/Title:CS2602 / Software Testing Unit: V

This vulnerability takes place if we haven’t updated or implemented the latest version of the secure
software. It results in making the entire application vulnerable from the vulnerable framework or
software we used within.
Also, this vulnerability takes place when you implement software and its related components in your
application for unreliable or untrusted sources.
Impacts of Vulnerable and Outdated Components
 Server compromise
 Data breach
 Reputational damage over the firm
How to prevent Vulnerable and Outdated Components
 Update the software and framework patches
 Remove unnecessary dependencies
 Only rely on components and dependencies from secure sources

A07:2021 – Identification and Authentication Failures

This vulnerability is related to security weakness in the login module.
It occurs due to a lack of restrictions for automated attacks, unchanged default passwords, improper
session validation or expiry, and a lack of restrictions for weak or well-known passwords.
Impacts of Identification and Authentication Failures
 User account takeover
 Identity theft
How to prevent Identification and Authentication Failures
 Restrict weak or default passwords
 Implement Multi-Factor Authentication
 Log failed password attempts and implement an admin alert system
 Implement delay for numerous failed login attempts
 Enforce password length, complexity, and password standards

A08:2021 - Software and Data integrity failures

Software and data integrity failures occur when an attacker can modify or delete data in an
unauthorized manner. This can happen due to vulnerabilities in the software or poor coding practices.
Attackers can exploit these vulnerabilities to gain access to sensitive information or cause damage to
the system.

Impacts of software and data integrity failures

 A hacker gains access to a company’s database and modifies customer records.

 An attacker exploits a vulnerability in a web application to inject malicious code into the
database.
 A malicious insider alters financial records for personal gain.

How to prevent Identification and Authentication Failures

 Implement secure coding practices.

 Conduct regular vulnerability assessments and penetration testing.
 Use encryption to protect sensitive data in transit and at rest.
 Implement access controls to restrict unauthorized access to sensitive data.

A09: 2021 - Security Logging and Monitoring Failures

25
 Course Code/Title:CS2602 / Software Testing Unit: V

Security logging involves recording events that occur in an application or system. This includes user
activity, system events, errors, and other relevant information. Monitoring involves analyzing these
logs to detect potential security threats or issues.

Impacts of Security Logging and Monitoring Failures

 Inability To Detect Attacks: Without proper monitoring tools in place, attacks may go
unnoticed until significant damage has already been done.
 Lack Of Visibility: Without adequate logs being recorded, it can be difficult for organizations
to understand what happened during an attack.
 Inability To Respond Quickly: If an organization does not have real-time visibility into their
systems’ activities through log analysis tools like SIEMs (Security Information Event
Management), they may not be able to respond quickly enough to prevent further damage.
 Non-Compliance: Many compliance regulations require organizations to maintain logs for
auditing purposes. Failure to comply with these regulations can result in significant fines or legal
consequences.

How to prevent Security Logging and Monitoring Failures

 Implementing A SIEM: A Security Information Event Management (SIEM) system is a tool

that collects and analyzes log data from various sources. It provides real-time visibility into an
organization’s systems, allowing them to detect potential threats quickly.
 Maintaining Logs: Organizations should ensure that logs are maintained for an appropriate
amount of time and are easily accessible when needed.
 Regularly Reviewing Logs: Regularly reviewing logs can help identify potential issues
before they become significant problems. This includes analyzing user activity, system events,
errors, and other relevant information.
 Incorporating Automated Alerts: Automated alerts can notify security teams when specific
events occur in the system or application. This allows them to respond quickly before any
significant damage is done.

A10: 2021 - Server Side Request Forgery (SSRF)

Server Side Request Forgery (SSRF) is a type of vulnerability that allows an attacker to send requests
from the server to other internal or external systems. This can be done by manipulating input
parameters such as URLs, IP addresses, and ports.

Impacts of Server Side Request Forgery

 An attacker could use SSRF to bypass authentication mechanisms by accessing internal APIs.
 An attacker could use SSRF to scan internal networks for vulnerable services.
 An attacker could use SSRF to launch attacks against third-party services.

How to prevent Server Side Request Forgery

 Avoid using user-supplied input in URLs or IP addresses.

 Use whitelisting to restrict the URLs and IP addresses that can be accessed.
 Implement input validation to ensure that only valid URLs and IP addresses are accepted.
 Monitor network traffic for suspicious activity.

26
 Course Code/Title:CS2602 / Software Testing Unit: V

Security testing tools: OWASP ZAP, BurpSuite

We have various security testing tools available in the market, which are as follows: SonarQube,
OWASP ZAP, Netsparker, Arachni, BurpSuite.

OWASP ZAP:
ZAP provides installers for Linux, Mac OS/X, and Windows download from URL [Link]
and install ZAP for the system to perform penetration testing [Link] are the requirements for ZAP and
each installer:

 ZAP requires Java 8+ to run.

 The Mac OS/X installer comes with Java 8+.
 Linux, Windows, and the various cross-platform versions require installing Java 8+
separately.
 Docker versions do not require installing Java at all.
Determine whether to persist the session

After installing ZAP, specify whether need to persist this ZAP session. ZAP sessions are recorded by
default to the disk in an HSQLDB database that gets a default location and name. If selected as not to
persist a session, the files are deleted once you exit [Link] decided to persist this session, all session
information is saved within the local database. ZAP lets you provide custom locations and names for
saving the [Link] that can access the database later.

Key components of the desktop user interface (UI)

ZAP’s desktop UI is composed of the following elements:

1. Menu Bar—lets you access ZAP’s manual and automated tools.

2. Toolbar—provides easy access to commonly used ZAP features.
3. Tree Window—displays the Scripts tree and Sites tree.
4. Workspace Window—displays responses, scripts, and requests and lets you edit them.
5. Information Window—displays the details of manual and automated tools.
6. Footer – displays a summary of all alerts and the status of all main automated tools.

27
 Course Code/Title:CS2602 / Software Testing Unit: V

Using the Quick Start tab

The Quick Start tab is an add-on included with your ZAP installation, which can help you get started
with ZAP. Here is how you can run a Quick Start Automated Scan:

Start ZAP, go to the Workspace Window, select the Quick Start tab, and choose the big Automated
Scan button.

1. Go to the URL to attack text box, enter the full URL of the web application you intend to
attack, and then click the Attack button.

How ZAP attacks work

After clicking the Attack button, ZAP starts crawling the web application with its spider, passively
scanning each page it finds. Next, ZAP uses the active scanner to attack all discovered pages,
parameters, and functionality.

ZAP includes two spiders that can crawl web applications. The key differences between the spiders:

 A traditional ZAP spider—this spider discovers links by examining the HTML in responses
from a web app. It is fast but not always effective when you want to explore AJAX web
applications that generate links using JavaScript.
 ZAP’s AJAX spider—this spider is for AJAX applications. It explores a web application by
invoking browsers, which then follow all the links that were generated. It is slower than the
traditional spider and requires extra configuration when using it in a “headless” environment.
Passive vs. active scanning

ZAP passively scans all responses and requests that are proxied through it. This type of scanning does
not change responses, which is why it is generally considered safe. The scanning is performed in a
background thread so as not to slow down exploration. Use passive scanning to find certain
vulnerabilities, get a sense of the basic security state of the tested web application, and find locations
requiring further investigation.
ZAP’s active scanning functionality attempts to identify more vulnerabilities. It works using known
attacks against the targets. Note that active scanning launches a real attack on the target and might put
the target at risk. You should only use active scanning against targets that have given you explicit
permission to conduct penetration testing.

28
 Course Code/Title:CS2602 / Software Testing Unit: V

Burp suite :

Burp Suite is one of the most popular security testing tool. Burp Suite can be used to identify different
types of vulnerabilities, such as SQL injection or cross-site scripting, by testing the web application
beyond its graphical user interface (GUI). It is a type of proxy server, which means it sits between the
user’s web browser and the web server to observe and manipulate all the data that is being sent back and
forth.
Burp Suite has different features such as proxy, Repeater, intruder, scanner, decoder, and more.

 Proxy: Burp Suite’s proxy function allows users to intercept and modify HTTP requests
between a user’s web browser and the web server. This allows for the observation and manipulation
of web traffic, which can help identify potential security issues.

 Repeater: Burp Suite Repeater lets us grab a request, change it however we want, and send it
again and again. This can be super useful, especially when we have to guess a payload by trying
different things (like in SQLi) or when we want to see if an endpoint has any bugs.

 Intruder: Burp Suite’s intruder feature contains several different attacks that can be performed
on a remote website. These attacks include dictionary attacks and brute force attacks, which can
help identify vulnerabilities in the web application’s authentication mechanisms.

 Scanner: Burp Suite’s scanner function allows users to scan a particular website for potential
vulnerabilities. This feature automates the testing process and provides detailed reports on any
vulnerabilities that are found.

 Decoder: Burp Suite’s decoder function allows users to decode different types of data, such as
URL encoding. This can help identify potential security issues in the web application’s handling of
data.
When to use Burp suite?
Hackers are always looking for ways to intercept calls so make sure hackers won’t be able to intercept
the calls.
Why to use Burp suite?
 Ensure that app/web applications are secure and reliable.
 By using the burp suite we can check the vulnerability of websites and applications.
Downloading and Setting Up Burp Suite on Windows
1. Go to the Burp Suite website and download the installer.
2. Run the installer and follow the prompts to complete the installation process, select “new
temporary project”, followed by “use burp defaults”
3. Click on Start Burp

Create temporary project on Burp Suite Community edition

29
 Course Code/Title:CS2602 / Software Testing Unit: V

Configuring Burp Suite

1. Set up the Proxy: In order to intercept traffic, you need to configure the proxy settings in Burp
Suite.
Go to the “Proxy” tab, then click on the sub-tab “Options/Proxy Setting”

30
 Course Code/Title:CS2602 / Software Testing Unit: V

2. You should see an entry in the table with a ticked Checkbox in the Running column, and
“[Link]:8080” showing in the Interface column.

By default Burp Suite runs on port 8080

3. You can modify this setting for it to listen to other ports by just clicking on the “Edit”, button and
changing the port number of the listener to a different number.

31
 Course Code/Title:CS2602 / Software Testing Unit: V

4. Go to the Proxy > Intercept tab and Click the Intercept is off button, so it toggles to Intercept is
on. This toggle allows you to intercept any request or response, and modify it before forwarding it.

Ensure intercept is turned on

Configuring browser
To use Burp Suite as a proxy, need to configure the browser. The process varies depending on the
browser using Firefox. Open Firefox in the top right corner and go to Settings and then search for the
word proxy. Click on the icon to open proxy settings.

32
 Course Code/Title:CS2602 / Software Testing Unit: V

Setting up a proxy server for Firefox

To configure your host computer, open the relevant configuration options and select ‘Manual proxy
configuration.’ Enter the same HTTP Proxy and Port number as entered on Burp Suite, and then click
‘OK’ to save the settings.
Now the browser is already setup to use Burp Suite as a proxy which is listening at port 8080. Now you
need to install Burp’s CA cert.
 Go to burp/ or [Link]:8080 in Firefox.
 Click on ‘CA Certificate’ in the top menu bar to download it.

Download Burp’s CA cert

Downloaded Burp Certificate

 The CA cert must be installed in your browser as a trusted root so that the browser will trust the
SSL connections made to Burp Suite.
Go to Firefox > Click on Options from the side menu > Write Certificates in the search field and
then Click on “View Certificates” > Authorities > Import.

33
 Course Code/Title:CS2602 / Software Testing Unit: V

Once the Burp’s CA cert is installed you should have no problem using Burp Suite as an interceptor. At
Firefox, try to browse to [Link] and can not see any security warning.
At Burp Suite, when the interceptor is turned on, can see all the requests made by the browser. So can
analyze the requests and make any modifications. Then click on the Forward button to send the message.

Intercepting a request

34
 Course Code/Title:CS2602 / Software Testing Unit: V

You can also click on the HTTP History tab to view the list of request history.

HTTP request history

35