Introduction to software testing Presentation

GITAM
CSE DEPARTMENT
SUBJECT: SOFTWARE TESTING
COURSE CODE: PEC-CSE-413G
B. TECH CSE 7TH
SEM
LECTURE DELIVERED BY:
RITIKA SAROHA
ASSISTANT PROFESSOR
CSE DEPT.

SYLLABUS
Unit 1
Introduction: Overview of Software Development
Life Cycle (SDLC), Significance of Software Testing
in SDLC, Objectives and Limitations of software
testing. Difference between an Error, Fault and
Failure (Software Bug), Software Testing Life
Cycle (STLC) and Seven Principles of Software
Testing, Role of Software Testing in Software
Quality

UNIT 2
 Test Case Design: Test Cases and Test Suite, Test
Case Planning and Designing, Characteristics of Good
Test Case Design, Format of test case.
 Testing Activities: Levels of Testing- Unit, Integration
Testing and System Testing. V Model for Software
Testing.

SDLC (SOFTWARE DEVELOPMENT
LIFE CYCLE)
WHAT IS SDLC?
 It is also called as Software Development
Process.
 Software development life cycle (SDLC) is a
structured process that is used to design,
develop, and test good-quality software.
OR
 SDLC is a methodology that defines the entire
procedure of software development step-by-step.

INTRODUCTION
 Software Development Life Cycle (SDLC) is a
process used by the software industry to design,
develop and test high quality software’s.
 The SDLC aims to produce a high-quality
software that meets or exceeds customer
expectations, reaches completion within times
and cost estimates.

STAGE 1
PLANNING AND REQUIREMENT
ANALYSIS
 Requirement analysis is the most important and
fundamental stage in SDLC.
 It is performed by the senior members of
the team with inputs from the customer, the
sales department, market surveys and
domain experts in the industry.

 This information is then used to plan the basic
project approach and to conduct product
feasibility study in the economical,
operational and technical areas.
 Risk Identification is also done in the planning
stage.
 The outcome of the technical feasibility
study is to define the various technical
approaches that can be followed to
implement the project successfully with
minimum risks.

STAGE 2: DEFINING
REQUIREMENTS
 Define and document the product
requirements
 This is done through an SRS (Software
Requirement Specification) document which
consists of all the product requirements to
be designed and developed during the project
life cycle.

STAGE 3:
DESIGNING THE PRODUCT ARCHITECTURE
 Based on the requirements specified in SRS,
usually more than one design approach for the
product architecture is proposed and documented
in a DDS - Design Document Specification.
 DDS is reviewed by all the important
stakeholders.
 on the basis of various parameters as risk
assessment, product robustness, design
modularity, budget and time constraints,
the best design approach is selected for the
product.

STAGE 4: BUILDING OR DEVELOPING
THE PRODUCT(CODING)
 Actual development starts and the product is
built.
 During this stage. The programming code is
generated as per DDS.
 The programming language is chosen with
respect to the type of software being
developed.

STAGE 5: TESTING THE PRODUCT
 This is testing stage of the product.
 Here product defects are reported, tracked,
fixed and retested.

STAGE 6: DEPLOYMENT IN THE
MARKET AND MAINTENANCE
 Once the product is tested and ready to be deployed
it is released formally in the appropriate market.
 Sometimes product deployment happens in stages as
per the business strategy of that organization.
 The product may first be released in a limited
segment and tested in the real business environment
(UAT- User acceptance testing).
 Then based on the feedback, the product may be
released as it is or with suggested enhancements in
the targeting market segment.
 After the product is released in the market, its
maintenance is done for the existing customer base.

SDLC MODELS
These models are also referred as “Software
Development Process Models”:
 Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
 Agile Model, RAD (Rapid Application
Development) Model
 Prototyping Models.

•
WATERFALL MODEL
 The Waterfall Model was the first Process Model
to be introduced.
 It is also referred to as a linear-sequential life
cycle model.
 It is very simple to understand and use.

 In a waterfall model, each phase must be
completed before the next phase can begin and
there is no overlapping in the phases.

STAGES OF WATERFALL MODEL
STAGE1: Requirement Gathering and analysis −
All possible requirements of the system to be
developed are captured in this phase and documented
in a requirement specification document(SRS).
STAGE2: System Design −
 The requirement specifications from first phase are
studied in this phase and the system design is
prepared.
 This system design helps in specifying hardware
and system requirements and helps in defining the
overall system architecture.

WATER MODEL(CONTD.)
STAGE3:Implementation −
 With inputs from the system design, the system is
first developed in small programs called units,
which are integrated in the next phase.
 Each unit is developed and tested for its
functionality, which is referred to as Unit Testing.
STAGE4:Integration and Testing −
 All the units developed in the implementation
phase are integrated into a system after testing of
each unit.
 Post integration the entire system is tested for
any faults and failures.

WATER MODEL(CONTD.)
STAGE5: Deployment of system −
 Once the functional and non-functional testing is
done; the product is deployed in the customer
environment or released into the market.
STAGE6:Maintenance −
 There are some issues which come up in the
client environment. To fix those issues, patches
are released.
 Also to enhance the product some better versions
are released. Maintenance is done to deliver
these changes in the customer environment.

WATERFALL MODEL - APPLICATION
 Requirements are very well documented, clear
and fixed.
 Product definition is stable.
 Technology is understood and is not dynamic.
 There are no ambiguous requirements.
 Ample resources with required expertise are
available to support the product.
 The project is short.

WATERFALL MODEL - ADVANTAGES
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model.
Each phase has specific deliverables and a review
process.
 Phases are processed and completed one at a
time.

ADVANTAGES [CONTD.]
 Works well for smaller projects where
requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.

WATERFALL MODEL -
DISADVANTAGES
 No working software is produced until late
during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented
projects.
 Poor model for long and ongoing projects.

WATERFALL MODEL -
DISADVANTAGES
 Not suitable for the projects where requirements
are at a moderate to high risk of changing. So, risk
and uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a
project.
 Integration is done as a "big-bang. at the very end,
which doesn't allow identifying any technological or
business bottleneck or challenges early.

OBJECTIVES OF SOFTWARE
TESTING
 Here are five main objectives of software
testing:
1. Verification and Validation
2. Identification of Defects
3. Defects Prevention
4. Ensuring Quality Attributes in the Product:
Some of the quality attributes tested with
software testing include functionality,
performance, usability, security, compatibility,
and scalability, among others.
5. Risk Management

LIMITATIONS OF SOFTWARE
TESTING
 It’s impossible to test for all conditions.
 Testing usually gives no insight into the root
causes of errors.
 Time and resource constraints.
 Reliance on test data.
 Inability to guarantee absolute correctness.

BUG,DEFECT,ERROR
BUG:
 When we have some coding error, it leads a program to its
breakdown, which is known as a bug.
 The test engineers use the terminology Bug.
DEFECT:
 When the application is not working as per the requirement is
knows as defects.
 It is specified as the aberration from the actual and
expected result of the application or software.
 announced by the programmer and inside the code is called
a Defect.
ERROR: The Problem in code leads to errors. Developer uses the
term error.

FAULT, FAILURE
 The fault may occur in software because it has not
added the code for fault tolerance, making an
application act up.
 A fault may happen in a program because of the
following reasons:
• Lack of resources
• An invalid step
• Inappropriate data definition
Failure
 Many defects lead to the software's failure, which
means that a loss specifies a fatal issue in software/
application or in its module, which makes the system
unresponsive or broken.

DIFFERENCE BETWEEN
ERROR,FAULT AND FAILURE

SOFTWARE TESTING LIFE CYCLE
(STLC)
 The procedure of software testing is also known as STLC
(Software Testing Life Cycle) which includes phases of the
testing process
 Characteristics of STLC
• STLC is a fundamental part of the
Software Development Life Cycle (SDLC) but STLC consists
of only the testing phases.
• STLC starts as soon as requirements are defined or
software requirement document is shared by
stakeholders.
• STLC yields a step-by-step process to ensure quality
software.

STLC PHASES
 Software testing life cycle contains the
following steps:
1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test case Execution
6. Test Cycle Closure

STLC PHASES (PHASE 1)
Requirement Analysis is the first step of the Software Testing Life
Cycle (STLC).
 The activities that take place during the Requirement
Analysis stage include:
• Reviewing the software requirements document (SRS) and
other related documents(DDS).
• Interviewing stakeholders to gather additional information
• Identifying any ambiguities or inconsistencies in the
requirements
• Identifying any missing or incomplete requirements
• Identifying any potential risks or issues that may impact the
testing process
Creating a requirement traceability matrix (RTM) to map
requirements to test cases

PHASE 2 TEST PLANNING
The activities that take place during the Test Planning stage
include:
• Identifying the testing objectives and scope
• Developing a test strategy: selecting the testing methods and
techniques that will be used
• Identifying the testing environment and resources needed
• Identifying the test cases that will be executed and the test data that
will be used
• Estimating the time and cost required for testing
• Identifying the test deliverables and milestones
• Assigning roles and responsibilities to the testing team
• Reviewing and approving the test plan
 At the end of this stage, the testing team should have a detailed plan
for the testing activities that will be performed, and a clear
understanding of the testing objectives, scope, and deliverables.

PHASE 3:TEST CASE DEVELOPMENT
 In this phase testing team notes down the detailed
test cases. The testing team also prepares the
required test data for the testing.
• Identifying the test cases that will be developed
• Writing test cases that are clear, concise, and easy to
understand
• Creating test data and test scenarios that will be used
in the test cases
• Identifying the expected results for each test case
• Reviewing and validating the test cases
• Updating the requirement traceability matrix (RTM) to
map requirements to test cases

PHASE 4 TEST ENVIRONMENT
SETUP
 Test environment setup is a vital part of the STLC.
Basically, the test environment decides the conditions
on which software is tested.
 This is independent activity and can be started along
with test case development.
 In this process, the testing team is not involved.
either the developer or the customer creates the
testing environment.

PHASE 5:TEST EXECUTION
 After the test case development and test
environment setup test execution phase gets
started. In this phase testing team starts executing
test cases based on prepared test cases in the
earlier step.

PHASE5:TEST CYCLE CLOSURE
Test closure is the final stage of the Software Testing Life Cycle (STLC) where all
testing-related activities are completed and documented.
 The main activities that take place during the test closure stage include:
• Test summary report: A report is created that summarizes the overall testing
process, including the number of test cases executed, the number of defects
found, and the overall pass/fail rate.
• Defect tracking: All defects that were identified during testing are tracked and
managed until they are resolved.
• Test environment clean-up: The test environment is cleaned up, and all test data
and test artifacts are archived.
• Test closure report: A report is created that documents all the testing-related
activities that took place, including the testing objectives, scope, schedule, and
resources used.
• Knowledge transfer: Knowledge about the software and testing process is shared
with the rest of the team and any stakeholders who may need to maintain or
support the software in the future.
• Feedback and improvements: Feedback from the testing process is collected and
used to improve future testing processes

7 PRINCIPLES OF SOFTWARE
TESTING

APPLICATION OF SOFTWARE
TESTING IN QUALITY PLANNING:
 Quality planning is the development of a series of
measures and steps to ensure the high quality of a
software product.
 Determine the test objectives and scope
 Determine the test strategies and methods
 Make a test plan
 Evaluate test coverage

 Software testing can help identify software defects and
problems, prevent software errors, and ensure that
software quality meets user needs and standards.
 Standardized management of software testing can
improve test efficiency and test quality, and can also
reduce test cost and test risk.
 In the software testing process, we need to have
certain skills and knowledge, and need to pay
attention to communication and collaboration to
ensure that the test tasks can be completed on time.

 Software testing should be a whole-process activity,
including test plan, test design, test execution, test
evaluation and test improvement.
 In conclusion, software testing plays a vital role in
software quality management, and only continuous
improvement in the testing process can ensure the
stability and reliability of software quality.

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

TEST CASES (CONTD.)
 These are executed during the testing process to
check whether the software application is
performing the task for that it was developed or
not.
 Test case helps the tester in defect reporting by
linking defect with test case ID.
 Detailed test case documentation works as a full
proof guard for the testing team because if
developer missed something, then it can be caught
during execution of these full-proof test cases.

TEST CASES (CONTD.)
 To write the test case, we must have the
requirements to derive the inputs, and the test
scenarios must be written so that we do not miss out
on any features for testing.
 Generally, we will write the test case whenever the
developer is busy in writing the code.

WHEN DO WE WRITE A TEST CASE?
• When the customer gives the business needs then, the
developer starts developing and says that they need 3.5
months to build this product.
• And In the meantime, the testing team will start writing
the test cases.
• Once it is done, it will send it to the Test Lead for the
review process.
• And when the developers finish developing the product,
it is handed over to the testing team.
• The test engineers never look at the requirement while
testing the product document because testing is
constant and does not depends on the mood of the
person rather than the quality of the test engineer.

WHY WE WRITE THE TEST CASES?
 We will write the test for the following reasons:
• To require consistency in the test case
execution
• To make sure a better test coverage
• It depends on the process rather than on a
person
• To avoid training for every new test engineer
on the product
 To require consistency in the test case
execution: we will see the test case and start
testing the application.
 To make sure a better test coverage: for this,
we should cover all possible scenarios and

TEST CASE TEMPLATE
The primary purpose of writing a test case is to
achieve the efficiency of the application.

 we know, the actual result is written after the
test case execution, and most of the time, it
would be same as the expected result. But if
the test step will fail, it will be different. So, the
actual result field can be skipped, and in the
Comments section, we can write about the
bugs.
 Test case type
 It can be functional, integration or system test
cases or positive or negative or positive and
negative test cases.

EXAMPLE OF TEST CASE FOR ICIC’S
APPLICATION LOGIN

TYPES OF TEST CASES
 We have a different kind of test cases, which are
as follows:
• Function test cases
• Integration test cases
• System test cases
 The functional test cases
 Firstly, we check for which field we will write test
cases and then describe accordingly.

 Rules to write functional test cases:
• In the expected results column, try to
use should be or must be.
• Highlight the Object names.
• We have to describe only those steps which we
required the most; otherwise, we do not need to
define all the steps.
• To reduce the excess execution time, we will
write steps correctly.
• Write a generic test case; do not try to hard code
it.

TEST CASE
 A test case is a set of instructions determining whether
a software or system behaves as expected.
 A test case generally outlines the various inputs and
outputs for a particular scenario and provides step-by-
step instructions on executing that scenario.
 It can also include information about the expected
result after executing those steps.
 Test cases are essential because they help identify
bugs and issues early, saving time and money in the
long run.
 Ensuring high-quality software products that meet
customer requirements would be much harder without
them.

IMPORTANCE OF TEST CASE
 They help identify defects and bugs in the software application.
 Test cases assist in verifying whether the software application
meets its functional and non-functional requirements.
 They help in validating the accuracy and completeness of the
software application.
 Test cases help establish quality standards for the software
application.
 They assist in tracking the progress of software testing
activities.
 Test cases act as a guide for developers to fix defects and errors.
 They help reduce software development costs by detecting
defects early in the development lifecycle.
 Therefore, creating complete Test cases is essential to ensure
the software application performs as expected and delivers an
excellent user experience without errors or defects.

A sample Test case to test whether an existing user can log
in to the website successfully.
Test Objective: Confirm you can log into the website using
the correct information.
Pre-requisites: A valid username and password.
Steps:
1.Launch the application under test.
2.Enter the valid username and password.
3.Click the ‘Login’ button.
4.Ensure that the user logs in successfully.
Expected Result: The user should be successfully logged
in to the website. So now we can see how to create a Test
case using Test sigma. The image below shows you how to
begin creating a Test case in Test sigma. It has all the
advanced options for creating a Test case.

WHAT IS A TEST SUITE?
 A test suite is a set of tests designed to check the
functionality and performance of the software.
 It collects individual test cases based on their specific
purpose or characteristics.

IMPORTANCE OF TEST SUITE
 As a test suite is a collection of test cases grouped
according to a specific set of criteria, we must learn
the major importance of these test suits.
 By organizing test cases into test suites, testers can
identify and prioritize the most critical tests, ensuring
that the most important aspects of the software are
tested first.
 This helps reduce the risk of missed errors or defects
during testing.

TEST SUITES- AN EXAMPLE
 a Test suite for a product means creating a Test
suite with multiple Test cases.

DIFFERENCE BETWEEN TEST SUITE
AND TEST CASE
Parameter Test Suite Test Case
Definition
A collection of test cases that are designed to test a
specific feature or functionality of the software
A set of inputs, preconditions, and expected
outcomes that are designed to test a particular
aspect of the software
Function Tests multiple scenarios and functionalities Tests a single scenario or functionality
Dependency It can be dependent on other Test Suites
Test cases, ideally, run independently of each
other
Priority
Can be prioritized based on the functionality they
cover
Can be prioritized based on the severity of the
issues they uncover
Purpose Validate broad functional requirements Validate specific detailed scenarios

TEST CASE PLANNING AND
DESIGNING
 TEST CASE PLANNING:
A test plan is a detailed document which describes
software testing areas and activities. It outlines the test
strategy, objectives, test schedule, required resources
(human resources, software, and hardware), test
estimation and test deliverables.
 The test plan is prepared by the Test Lead (60%), Test
Manager(20%), and by the test engineer(20%).

TYPES OF TEST PLAN
• Master Test Plan
• Phase Test Plan
• Specific Test Plans
 Master Test Plan
Master Test Plan is a type of test plan that has multiple levels of
testing. It includes a complete test strategy.
 Phase Test Plan
A phase test plan is a type of test plan that addresses any one
phase of the testing strategy. For example, a list of tools, a list
of test cases, etc.
 Specific Test Plans
Specific test plan designed for major types of testing like
security testing, load testing, performance testing, etc. In other
words, a specific test plan designed for non-functional testing.

HOW TO WRITE A TEST PLAN
Making a test plan is the most crucial task of the test
management process. According to IEEE 829, follow the
following seven steps to prepare a test plan.
• First, analyze product structure and architecture.
• Now design the test strategy.
• Define all the test objectives.
• Define the testing area.
• Define all the useable resources.
• Schedule all activities in an appropriate manner.
• Determine all the Test Deliverables.

TEST PLAN COMPONENTS OR
ATTRIBUTES

THE DIFFERENT TYPES OF TEST CASE DESIGN
TECHNIQUES
Test case design techniques allow QA engineers to design better
test cases, reduce the number of test cases to be executed, and
increase testing coverage.
1. Specific-Based Techniques (Black Box Techniques)
2. Boundary value analysis (BVA)
3. Equivalence partitioning (EP)
4. Decision table testing
5. State transition diagrams
6. Use case testing
7. Structure-Based Techniques (White Box Techniques)
8. Statement coverage testing
9. Decision testing coverage
10. Condition testing
11. All path testing
12. Experience-Based Techniques

CHARACTERISTICS OF GOOD TEST
CASE DESIGN
These are the characteristics of Good Test Case.
1. Test cases should have very good test case
coverage.
2. Test Cases should have good coverage with less
no. of steps.
3. Test Case should be written by applying test case
design techniques.
4. Test Case should be simple to understand.
5. If test cases given to any new Tester, he/ she
should be able to execute the test cases without
asking any questions or clarifications.

1. Test Case should be written in test case
template.
2. Test Case should be consistent, means flow or
sequence should be good.
3. Test Case should consists of both positive and
negative scenarios.
4. Test cases should be able to catch the defects.
5. Test cases should not be redundant, means no
duplicates.
6. Test Cases should be very easy to convert into
Automation scripts.

Introduction to software testing Presentation

Recommended

More Related Content

Similar to Introduction to software testing Presentation (20)

Recently uploaded (20)

Introduction to software testing Presentation