What is Software Testing?

➔ Testing the software application which is being developed based on the client's
requirements
➔ In other words, Validating the application whether the developed software meets client
requirements
➔ Example: The company develops an eCommerce application like Flipkart and
establishes the testing of whether users can place the order successfully by using that
application. Here, the testing role is confirming the functionality of an application is
working fine

Why do we require Software Testing?

➔ To find whether the application has any programming and logic errors
➔ To confirm whether an application meets the client's expectation
➔ Developed Applications should be competitive in the market
➔ To keep the existing customers
➔ To form new customers
➔ Everything is incomplete without testing
➔ Example: The company develops an eCommerce site without testing and deploying the
application to customer usage. When a customer tries to place an order if it fails then the
business gets lost. Now, you can understand the importance of software testing

Difference between Verification and Validation in Software testing:

Verification Validation

Checks whether the product is built as per the Checks whether the product is fit for use and
specified requirement and design satisfies the business needs after product
specification while developing a product development completes

An example includes Inspections, reviews, An example includes all types of testing like
and walkthroughs of the Business Smoke, Sanity, Regression, System, and UAT
requirement documents, Design documents,
etc.

Verification happens in each phase of the Validation happens in during or end of each
development cycle phase of the development cycle

Checks "Are we building the product right"? Checks "Are we building the right product?

Verification is also known as Static Testing Validation is also known as dynamic testing

Here, the Execution of code does not happen Here, the Execution of code happens

It comes before validation It comes after verification

 Real-time example: Reviewing the features Real-time example: Validating the features
of a motor vehicle that are present in the of the motor vehicle are working fine by
showroom before the test drive driving it

When to Start Testing?

➔ In the Software development life cycle(SDLC), testing can be started in the requirement
phase and continue till the software deployment
➔ It also depends on the SDLC Model that is being used. For example, in the waterfall
model testing starts in the testing Phase. In the Agile model, the test starts for each
sprint by reviewing the BRD, reviewing the design document, and writing the test cases
➔ Testing can start at an early stage so it reduces the cost and time to rework and can be
delivered the product at the right time
➔ Testing performed by developers after the completion of codes is also categorized as
testing.

When to Stop Testing?

➔ IIt’s very difficult to decide when to stop testing

➔ We can’t say 100% software tested since testing is a never-ending process.
➔ Some of the aspects are there to stop the testing process such as
◆ Based on Testing Deadlines
◆ Completion of test case execution
◆ Based on Functional and code coverage completion
◆ No high-priority bugs are identified and if the defect percentage is less than some
certain level

What is the Software development life cycle(SDLC)?

➔ SDLC is a process to develop the quality software

➔ SDLC includes the various activities in each phase such as Analysis, design, creation,
testing, and Maintenance
➔ Each resource starts its activity at an early phase of development to create high-quality
software or product

They are 6 Phases in the Software development life cycle(SDLC)

Requirement
Design
Coding/Development
Testing
Deployment
Maintenance

1
Requirement Phase

➔ Gathering all kinds of client requirements and specifications based on Modules(Example:

Cart and Checkout Module)/Components(Example: Ratings & Reviews about a product)
/Platforms(Example: Web & Mobile Application)
➔ Business Analysts or Project Managers are responsible for gathering all the
requirements from the client and maintenance in documents. That requirement
documents have to get approval from the Client
➔ Documents may vary from one company to another. For Example: Business
Requirement document(BRD) or Software Requirement Specification(SRS) or Functional
Requirement document etc.,
➔ Also, we can know who are the primary users of the application from the documents.
Example: For an eCommerce site, Business to Business(B2B) companies are users,
Business to Customers(B2C) are users, Admin, and Non-Admin Users

Design Phase

➔ In this phase, a senior developer or architect will make a design of software as per logic
based on client requirements by referring to the documents
➔ The design team supports making mockup screens in a wireframe which is a schematic
or blueprint that describes the structure and functionality flow of the software.
➔ This wireframe is shared with the developer which works as input for the developer in the
coding phase and it is also an input for the testing to make test plans and test cases.
➔ There are some tools to create interactive mockups for the designs. For example,
InVision, etc.,

Coding/Development Phase

➔ This is an important phase in the development life cycle where we build software and
write code for the product
➔ Front-end and Backend developers are primarily responsible to develop the software
according to the design and according to the client requirements discussed in the
previous phases
➔ Front-end developers develop attractive GUI and necessary interface to interact with
back-end operations and Back-end developers do back-end coding according to the
required operations

Testing Phase

➔ In this phase after getting deployed in a testing environment with Frontend and Backend
code then the testing team starts to test.

2
 ➔ Testing determines whether all the functionality is working fine in the software as per
client requirements mentioned in the requirement phase
➔ When there are defects in the application the testing team raises a bug in any tools the
company has like Jira, Bugzilla, etc., or an Excel sheet explaining the scenario or test
case and test steps.
➔ The developer will fix the issues if they reproduce them, then the tester retests the fixed
issues. This process goes on until the build is stable

Deployment

➔ Once testing is done successfully without any issues. If any known issues are there and
if it does not affect the current functionality that issue will be fixed in the next version
➔ The next phase is a deployment where deploy the stable build to production by
deployment engineers
➔ Once an application for using the customer starts to use the application

Maintenance

➔ When customers come across any issues in production like functionality not working as
expected, GUI is not user-friendly, performance issues for example Response from the
server gets delayed when more number of users access the application, security issues,
for example, unauthorized user access the application
➔ If issues are high severity then the development team will fix the issue as a high priority
and redeploy the fixed issue in production. When an issue is a low severity that issue
gets fixed and release in the next version
➔ This Maintenance phase is a prolonged process, which never ends in the software
development life cycle until the software in the usage
➔ During the Maintenance phase, customers may request any other new or additional
features for the application such case that requirement will be added to the Business
document

What is the Software testing life cycle(STLC)?

➔ The Software testing life cycle is a process of software testing that takes place in
different phases to ensure delivering the high-quality product
➔ In each phase, a specific activity takes place to ensure that the quality goals are met in
the testing life cycle
➔ We have Entry and Exit Criteria for each phase in STLC

Entry Criteria: For each phase set of conditions to be satisfied before starts the testing

Examples:

3
 ➔ Test Plan - This Test plan document should be completed before starting testing.
It’s a document that includes the scope, and approach and points out a software
testing effort
➔ Test Strategy - The testing approach should be finalized before starting testing.
It’s a set of directions that explain the test design and figure it how testing needs
to be done
➔ Test case and Test Data - Test cases with Test data should be ready for
execution
➔ Test Tools - Identifying the testing tools wherever it’s necessary for testing
➔ Test Environment - Identify the Environment where the testers going to execute
the test cases

Exit Criteria: For each phase set of conditions to be satisfied before testing comes to a
conclusion

Examples:
➔ Complete execution of all scenarios and test cases
➔ Meets the sufficient coverage requirements and functionalities
➔ Should not have critical, show stopper and high priority bugs when testing comes to the
conclusion

They are the following 6 different Phases in STLC

Requirement Analysis
Test Planning
Test Case Development
Environment Setup
Test Case Execution
Test Cycle closure

Requirement Analysis

➔ In this Phase, testers walk through the requirement documents developed in the
requirement phase of SDLC.
➔ While reviewing the documents, the tester should understand the objective and scope of
the software

Entry and Exit Criteria Activities Deliverables

Entry Criteria: ● Prepare the list of all ● List all the necessary
● Planning of test plan requirements and questions, tests for testable
requirement specification and get clarified from the requirements and Test
environment details

4
 and acceptance criteria Business analyst and the ● Search the Automation
should be available client feasibility(if needed)
● Preparing the Application ● Identify the types of testing to
architecture document be performed
● Identify the Risk
Exit Criteria: ● Identify the Test environment
● The requirement where the testing to be
Traceability matrix performed
should be approved by
the client
● And signed off the test
automation feasibility

Test Planning

➔ In this Phase, the Test Manager or Lead prepares the test plan and test strategy
documents
➔ The Test plan will be having the testing approach for both functional and non-functional
testing.
➔ The Test Plan gets prepared and finalized in the same phase

Entry and Exit Criteria Activities Deliverables

Entry Criteria: ● Defining the scope of the ● Test Plan and Test
● The requirement software strategy documents
document should be ● Identify the testing approach ● Test estimation
available ● Identify the feature to be documents get ready for
tested and not to be tested deliverables in this phase
Exit Criteria: ● Team formation
● The test plan document ● Test estimation
should get approved by ● Determine which tools
the Project Manager and needed for testing
by the client ● Determine the role and
responsibilities of the team

Test Case Development

➔ In this phase, the tester identifies the test scenarios, Test case/Test scripts(for
automation), and Test data based on Requirement documents
➔ The prepared Test cases will be reviewed by Team Member/Team Lead/Business
Analyst and the Client(If Test Case needs approval from the Client)

5
 Entry and Exit Criteria Activities Deliverables

Entry Criteria: ● Obtain Test Scenarios ● Test cases

● Requirement ● Create the Test cases from ● Test Data
Documents, RTM, and Test Scenarios ● Expected Results for
each test case
Test plan ● Prepare Test Scripts for
● Test Scripts for
● Automation analysis automation(Optional) automation if required
report ● Identify the Test data, then
Exit Criteria: create it
● Reviews Test cases/Test ● Mention the Expected result
Scripts(if automation) for each test case
and Test data ● Review the Test case by a
Business analyst
● Map Test cases with
requirements in RTM

Environment Setup

➔ Environment setup needs a group of essential software and hardware to set the
environment for testing
➔ The testing team won’t be involved in the environment setup if the development team
provides the test Environment.
➔ Testing environment configuration mostly as same as the production environment
➔ Confirming the testing environment whether it’s in ready status by executing the smoke
testing

Entry and Exit Criteria Activities Deliverables

Entry Criteria: ● Compose the list of software ● Smoke Test execution

● System design and hardware by analyzing report to ensure the Test
documents, Architectural the requirements documents environment is ready for
further testing in the
documents of the ● Ensure the test environment
same environment
application, and is ready by executing the ● Defect Report
environment setup smoke test
checklist
● Furnishing of Test Plan,
Preparedness of smoke
test cases, and
Arrangement of test data
Exit Criteria:
● Test Environment should
be in ready status

6
 ● Smoke should be
performed successfully
in the given environment

Test Case Execution

➔ This is the Key phase of the STLC, Test cases are executed in the corresponding
environment
➔ While execution tester may find defects and can raise it accordingly
➔ The developer fixes the issue and the tester retest the fixed defects to confirm defects
working fine as expected

Entry and Exit Criteria Activities Deliverables

Entry Criteria: ● Test case execution ● Test case execution

● Requirement Document ● Update the execution results results
& Test Plan ● Raise the bug in the ● Bug Report with an
explanation of the
● Test Case document, corresponding defect
Defects
Test data, and Test management tool
Environment ● Map the Test cases with the
Exit Criteria: requirements
● Test case execution ● Retest the fixed bug
Report
● Bug Report with Ticket
number
● Test coverage
Documents(RTM)

Test Cycle closure

➔ This Test Cycle closure contains Requirements, Design, Development related

documents & Test case documents along with test and defect reports

Entry and Exit Criteria Activities Deliverables

Entry Criteria: ● Estimate the Test cycle ● Test Closure report

● All testing documents completion criteria based on
related to software Time, Test Coverage, Cost,

7
 ● Opened and Closed Bug Critical Business objectives
reports & Quality
Exit Criteria: ● Prepare the test Metrics
● Test closure report ● Make the documents what
signed off by client and are the things learned from
Test Metrics the project
● Prepare the test closure
report
● Segregate the defects by
Severity and Priority from the
test result

Roles and Responsibility of Tester

Understanding the requirement

➔ The tester needs to review the documents and understand the requirements before
starting the preparation of test cases
Example: Walkthrough the Business requirements document(BRD),System
requirements document(SRD),Functional requirements document(FRD) etc.

Go through the test plan

➔ Needs to walk through the test plan documents to know about strategies for testing, test
approaches, testing tools going to use for testing, and so on
Example: Most of these details will be in the test Plan 1) Types of testing going to use
for testing 2) Details of entry and exit criteria 3) Details of Features to be tested and not
to be tested 4) List of testing tools going to use for testing and so on

Preparation of test cases

➔ Before executing the test cases, list the test scenarios and test cases with test steps &
expected results upon the requirement documents
Example: Writing the test cases for login scenarios, cart pages, checkout page
scenarios for eCommerce domain, test cases for forgot password scenarios, and so on

Review the test cases with Team lead or Business analyst

➔ Walkthrough the prepared test cases with a superior of the testing team or Business
analyst
Example: Once completed the test cases, before forwarding to the client testing team
superior like the Senior tester, Test lead, Test manager, or business analyst for that
project needs to review

Executing the assigned test cases

➔ Perform the testing upon the test cases and raise the defects in the bug tracking tool

8
 Example: Assume an eCommerce domain, below modules are allocated to persons for
execution.
● Person A: Assign login for an existing user, sign up for the new user, and forgot
password test cases
● Person B: Seller and User(Buyer) login-related test cases
● Person C: Product details and placing the order by the user and so on

Preparation of defect report

➔ Tickets raised while testing by testers list those raised defects and address to the
development team
Example: Below are a few examples for defects
● No error message for password character limitation in the login
● For forgot password mail is not receiving to mail id
● Customer(buyer) not able to place multiple products

Re-test the software

➔ After fixing the defect retest the issue and close it if it’s working fine else reopen the
ticket
Example:
● Verify error message is displaying or not when the password character is beyond
the limit
● Verify mail receiving for forgot password to concern mail id

Preparation of test report

➔ Prepare the test report with Actual results & test results
Example: Have to update execution status like pass, fail if issues not yet fixed, not
implemented, pending, and so on

SDLC Models

Some of the important SDLC Models mentioned below.

Waterfall Model
V Model
Agile Model
Spiral Model

Waterfall Model

➔ Waterfall Model is the base model in SDLC and it’s simple to understand and use it
➔ In this Model, phase execution happens in sequential order(One by One) which means
the outcome of one phase would be the input of the next phase. Therefore, this model is
also known as the Linear sequential life cycle model

9
 ➔ In this phase, can avoid overlapping issues between the phases since each phase must
be completed before the next phase starts
➔ Each phase deliverables utilizes in the next phase for example requirements documents
used in the design phase, design documents used in the development, etc.
➔ Example: In the Requirement stage outcomes are BRD/SRD/FRD, this outcome moves
to the Design phase as Input, this design outcome moves to the development phase to
develop the software, then this outcome moves to the testing phase to test the software

The waterfall model has various stages which happens in below sequential

Requirement Gathering
System Requirements
Design
Coding
Testing
Release and Maintenance

Let’s see in the detail

Requirement Gathering:

➔ In this first phase, the Business team gathers all business needs from the client to
develop the software and make it in the form of requirement documents(For
Example:Business Requirement Documents(BRD))
➔ This documents should contains business needs clearly which means specification of
the input and output of the product

System Requirements:

➔ In this phase, Business requirements converts into the System requirements

➔ It carries all functionality specification information

Design:

➔ In this phase, will create the overall application architecture based on system
requirements document
➔ Also, creates the application module flow as happy and unhappy scenarios by flow chart,
flow diagram etc.

Coding:

➔ Once design is completed, the next developer starts to write the code to develop the
application in a specific programming language if the client requested.

10
 ➔ Otherwise they use the Industry standard programming language such as Javascript,
Python, Java, C#, C++ and so on
➔ The 2 different development team will be there for the project one is Frontend who
develops the GUI and other one is Backend who develops the API’s based on
requirements
➔ Design team also involves in this phase to present the application attractively

Testing:

➔ Here, testing team starts to execute the test cases on the application based on client
requirements
➔ If they found any defects will raise it to development team
➔ Once issue is fixed, tester do retest the defect to confirm that issue is working fine

Release and Maintenance:

➔ Once the Functional and Non-functional testing is done then deploy the application in
production environment after client approval
➔ Once deployed the application successfully in respective environment, if users gets any
unexpected results or facing any problem while using the application then client will
address to project manager or business analyst to fix the issue by development team
➔ If client request any changes in the application that also will be taken care in the
Maintenance phase

Advantages of waterfall model:

➔ In this model, can do the phases one by one to develop the product
➔ Can keep the deadline for each phase to complete their process
➔ This waterfall model is easy to understand and easy to use
➔ This model is suitable for smaller project where the requirements is less

Disadvantages of Waterfall Model:

➔ In this Model, cannot do the phases in parallel

➔ Estimation of time and cost for each is difficult in this Model
➔ Here, we cannot do the changes in the application when the process in testing phase
➔ This model is not suitable for Complicate and Object Oriented Projects
➔ If requirements need to change in the middle of the process which is not acceptable in
this model that creates the higher risk of changing the requirements

When to use the waterfall Model?

11
For smaller projects
If Project requirements is stable
Technology is understood
There are no Inexplicit requirements

V-Model:

➔ This Model overcomes the drawback of the Waterfall Model and in this model testing
start in requirement stage itself
➔ In this V Model, all development phases can be integrated with testing phase
➔ Verifying the testing documents such as Test Plan, Test case and so on by reviewing and
discussing for feedback
➔ Validating the developed software by testing it based on the client requirements
➔ This model also called as V and V Model which stands for Verification and Validation
Model
➔ Here, process happens in the sequential order which means next phase started once
previous phase completed

V-Model

12
Elaborating about the integration of Development and Testing Phases

User Requirements Vs Acceptance Testing

➔ In this stage, doing the verification process in user requirements phase and doing the
validation process in Acceptance Testing
➔ Business Analyst gather the requirements from the client and document it
➔ Business Analyst review the documents with client and get the approval from them for
further process
➔ Testers gather Acceptance test cases from requirement document

System Design Vs System Testing

➔ Development Manager/Technical manager converts the user requirements to

System/Software requirements
➔ Verifying the Software requirements document with project manager like reviewing it and
get the approval from them
➔ Tester create the test cases from Software requirements document in order to perform
the system testing

Architecture Design Vs Integration Testing

13
 ➔ Senior Developer creates architecture and design for the application
➔ It provides overview of solution, platform, system, product and service/process
➔ Normally more than one technical approach is proposed based on the technical and
financial feasibility then final decision will be taken
➔ Developer perform integration testing based on application architecture

Module Design Vs Unit Testing

➔ In this Module design phase, clear application components are designed. It defines the
actual logic for each and every component of the system
➔ Components can be divided into small units or module and explain to each of them so
programmer starts coding directly
➔ Verify that design is compatible with other modules in the system architecture and other
external system
➔ Developer perform the unit testing based on application modules once development
completed

Advantages of V-Model:

➔ In this Model, Tester role starts in the requirements phase itself

➔ Many stage of testing available therefore defects can be reduced in this model
➔ Due to multiple stage of testing and multiple teams involvements so quality can be
improved
➔ The phases are completed one at time and it’s a highly disciplined model
➔ Each phase has specific outcomes and a review process
➔ This model is simple and easy to understand and use
➔ Testing activities like planning, test case design happens before starts coding so time
gets save

Disadvantages of V-Model:

➔ It’s expensive model than waterfall model, needs a lot of resources, expensive budget
and need more time
➔ Coordination and maintenance are difficult
➔ Adding new requirements and changing in the existing requirements at middle of the
process are difficult
➔ Here, we need to do more documentation work like preparing the test cases and all other
documents
➔ The V model is not suitable for object oriented projects
➔ We cannot go back and replace the functionality when the application in the testing
stage

Agile Model:

14
➔ Initially the Waterfall model was popular in the software industry to develop the software.
➔ The Main difficulties for developer is handling the changes when customer requesting to
change in requirements at the mid of development and probably developers needs a
time to complete those changes
➔ To overcome the drawback of waterfall model, they brought Agile software development
model
➔ The Agile model is primarily designed to complete the change request quickly. Also, by
utilizing this model can complete the project as soon
➔ In the Agile model, the customer requirements are break down into many small parts to
develop the application incrementally so it adopts the iterative development
➔ Agile model is combination of Incremental and Iterative process Model
➔ For each incremental part less number of components or features comes for
development which goes in an iteration wise. So each iteration have less components to
develop and can be completed in a couple of weeks
➔ At the time one iteration get planned, developed and deployed to the customers
➔ For each iteration time will be there to complete the development and deliver to
customer

The following steps are the agile process of SDLC which is used for each iteration to
develop the software in an incremental way. Activities of each phases are same which
we have seen in Waterfall and V-Model

15
Principles of Agile Model:

➔ To establish close contact with customers during the development and to get clear
understanding of the requirements for each agile project there will be customer
representatives on the team.
➔ At the end of each iteration, the Business analyst and customer representative review
the process and re-evaluate the requirements
➔ Frequently delivery of incremental versions of the software to the customer
representative in intervals of few weeks
➔ Whenever customer request the changes in requirements will get it and efficiently
integrated with the application
➔ In this model, communication with project team members happens whenever required
instead the exchange of the documentation
➔ The Agile development process usually deploys Pair programming that means 2
programmer's work together for the project. They split the works and deliver the modules
before or on deadline

This three Agile methodologies are mostly used in industry:

16
 ➢ Scrum
➢ Feature-driven development
➢ Extreme programming(XP)

Scrum:

➔ Scrum is a most popular methodology which helps to make a high productivity in

developing the software
➔ It is primarily based on Incremental development process model
➔ In scrum method, entire development cycle is divided into a series of iteration where
each iteration is called as Sprint
➔ Scrum is a lightweight software development methodology that focuses on prioritize the
feature and develop it on specified time that says sprint which functionality are
incorporated into an integrated to the application
➔ These are the some of the benefits of agile scrum methodology
● Flexibility and adaptability
● Creativity and innovation
● Lower costs
● Quality Improvement
● Organizational synergy
● Employee satisfaction
● Customer satisfaction

Extreme Programming(XP):

➔ XP is an agile framework that aims to build higher quality software and higher quality of
life for the development team
➔ XP is built upon values,principles and practices
➔ In XP method, mostly concentrate on customer satisfaction and it requires maximum
customer interaction to develop the software
➔ It divides entire software development cycle into several number of short development
cycles
➔ It accepts customer request and integrated changes or requirements at any phase of the
development life cycle
➔ When XP is applicable in Agile methodology
● Dynamically changing software requirements
● Risk caused due to project deadline using new technology
● Small, co-located extended development team
● The technology you are using permits for automated unit and functional tests

17
Feature Driven Development(FDD):

➔ FDD is an agile iterative and incremental model that focussing on the progress of the
feature of developing the software
➔ The main objective of the FDD is to provide the updated and working software to the
client timely. In FDD,reporting and progress tracking required at all levels
➔ The following are the 5 stages of FDD life cycle
● Build an overall model -> Domain Model than content
● Build a features list -> A list of feature
● Plan by feature -> Assigning the features to developers
● Design by feature -> Adding content to Model
● Build by feature -> Inspection by client

Advantages of Agile Model:

➔ Can adopt the changes in the mid of software development since development in
iteration wise
➔ An error can be reduced in this model since development in incremental model
➔ Able to deliver the one part of developed software to customer at the earliest
➔ A whole project development time also can be reduced
➔ Customer representative keeps in follow up with business analyst to track the
development status
➔ At the end of the project can deliver the software with high quality to customer in this
model

Disadvantages of Agile Model:

➔ Document works more in this model
➔ This Model is more helpful for management than developer
➔ The senior manager or delivery manager are in better position to take decision in the
agile model
➔ Difficult to manage when a team gets large
➔ If the project is large then difficult to judge the effort and time required for the project in
software development cycle

Spiral Model:
➔ Spiral Model is a combination of Iterative Development Model and Waterfall Model
➔ Spiral Model provides a support for handling the Risk in the project
➔ In this model, develop the application module by module and deliver to the customer so
that customer start the application at the early stage
➔ This Model is best used for medium and large projects since continuous enhancement
involvement in the project
➔ In this Model, develop the application in phases because sometimes the client provides
the requirements or changes in between the process.

18
 ➔ This model is favored for expensive and complicated projects. Its a circular view of
software life cycle

The different phases of the spiral model are as follows:

Requirement Gathering
Design
Coding
Testing and Risk Analysis

Requirement Gathering:
➔ Document the all kind of gathered Requirements like system, unit and subsystem needs
from the customer and identify the objectives of the project
➔ It includes estimation of cost,schedule and resource for the spiral
➔ In this stage, easily can understand business requirements since business analyst and
client have stable communication

Design:
➔ In the second stage of the spiral model, where we design the architecture of the
application, logical diagram, flow charts, decision tree etc.

Coding:
➔ In this coding stage, develop the application as per the client requirements and get the
client feedback after providing the demo for developed module
➔ In Each iteration the developed modules are built with different version numbers.
➔ Whatever Modules Developed in each iteration that builds deliver to customer for their
responses

Testing and Risk Analysis:

➔ Next stage is testing the deployed build in the QA environment and also analyze the risk
of the software on different aspects such as managing risks, detecting and observing the
technical feasibility
➔ Once testing completed with all fixes, deliver the build to customer for their testing and
they give their feedback

Risk Handling in Spiral model:

➔ A risk in the project may affect the successful completion of the project
➔ The most important feature of the spiral model is handling the unknown risk after
the project starts. Such risk resolutions are easily done by developing a prototype

19
 ➔ The Prototype model helps to handle the risk in the project. But,that risk will be
identified completely before starts the development work
➔ We cannot use the prototype model after development work started.
➔ In each phase of the spiral model, the modules of the product dated and
analyzed that time risk will be identified and resolved by prototype model

Advantages of Spiral Model:

➔ Flexible changes are allowed in spiral model

➔ The development can be distributed into smaller parts and more risky parts can be
developed at the early stage which helps better risk management
➔ The customer can use at the early stage and they can provide any changes needed on
the requirements that will implemented faster
➔ More clarity for developers and testers
➔ Cost estimation becomes easy as prototype building is done in small segments

Disadvantages of Spiral Model:

➔ It is not suitable for the small and low-risk product since it’s costly for smaller project
➔ Risk analysis is an important phase so it requires expert people for risk assessment
➔ There is no requirement of review process and no parallel deliverables allowed in the
spiral model
➔ In the spiral model, management is a bit difficult, that’s why it is a complex process
➔ The maximum number of intermediate phases needs unnecessary paperwork since
more number of phases in this model estimating the time also is very difficult

When the spiral model should be followed:

➔ For Medium and big projects
➔ For high risk projects
➔ Whenever requirements are complex
➔ Users are unsure of their needs
➔ If the requirements are more complicated
➔ If frequent changes required in the projects

20
Types of Software Testing

The software testing mainly divided into two parts which are mentioned below:

❖ Manual Testing
❖ Automation Testing

What is Manual Testing?

➔ Manual testing is testing the application by executing the test cases manually, not testing
by automation testing tool
➔ It’s performed to find any bugs in the application under development
➔ In Manual testing, the testers checks all the features of the given application without
using any automation tools
➔ Example: Execute the Login scenario like positive and negative test cases by manually
upon the prepared test cases

What is Automation Testing?

➔ In Automation testing, tester write the code or test scripts to automate test execution
➔ Here, Testers use appropriate automation tools to re-run the test scenarios whenever
needed testing to reduce the execution time
➔ The goal of automation testing to complete the test quickly
➔ Reuse the developed test scripts for regression test which runs automatically to compare
actual result with the expected result
➔ Even though all process are performed automatically, automation requires human effort
to prepare and update the test scripts
➔ Example: Prepare the test scripts for one full flow like Login,select the product and buy
the product by automation tool and execute the script

Important difference between Manual and Automation testing

Manual Testing Automation Testing

Manual Testing is done manually by test Automation testing is done with use of
engineer script,code and automation tools by a test
engineer

Manual testing process is not accurate Automation process is well grounded

because possibility of human errors because it is code and script based

In Manual testing takes some time to In Automation testing can complete the test
complete the test very fast compared to manual testing

21
 For manual testing, programming knowledge For automation testing, programming
is not needed knowledge is needed

In manual testing allows random testing In Automation testing does not allow random
testing

Classification of Manual Testing

The following three different types of testing categorized in the manual Testing

❖ White Box Testing

❖ Black Box Testing
❖ Gray Box Testing

Let’s see those types of testing briefly here

White Box Testing:

➔ It is done by the developer
➔ It is used to test the internal logic (coding) of the module which is working fine before
moving that module codes to testing team
➔ The purpose of implementing the white box testing is to point out the flow of Inputs and
Outputs over the software, enhancing the security of an application and improving the
design and usability
➔ White box testing is also known as Open box testing,Glass box testing, Structural
testing, Clear box testing and Transparent box testing
➔ Unit Testing is comes under white box testing which is done by the developer

Black Box Testing:

➔ It is done by the tester. The Testing is done without knowing the internal codes and
Structure of the program
➔ It is used to test the functional aspects of the application
➔ In this testing, tester execute the test from the customer’s point of view, identify the
defects and address the defects to the development team
➔ Developer will fix those defects and does one round of white box testing and send it to
the testing team
➔ In Black box testing, tester first focus on Inputs and outputs of software system
➔ It is also called as Functional Testing and Tester called as Black box tester or Functional
tester
➔ Two types of block box testing is Functional Testing and Non Functional testing

22
Gray Box testing:
➔ Gray box testing is a software testing method to test the software application with partial
knowledge of the internal working structure
➔ The purpose of gray box testing is to search and identify the defects due to improper
code structure or improper use of application
➔ It gives the ability to test both the presentation layer as well as internal coding structure.
It’s primary used in integration testing and penetration testing
➔ It is the combination of both white box and black box testing
➔ Example: While testing website feature if tester found font related issues or height &
Width alignment etc then tester can make the changes straightaway in HTML Code and
check those alignment issue as real time

Types of Black box testing

Black box testing are classified into two parts, which are explained below

❖ Functional Testing
❖ Non-Functional Testing

Functional Testing:
➔ The tester will check all the components of the application against requirement
specification known as functional testing. Also, it called as Component testing
➔ In functional testing, execute all the components by providing the input value and define
the output value, then validate the actual with expected value
➔ Validating the functionality of application whether it meets business needs
➔ Functional testing is combination of Unit Testing, System Testing and Integration testing

Non Functional Testing:

➔ Non functional testing provides detailed information of application performance and used
technologies
➔ Validating the performance of the application on which is measuring the scalability of the
Application
➔ Non functional testing will minimize the risk of the application and related costs of the
application
➔ Non functional testing is the combination of the Performance, Load,Stress, Usability and
Compatibility Testing

23
Types of functional testing

Functional testing is also classified into various categories which are mentioned below

❖ Unit Testing
❖ Integration Testing
❖ System Testing
❖ User Acceptance Testing

Unit Testing
➔ Unit Testing is also called Initial level Testing
➔ It’s done by the developer
➔ The aim of the unit testing is to isolate the each point of the code and verify its
correctness
➔ Unit Testing is performed by respective developers on the individual modules of source
code assigned to developers
➔ The developers use test data that is different from the test data of the testing team
➔ It mainly focuses on field level and functional level validation
➔ Developer checks all fields are available in the application

Integration Testing
➔ It is used to test the link or integration among the components of the application
➔ To test the interfaces or communication amongst many modules
➔ Integration testing focuses on checking data communication among the all modules
➔ The Integration testing is individual software modules are integrated logically and tested
as a group
➔ Integrated testing can be done in two ways such as Bottom-up integration testing and
Top-down Integration testing
➔ Bottom-up Integration Testing: This testing starts with unit testing, followed by tests of
progressively higher level combination of units called Modules or builds
➔ Top-down Integration Testing : In this testing, the highest level modules are tested first
and progressively, lower level modules are tested thereafter

System Testing
➔ It is to test the software and the hardware requirements of the application
➔ It test the whole functionality of the application
➔ It test the performance of the system which means system response from server after
request hits to the server

24
 ➔ System testing is the testing of complete and fully integrated software product
➔ The application is tested in an environment that is very close to the production
environment where the application will be deployed. Example: QA Environment/Staging
environment
➔ System testing enable to test,verify and validate the business needs as well as the
application architecture

User Acceptance Testing(UAT)

➔ This is the final stage of testing. It also called as Pilot testing
➔ UAT is a types of testing performed by the client to certify the system is working fine
upon the requirements
➔ This testing happens in the final phase of testing before the application moving to the
market or production environment
➔ The Main objective of this testing is to validate the end to end business flow
➔ It is a kind of black box testing where two or more end-users will be involved

There are two types of UAT

❖ Alpha Testing
❖ Beta Testing

Alpha Testing
➔ Alpha testing is a type of user acceptance testing which it confirms whether the
application functionally working as per requirements and identify the possible issues or
defects before deliver to the end user or public
➔ This testing is performed by internal employees of Software test engineers
➔ The focus of this testing is to simulate the real users by using black box and white box
techniques
➔ The process of Alpha testing is
◆ Review the business requirement documents
◆ Develops the test plan and test case
◆ Execute the testing as per test case
◆ Raise the defects and assign to the developers
◆ Developer fix the defects and tester retest of the defects

Beta Testing
➔ It is done by the different customers
➔ Beta testing of a product is performed by real users of the application in the real
environment and can be considered as a form of external user acceptance testing

25
 ➔ Beta version of the software is released to the limited number of end users to obtain the
feedback of product quality
➔ Beta testing reduces the product failure risks and provides increased quality of the
product through customer validation
➔ Direct feedback from customers is major advantages of beta testing
➔ This helps testing the product in real time environment
➔ For Example: They deploy the beta version and they mention the beta word with version
like WhatsApp for Android Beta 2.22.12.6

Types of Non Functional Testing:

Following testing are the non functional testing:

❖ Performance Testing
❖ Usability Testing
❖ Compatibility Testing

Performance Testing:
➔ In this testing, they capture the performance of application by applying some loads and
will focus on response time, load, throughput and stability of an application
➔ Performance testing contains various types of testing such as
◆ Load Testing: In this testing, we execute the test with some load on the
particular API to validate the application performance. Here, load means request
that could be less than or equal to the requested load by client
Example: Requested load is 100 requests. User hit less than or equal to 100
request and have to find it whether server capacity accepts the 100 requests or it
throwing an error in the response
◆ Stress Testing: In this testing we execute the test with the load beyond the limit
and we observe how the system acts for this load.
Example: Requested load is 20000 requests only. But, here we use more than
20000 Request and will find in which request server throws an error or server
gets crash
◆ Scalability Testing: Here, we inspect the performance of application by
increasing or reducing the load in particular balance is known as scalability
Testing
Example: Here,from time to time Increase the load and decrease the load to find
the performance of the application

26
 ◆ Stability Testing: In this testing, we estimate the application performance by
applying the load for a specific time to find any defects in the application
Example: Hit the 10,000 request in 1 minute and find how is the server
response for this load

Usability Testing:
➔ In Usability Testing, testers examine how user friendly this application is and identify the
issues related to usability problem
➔ Verify how much this application is workable and easy to understand to the end user for
handling the application
➔ Verify the application appearance having pleasant look and confirm the application
making feel to the end user to use it

Compatibility Testing:
➔ In this testing, testers test the application in different operating systems like
Windows,Linux, Mac to confirm the application is working properly in all OS.
➔ Verify the application behavior in various browsers like Chrome, Firefox, IE, Microsoft
Edge, Safari etc. Will raise the defects if any unexpected behavior in any browsers and
developer will fix it
➔ Verify the application with old version of backend codes
➔ Verify how the responsiveness of application with various mobile devices
➔ Verify the application with various network environments

Some Other types of testing

The Following testing are some other types of software testing to evaluate the application
performance
Smoke Testing
Sanity Testing
Retesting
Regression Testing
Database Testing
Exploratory testing
Ad Hoc testing
Security Testing
GUI Testing

Smoke Testing
➔ It test the Major functionality of the application

27
 ➔ Testers focus only the positive scenario of application, not a negative scenario
➔ Main purpose of smoke testing is that delivered build is stable or not for further testing
which is also known as Build verification testing
➔ For smoke testing can filter a test cases from already designed test cases
➔ Smoke testing prefers wherever new builds are deployed in any environment like QA
server, UAT & Production server to confirm no blocker bugs in the new build
➔ Example: In Chat application, additionally they developed video call feature in
application and deployed in QA Server. Initially Tester starts sanity test they do smoke
test to make sure build is stable

Sanity Testing
➔ Sanity Testing performs after deploys the build with new features or fixes defects
➔ Test all new features and dependent feature functionality is working fine
➔ Verify all resolved defects are working fine by fixing this defects that does not affect any
other associated functionality
➔ Once Sanity test is working fine then can starts a regression testing
➔ All the test cases are not covered in Sanity testing
➔ Example: Already your account details options are available in an ecommerce site
which is in production. Additionally they added new features such as Your wishlist,
Payment through UPI and Your Recommendation. Need to test all these features and
dependent functionality of these features also needs to test in the application

Retesting
➔ In Restesting, verify the fixed defects is working fine or not which is raised during the test
execution
➔ Retesting also occurs on specific functionality when client finds a defects on that
functionality
➔ In some cases raised defects can be declined by developer since they have not
reproduce that issue their side such case testers do retest of that bug and make sure
whether that defect is there or not
➔ Sometimes any core features needs to retest to make sure there is no major defects on
that features
➔ Example: In Chat application, testers raised an issue messages are not delivered to all
users when a user sends a message from a group chat. After issue fixed by developer,
the tester do retest to confirm now message are delivered to all users from group

Regression Testing

28
 ➔ Regression testing means repeating a test already run successfully and compare the
new results with the earlier valid results
➔ Verify whether fixed defects does not any impact on the application that has already ran
successfully
➔ Regression testing is confirming that the product works fine with new functionality, bug
fixes or any change in the existing features
➔ Test cases need to execute again and again whenever deploying the new functionality or
changes in the existing features. To avoid test manually, automation testing prefers for
regression testing for time consuming
➔ Example: In Chat application, once sanity test done for video call feature and bug fixes
for message delivery issues. Then, tester starts the regression testing for whole
application to make sure all functionality are working fine

Database Testing:
➔ Database is a collection of data which contains information of the application those are
stored in tables to retrieve the appropriate data whenever it needs
➔ It tests the data integrity that is connection between the backend and the frontend
➔ It tests whether there is any missing or wrong data in the database that is missing
table,column etc.
➔ It tests whether data is store or not and where it is stored
➔ It tests the performance related data
➔ It used to analyze the schema, tables, triggers etc., of the database under test
➔ While doing the database testing, can make sure the database efficiency, maximum
stability, performance and security
➔ To perform the database testing, must have basic knowledge of SQL

Exploratory Testing
➔ For exploratory testing, have to get the application in all possible ways, understanding
the flow of the application from senior test engineers & developers, making a test
document and checking the application working condition
➔ We use the exploratory testing a) When the requirement is missing b) Early Iteration is
required c) If new testers tested the functionality of the application to cross check the
modules or features of the application, verify the same functionality of the application by
experience testers
➔ Types of Exploratory Testing:
◆ Freestyle: In this testing, testers did not follow any rules, there is no maximum
coverage and will do testing like monkey testing

29
 ◆ Strategy based: This exploratory testing carry out with the assistance of multiple
testing techniques such as risk-based, boundary value analysis and equivalence
partitioning will be performed by senior test engineers who has good knowledge
about the application
◆ Scenario based: The Test engineers execute this testing with the help of
multiple scenarios such as end to end scenarios, test scenarios and real user
scenarios

Ad Hoc testing
➔ It test the functionality of the application randomly without any procedures
➔ This test execute when limited time is there for testing
➔ Ad Hoc testing is the form of unstructured testing techniques
➔ Normally, end users utilize the application randomly and find the defects, but test
engineers test the application systematically so they may miss some defects. To avoid
such defects testers who knows very well about the project execute the testing randomly
using error guessing techniques
➔ Therefore, this testing also known as Monkey testing or Random Testing
➔ Example:
◆ In browser compatibility testing, we test the application randomly without
following the test cases in all major browsers
◆ If developer disabled or enabled any software development technology in the
code such case test engineers perform the Ad Hoc testing
◆ If client asking the new build with new features added in the application to test
their side before deploying in production such case test engineers execute the
random testing on the application

Security Testing
➔ It test valid and invalid checking and also checks whether the application should not
allow the unauthorized users
➔ The Primary goal of security testing is to find the weakness, risk and threats in the
software application so that can make sure the security of the application
➔ It is a testing procedure, to ensure the customer whatever data’s passing in the
application are safe
➔ When performing the security testing, need to focus on below mentioned areas in the
application
◆ System Software Security
◆ Network Security
◆ Server Side Application Security

30
 ◆ Client Side Application Security
➔ Types of Security Testing:
◆ Security Scanning
◆ Risk Assessment
◆ Vulnerability Scanning
◆ Penetration Testing
◆ Security Auditing
◆ Ethical Hacking
◆ Posture Assessment
➔ The security testing recommends to perform parallely in each stage of the software
development life cycle

GUI Testing
➔ In this testing, usually use to evaluate the graphical user interface designs of elements or
features in the software application
◆ Text boxes
◆ Font size
◆ Font color
◆ Buttons
◆ Menus
◆ Links
◆ Layout

31
 ◆ Labels
◆ Text Formatting
◆ Lists
◆ Captions
◆ Icons
◆ Content
➔ The Primary goal of the GUI Testing is to validate the features of the software application
performs as per the given requirement/specifications
➔ As per GUI Testing, can decide whether a user will use the application more or not
➔ Users may not use the application again if user not satisfy with interface or unable to
identify the difficulties in order to understand it that’s why GUI Testing is the most
important in software testing
➔ The GUI Testing execution allows us to test the feature of the application from the user
perspective
➔ Sometimes the internal performance of the system works fine, but user interface doesn’t
work that’s why GUI Testing is very good approach in order to test other types of
application as well
➔ Example:
◆ In GUI Testing, checks the appearance of each module of the application are
good, even in different resolutions
◆ It Checks whether the interface is attractive or pleasant or not and whether the
image has good clarity
◆ Verify all kinds of Headings are aligned correctly or not
◆ Verify the spellings,width, height of the elements, elements positions,font colors,
font size, alignment of the images, size of the images, Color of the error
messages, warning messages
◆ Verify Scroll bar is presents or not whenever content is more than the page size
◆ This testing also make sure that user may not get disappoint while using the
system interface

Software Testing Techniques

❖ Boundary Value Analysis(BVA)

❖ Equivalence Class Partitioning
❖ Error Guessing
❖ Decision Table based testing
❖ State Transition
❖ Use case

32
All these Testing techniques can see in detail

Boundary Value Analysis(BVA)

➔ This techniques can be implemented at all test levels such as Unit,Integration,System
and Acceptance testing
➔ Boundary value analysis is a type of black box or specification based testing technique
in which use to test boundary values because higher chance of error occurs where input
values near to boundary
◆ Example: Here, assume password characters field should be between 8 to 16
characters, it accepts alphanumeric & special characters. Developer may miss to
restrict the 8th character and 16th character, therefore lower and upper boundary
values must be tested in this field
➔ This techniques closely associated with equivalence partitioning since we analyze the
behavior of the application with test data residing at the boundary values of the
equivalence classes
➔ Boundary value analysis is based on testing at the boundaries between partitions. It
includes maximum, minimum, inside or outside boundaries, typical values and error
values
◆ Example: Assume same password field with same character restriction (8 to 16
characters). Here, tester use the input data as less than 8 or equal to 8, then
between 9 to 15 characters and equal to 16 character or above and checks the
error message when value is outside to boundary
➔ Whenever we do the testing by boundary value analysis, the tester focus on while
entering boundary value whether the software is producing the correct output or not
➔ Using this testing techniques, can reduce the number of test cases

Equivalence Class Partitioning

➔ This techniques also, can be implemented at any level of testing such as Unit,
Integration,System and Acceptance testing
➔ Equivalence class partitioning is a specific based testing technique in which we group
the input data into logical partitions called equivalent classes
➔ In this technique, input to the software are divided into partitions of valid and invalid
values that all partitions expects to present the same behavior
➔ If a condition of one partition is true then the condition of other equal partition must also
be true (Example: Password characters between 8 & 16 should accepts) and if condition
of one partition is false then the condition of another equal partition must also be
false(Example: Password characters <=7 & >=17 should rejects)

33
 ➔ The equivalent partitions are derived from requirements and specification of the
software.
➔ The advantage of this technique, it helps to reduce the time of testing since it reduces
the number of test cases from infinite to finite.
◆ Example: Assume same password field and same character restrictions it
accepts between 8 to 16 characters

Invalid Test Valid Test case Valid Test Case Valid Test Case Invalid Test
case Case

Characters <=7 Characters = 8 Characters = 11 Characters = 16 Characters >=

17

abcd345 xxxx123@ xxxxx123456 1234567890xxx 1234567890abc

@xx d$xx

In this example, we used both equivalence partitioning and boundary value analysis
techniques to reduce the number of test case from infinite to 5 Test cases

Error Guessing
➔ Error Guessing is a technique in which there is no specific procedure to identify the error
in the application
➔ In this techniques, every test engineer will take the values or inputs based on their
understanding of the requirements and they do not follow any kind of rules to perform
this technique
➔ It’s based on product knowledge and testing experience of the person who can guess
the problematic areas of the software which helps to save a lot of time.
➔ The implementation of this technique is depend on experience of tester or analyst having
prior experience in the same domain or similar domain
➔ The primary objective of this technique to identify common errors at any level of testing
➔ For example:
◆ Coding or logical error
◆ Syntax error
◆ Server Related error
◆ Database related error
◆ Browser related error
◆ UI Related error
◆ Connectivity related error
◆ Configuration related error

34
 Decision Table testing technique
➔ This is a systematic approach where the various input combination and their respective
system output shows in tabular form
➔ This Testing techniques can also be called as Cause-effects table where Cause is Input
value and Effect is output values are represents for better test coverage
➔ It used to pick the test cases in structured manner, it reduces a testing time and provides
good coverage to the testing area of the application
➔ Decision table is used to verify all probable combinations of conditions for testing and
test engineers are also able to find the missing conditions easily.
➔ This technique is important because it helps to test different combinations of conditions
and gives better test coverage for complex business logic.The conditions are Valid and
Invalid values.
➔ Normally, the number of probable combinations are calculated by 2 ^ n, where n is the
number of inputs. Therefore, when input(n) values are more such case we can goes for
any other technique like boundary value analysis or equivalent partitioning techniques
➔ Example: Assume that you need to write a test cases for profile picture uploading
functionality for chat application like whatsapp and below are the test conditions:
◆ Maximum file size is 2MB and
◆ File Type : JPEG(JPG), PNG & GIF
Therefore, our application accepts the image file only if both conditions are satisfied else
it throws an error message
The below one is decision table which captures the probable input conditions and their
respective outputs

Conditions Case Case Case Case Case Case Case Case Case Case Case Case
1 2 3 4 5 6 7 8 9 10 11 12

Input JPG PNG GIF JPG PNG GIF JPG PNG GIF Any Any Any
Format other other other
file file file
format format format

Input Size Size< Size< Size< Size= Size= Size= Size> Size> Size> Size< Size > Size =
2MB 2MB 2MB 2MB 2MB 2MB 2MB 2MB 2MB 2MB 2MB 2MB

Output Valid Valid Valid Valid Valid Valid Invalid Invalid Invalid Invalid Invalid Invalid

State Transition Techniques

35
➔ This technique represents when changes made in input conditions it cause the state of
output changes for the application
➔ This state transition techniques helps for testing to study the behavior of an application
for different input conditions
➔ Test engineers can give valid and invalid input test data and record the system behavior
➔ This technique can be used when a tester is having finite set of input values to test the
application
➔ When application have to test in sequential order like ATM Machine after insert the card
it ask the language, based on that input it ask another input like it goes until customer
final expectation
➔ When the system behavior is not in sequential order such case state transition technique
is not suitable for that modules or an application
➔ Below things should be understand before using state transition techniques for testing
the application
◆ State: It says the status of the element before and after input values or action.
For example, Button in Off status before action and Button in On Status after
action
◆ Transition: Here, the transition process happens when the status changes from
one status to another. For Example, When button changes from Off to On such
time one process happens which is called transition
◆ Events: To happen transition like changing the button from Off to On such action
is called Event
◆ Action: It says the result of transition may be success or failure. Example, When
changing the button from Off to On it shows success message for success else it
shows error message for failure
➔ Example: Assume a video file opens in any media player. Based on this example, you
can understand about the 4 components of state transition technique

◆ State - When video is playing which is play status and when it pause which is
pause status
◆ Transition - The Transition process gets when playing the video from pause
status
◆ Event - Pausing and Playing the video
◆ Action - When playing or pausing the video it get interrupt due to internet
connection or it keeps loading due to poor network

36
Use Case Testing Technique
➔ Use case is a brief description of action done by an actor or user on the System and the
responses of the software application(System) to those user actions
➔ It is extensively used in developing test cases at system or user acceptance level. Here,
Test cases looks like interactions between user and system
➔ This software testing technique assist to find test cases which covers the complete
system on a transaction by transaction basis from beginning to end of the system
➔ The use case gives us all probable techniques like what are possible ways users can
utilize the application
➔ This testing assist to fill the gaps if any in the system, that might not found when testing
the individual testing modules
➔ For every action on the application done by Actor and get reaction from the system for
that action which is called as Transaction
➔ For Example: Let’s assume +2 result pages published by the government.
◆ In a use case, user called as an Actor which represents by A and gets response
for corresponding action from System that represents by S
◆ Here, we can write a use case for a result functionality in a web application

37
 Scenario Step# Description

1 A: Enter Registration Number and DOB

A:Actor
2 S: Validate the Registration number and DOB
S:System
3 S: Allow to view the results with Marks

2a Invalid Registration number

S: Display the validation error message and ask for re-try
it
Extensions
2b Invalid Registration number 3 times
S: After 3 attempts system shows can try it again after
sometime

➔ Let’s see the above scenario in detail

◆ In the first step, Actor(User) enter the Registration Number and DOB
◆ In the second step, the system(S) validate the Registration Number and DOB
◆ On 3rd Step, if both details are valid then system navigates to result page
◆ For Failure case, here use keyword Extension in use case. If Registration
Number or DOB is invalid that case system throws an error message and ask to
retry it
◆ If both details are not valid for 3 times system ask to try after sometimes with
valid details

Testing Documentation / Test Case Development

Test Plan
Test Scenario
Test Case
Test Data Generation
Requirement Traceability Matrix(RTM)

Let’s see the above documentation in details

Test Plan:
➔ A Test plan has details about the test strategy going to use for testing an
application,scope of application,schedule for test activities, deadlines for testing
activities,deliverables after testing competes and it contains how much resources going
to use for testing an application
➔ Test Plan gives us how much effort needs to validate the quality of the application
➔ The quality assurance test lead, the test manager and the test engineer prepare the test
plan

38
 ➔ Below are the some benefits when making the test plan
◆ It is useful to development team, Business Analyst, Business development and
even for customers can understand the details of testing
◆ Testers can refer the Test plan to find which needs to be followed
◆ Management Team can find the features like Test strategy,scope of
application,test estimation, resources for testing by referring the Test Plan and
that can be use for other projects
➔ A test plan has the following Steps:
◆ Study about the Product
◆ Decide the Test Strategy going to use
◆ Mention the Test Objectives
◆ Define the Test Criteria(Entry and Exit Criteria)
◆ Resource Details for testing( Both Human and System Resource)
◆ Plan Test Environment
◆ Schedule and Estimation for testing activities
◆ Test Deliverable it contains Documents before testing,Test Data while testing,
Reports after testing

Test Scenario:
➔ Creating the test scenarios confirms test coverage covers completely
➔ Test scenario presents in one line statement of particular area for the application under
test
◆ For example: Scenario is, Checking the Login functionality
➔ From the Test scenario prepare the test cases for that functionality
◆ For example: Based on login functionality scenarios can write many test cases.
Here can see some sample test cases for this scenario a) Verify with valid user id
and password b) Verify with Invalid user Id and password c) Verify the forgot
password is working fine etc.
➔ To write a Test scenarios, first need to study the requirements thoroughly from Business
requirements document or any other document it vary from project or company wise and
understand it
➔ Tester needs to think as user perspective and have to focus to cover all real time
scenarios and use cases of the application
➔ Test scenarios are helps to ensure all process flows are tested from end to end of the
application
➔ Using Traceability matrix confirm all requirements has test scenarios or not
➔ Business Analyst/Test Lead/Test Manager and Client reviews the Test Scenarios and
approved it if no correction in the scenarios else it back to the team with their feedback

39
 ➔ Here, stated some scenarios from chat module for Whatsapp application
◆ Test Scenario 1: Check user able to Install the whatsapp from google and
register it
◆ Test Scenario 2: Verify user can be able to search the particular Name to send
the message
◆ Test Scenario 3: Verify user can be able to send the messages, images and
videos from gallery or camera
◆ Test Scenario 4: Verify user able to add participants in the group chat
◆ Test Scenarios 5: Verify user added participants in that group receives message
sent by sender
◆ Test Scenarios 6: Verify user able to set display picture(DP) from camera or
gallery in profile
➔ Like this we can write some more scenarios for chat module based on these scenarios
can write several test cases

Test Case:

➔ Test cases derives from Test Scenario of particular feature or functionality of the software
application
➔ Using Test cases perform the actions to validate the particular features of the application
➔ Test case should have all positive and negative test cases for respective scenarios
➔ Test Case contains Test case description, test steps, test data, Expected result, Actual
result and Pass/Fail status
➔ Same Test Cases can be used for Regression testing
➔ Tester starts to write a test cases when customer gives his requirement to Business
team and while programmer starts the developing application
➔ Once test cases are done it forward to the Business team they will review it then it goes
to the client for their review. If there is any feedback from the client, the tester will correct
it and send it to the client. It goes until client approve
➔ Test case execution starts once developer completes the development of application and
deployed in respective environment
➔ Before test execution the test case prepares so actual result and status details are
blanks only.
➔ After test executed based on the output, the actual result and status updated in
respective columns which is called Test Report
➔ Test case templates vary from project or company wise. But some basic columns are
always presents in Test case templates
◆ Test Case ID

40
 ◆ Requirement#
◆ Module
◆ Test case description
◆ Test case steps
◆ Test data
◆ Expected Result
◆ Actual Result
◆ Pass/Fail status
Let’s see whatsapp as a simple example for Test Cases

Test
TC Scenari Test Case Expected Actual Stat
No Module o Description Test Steps Results Results us
1. Open the
whatsapp and make
sure app in chat
screen
2. Click the new
message button
3. Search the
Contact:Contact X to
whom need to send
message and select
Verify user it
able to send 4. Type the User should
message by message: Testing the able to send
Verify using new message messages
user able message 5. Click the send to selected
1 to send a button button person
message
1. Open the
Chat s,images
whatsapp and make
and
sure app in chat
videos
screen
in single
2. Select the person
chat
Verify user from the recent chat
able to send Contact X
message by 4. Type the User should
selecting the message: Testing the able to send
person from message messages
recent chat 5. Click the send to selected
2 screen button Person

41
 1. Open the
whatsapp and make
sure app in chat
screen
2. Search the
Contact: Contact X
to whom need to
send image and
select it
4. Select the
attachment option
and select the gallery
Verify user 5. Select the images User should
able to send or photos to send able to send
images from 6. Click the send images from
3 gallery button gallery
1.Open the whatsapp
Verify that the 2.Click on Settings User should
user can view 3.Click the profile able to view
the profile and view the profile the profile
4 picture photo picture
1.Open the whatsapp User should
2.Click on Settings able to set
3.Click on profile and the profile
Verify that the Camera icon picture
user able to 4. Select the camera using
Verify set the photo option to set the camera
5 that the from camera profile picture option
user can User should
set 1.Open the whatsapp able to
Setting
Display 2.Click on Settings upload the
Picture(D Verify that the 3.Click on profile and profile
P) or user can Camera icon picture
not. upload the 4. Select the gallery using
photo from option to set the gallery
6 Gallery profile picture option
1.Open the whatsapp
2.Click on Settings
3. Click on profile
and Camera icon User should
Verify that the 4. Select either able to
user can gallery or camera remove the
remove the option profile
7 photo 5. Then, select picture

42
 Delete icon to
remove the picture
1.Open the whatsapp
2.Click on Settings
3.Click the profile User should
Verify Verify that the and change the able to set
that the user can set about content by the about
8 user can status or not. clicking edit button content
set
status or 1.Open the whatsapp
not. Verify that the 2.click on Settings User should
user can 3.click the profile and able to
update status set the about by update the
9 or not. clicking edit button about

Test Data Generation:

➔ Test data is an input data given to software application wherever needed in test
execution
➔ Enter valid test data as input to get the expected result for positive testing
◆ Example: Enter Valid username and password and expected result is system
should navigate to respective page
➔ Enter invalid test data as input to get the unexpected result for negative testing
◆ Example: Enter Invalid username and password and expected result is system
should throw the validation error message
➔ While preparing the test case, wherever possible enter the input value for the test cases
that saves execution time as well saves time for updating the test data in test case while
execution
➔ Let’s see whenever uses test data as input in the application
◆ For Negative testing, verify the system response whether it throws error message
when input field is empty, test data as invalid format, Invalid Input values, test
data not in the limitation etc.,
◆ For positive testing pass the valid input and verify the system response whether
user gets success message or it navigates to respective page
◆ When tester using the testing techniques like boundary value analysis,
Equivalence partition,Decision table,State transition then that fields needs input
data to check the functionality of the application

Requirement Traceability Matrix(RTM)

43
 ➔ Requirement traceability matrix is use to trace that all requirements are covered in
development and testing for the software application
➔ Requirement traceability matrix creates with the help of Business requirements
document(BRD) or Functional requirements document(FRD)
➔ RTM will be in the table format that contains the requirements with all possible test
scenarios and test cases and their current state which means it has pass,fail,Not
executed status
➔ The main aim of requirement traceability matrix is to validate that all requirements are
verified through test cases so we cannot miss any requirements for the project
➔ It is prepared by the test lead or test manager
➔ It contains the percentage of pass, fail, Not executed etc in numbers and in charts
➔ The Main aim of this matrix are
◆ Ensure the software is developed as per mentioned in the requirement
documents
◆ Using Matrix can get how many fail cases are there and how much testing are
completed
◆ It helps to concentrate on failed cases to fix it and Not executed/Pending test
cases to complete it before deadline
◆ It use to trace the developed documents during the different phases of SDLC
➔ Types of traceability matrix is
◆ Forward traceability maps from requirement to test cases that means all
requirement applied to the product and all requirement is tested fully
◆ Backward traceability maps from test cases to requirements
◆ Bi-direction tracing ensures all the requirements are covered by test cases

RTM template

Requirement ID Requirement Test Scenario Test Cases Status

Description

1 Login & TS1- Login TC1,TC2…TCn TC1-Pass,

Logout TS2 - Logout…. TC1, TC2… TCn TC2-Fail
TSn

2 Buy the TS1- Add the TC1.TC2…TCn TC1-Pass,

product cart TC1,TC2…TCn TC2-Not
TS2- Place the executed
order… TSn

44
 Total 100 1000
Requirement=100

RTM in chart for 3 platforms about status

Defect Tracking
What is Bug/Defect in software testing
Bug life cycle
Severity and Priority
Test Environment
Test Report and Bug Report

What is Bug/Defect in Software testing?

➔ Defect is an Error or Bug finding in created application while testing the application
➔ A programmer can make mistake in a coding while developing the application which is
called defects
➔ When application has mistake or error it won’t get expected result those error needs to
correct by developer
➔ All these defects will be find it in testing process by test engineers
➔ Defect or Bug occurs when developer writes wrong coding or wrong logic, developer
miss the code, & adds some extra coding while developing the application
➔ Take a forgot password functionality as an example to know about the bug
◆ Steps for Test case

45
 ● Click the forgot password link in login page
● It should navigate to page which contains requesting the mail id
● After enter the required details new password should come in the mail id
◆ Issue is mail received without a new password. Therefore, issue is without new
password user not able to login if user forgot the password which is a defect in
the application
➔ In the current market so many tools are present for defect management like
Jira,Bugzilla,Mantis etc.

Bug life cycle

Below are the life cycles of bugs:
➔ New : An error reported first time it comes as new error
➔ Open : Reported error assigned to developer by respective manager that is open state
➔ Fixed: Reported issue fixed by developer
➔ Resolved: Once reported issue is fixed status change to resolved by developer
➔ Retest: Need to retest the issue once fixed whether it is working or not
➔ Closed: If fixed issue is working fine then that bug is closed
➔ Reopen: If fixed issue is not working then reopen the bug
➔ Invalid: If developer thinks this is not an bug or for developer that issue works fine such
cases developer change the status to Invalid
➔ Duplicate: When same issue is raised twice such case developer marks one of the bug
as duplicate
➔ Example: Can take a same forgot password example mentioned in previous topic
◆ Testers raise that the new password is not received in mail as a New bug that
comes under Open status. Then, that bug assign to respective developer to fix
the issue
◆ Once issue is Fixed that status change to Resolved by developer
◆ Tester retest, now forgot password mail receiving with new password and able to
login using new password then that bug will be closed else that bug gets reopen
◆ When developer checks this issue their side if he/she receives mail with new
password perfectly before doing the fix then developer change the status to
Invalid
◆ If same forgot password issue raised by 2 testers such case one of the bug
marked as Duplicate

Bug Severity and Priority

Severity Bug:

46
 ➔ It measures how that bug affect the functionality of the software application
➔ Based on severity of the bug the testing process can be stopped such kind of bug need
to fix as soon as possible
➔ Severity are categorized into below
◆ Low - This is the very least severity in the bug. The Impact of this issue is very
low. Maybe this issue can occur in rare scenarios.
◆ Minor - This severity comes prior to Low severity. It won’t affect the functionality
of the application but it should be fixed.
◆ Major - This kind of severity bug should be fixed before release of the application
or version. It won’t stop further testing and can proceed the testing process.
◆ Critical - The main functionality of the application is not working such that the
case tester cannot continue the testing process. This kind of severity is also
known show stopper bug

Priority Bug:
➔ Identify the priority of the bug and initiate the action accordingly
➔ The high priority bugs to be fixed immediately
➔ Below are the priority bug categorized
◆ Low(P3) - This is the very least priority bug can do fix after high and medium
priority fixes may be can do these fixes after release also if this bug not affect the
functionality of the application.
◆ Medium(P2) - This priority bug it affects the application can fix before releasing
the application or version.
◆ High(P1) - This High priority bug needs to give first attention to fix the issue due
to this kind of bug testing process may be on hold.

Severity and Priority are the directly correlated

➔ High Severity and High priority: Need to fix the bug immediately since this kind of bug
affects the functionality of the application and stop the testing process
◆ Example: Consider whatsapp, trying to open the app in mobile but can't, it
crashes so it is not able to use the app such time developers need to fix this bug
as First Priority(P1) since this is a high severity bug.
◆ Similarly if any issues block the testing process such bugs come under P1 like
chat functionality, Audio or video calls functionality are not working those bugs fall
in P1.
➔ Low Severity and Low priority: Due to this kind of bug impacts is not much in the
application so can fix it at last either in current release or next release

47
 ◆ Example: In whatsapp inside to setting module in chat tab, if not able to see the
app information when clicks it such bug falls in low severity since it impacts is not
affect the functionality so it comes under low Priority(P3)
➔ High Severity and Low Priority: Some bug severity would be high but it comes under
low priority since it impacts is very high but users uses that scenario in rare case so it
comes under low priority that can be fixed before the current or next release
◆ Example: In Status, if Emoji is not able to select since those are not listing there
such issue impacts the functionality of application but it not comes under P1
since emoji won’t use by all users in status therefore that issue can be fixed
before the current or next release
➔ Low Severity and High Priority: Most of the design issues impacts is very less but
appearance of the application is not good so such kind of bug needs to give high priority
◆ Example: After adding the profile image in DP it overlap with Group name or
Individual person name in Chats or status or calls tab it impacts not affect in
functionality but app appearance is not good therefore needs to fix it as High
Priority(P1)

Test Environment:
➔ The test environment is use to test the software application after development to find the
errors in the application
➔ Once the requirement details gets from client, the development team starts to develop
the application in development environment
➔ After development completes the code moves to the QA environment for testing
➔ Most of the companies have 4 servers for projects.
◆ Development Server: When projects get from the client, first will get the
requirement details in a Business requirements document. Devops team creates
development server for developing the application, there programmer writes the
code and debug the code while developing the application
◆ QA Server: This environment setup with normal configuration which is used to
test the application after developing, that code moves into this QA server.
Whatever bugs are raised to the developer once they fix that issue, those codes
move to this environment to retest the issue.
◆ Staging Server: This environment configuration is similar to production server so
once testing completes in QA server the same code moves to staging server.
One round of testing will be done in this server to confirm application is stable
before codes push into the production server

48
 ◆ Production Server: This environment is used by the end user once code is
pushed into production from the staging server. Sanity or Smoke test will be done
by test engineers to confirm the application is stable

Test Report:

➔ In Test report, can see the actual result, status of the test case and Bug details wherever
test case is failed
➔ Test Report is a summarize from test case execution which contains test results and Bug
priority details
➔ Test report is useful to product managers, Business team and developers whether
software can be released or not
➔ Test report is needs to make sure the application are stable which is acceptable level of
quality
➔ Test report represents the current status of the project and it helps to measure the quality
of the end product
➔ Mostly Test Report contains below informations in the summary sheet
◆ Project Name
◆ Types of testing
◆ Application Feature/Modules
◆ Execution status(Includes Pass,Fail,Inprogress,Pending,Blocked,Not applicable)
◆ Defects details with priority level like High, Medium & Low

Template of Test Report:

➔ This is the test report template. May be vary based on Companies or Projects

49
 ➔ Above template is for web applications. If your project has mobile platforms then extend
the same format for those platforms
➔ Initially Project Name and Type of testing comes in the top of the table
➔ Features represents the module or component of the application
➔ Pass is number of test cases passed for particular feature
➔ Similarly number of test cases failed,pending and blocked for particular features
➔ In the end of the table, identify the total number of TC’s for pass,fail,pending & blocked
for all features and the total number of test cases presents for all features in this release
or application
➔ Then, Efforts Estimation in hours and days represents the estimation of this release in
hours and days for these features
➔ Version number of the release for the project, Pass, Fail,Pending, Blocked and Executed
percentage can be seen in the next table. Can keep any colors for status to identify it
➔ This is the simple calculation to get the percentage of Pass, Fail, Pending & Blocked
status that are calculated by total number of particular status of test case(Eg: Pass-375)
divided by total number of test cases of all status(Eg: 498) multiple by 100(Eg:
375/498*100=75%)
➔ Executed status percentage can be calculated by adding the percentage of Pass and
Fail test cases(Eg: 75+11=86%) it shows overall executed status
➔ In the last table, you can see the number of failed test cases based on priority like High,
Medium and Low. That total number of failed test cases should be matched with number
of test cases mentioned in the failed status in the feature table

Bug Report:
➔ Bug Report is a detail documents about defects addressed to the developer to fix while
testing the application
➔ The bug reports must contains the scenario or test case steps or root cause of the issue
so it’s easy to fix the defects faster by developer
➔ This saves the software release date from delay and can make the product on time with
good quality
➔ When reporting the bug to developer the below information contains in the bug report
◆ Bug_id: Unique identification number for bug addressed to developer
◆ Bug description: It describe the details of the bug including in which module bug
was found
◆ Test Steps to reproduce the bug: Here, elaborating the steps how can able to
get that bug
◆ Affected and Fix Version: In which version, the bug was identified and which
version going to fix it

50
◆ Reported Date: When the bug was addressed to developer
◆ Components: In which platforms, the bug is being identified either Web
application or Android or iOS
◆ Reported By : The name of the tester who raised the bug
◆ Resolved By: The name of the developer who resolved this bug
◆ Status : The latest status of the bug whether it has been closed or reopened
◆ Closed Date: When that bug is closed by tester
◆ Priority: Mentioning the priority of the bug whether it has been High/Medium/Low
based on the severity of the bug that means how that bugs impacts of the
application
◆ References: Any proof of the bug like screenshots of the issue, requirement
documents to make sure features of the application should be like this.

51