Learn Software Testing
For Beginners
What is Quality?
Quality is “fitness for use” - (Joseph
Juran)
Quality is “conformance to
requirements” - (Philip B. Crosby)
Quality of a product or service is its
ability to satisfy the needs and
expectations of the customer
SOFTWARE DEVELOPMENT LIFE
CYCLE (SDLC)
Phases of SDLC
• Requirement Specification and
Analysis
• Design
• Coding
• Testing
• Implementation
• Maintenance
Requirement Specification
and Analysis
User Requirement Software Requirement
Specification (USR) Specification (SRS)
Design
The output of SRS is the input of design phase.
Two types of design -
High Level Design (HLD)
Low Level Design (LLD)
High Level Design (HLD)
List of modules and a brief description of each
module.
Brief functionality of each module.
Interface relationship among modules.
Dependencies between modules (if A exists, B
exists etc).
Database tables identified along with key
elements.
Overall architecture diagrams along with
technology details.
Low Level Design (LLD)
Detailed functional logic of the module, in
pseudo code.
Database tables, with all elements,
including their type and size.
All interface details.
All dependency issues
Error message listings
Complete input and outputs for a module.
The Design process
Breaking down the product into independent
modules to arrive at micro levels.
2 different approaches followed in designing –
Top Down Approach
Bottom Up Approach
Top-down approach
Bottom-Up Approach
Coding
Developers use the LLD document and
write the code in the programming language
specified.
Testing
The testing process involves development of
a test plan, executing the plan and
documenting the test results.
Implementation
Installation of the product in its operational
environment.
Maintenance
After the software is released and the client starts
using the software, maintenance phase is started.
3 things happen - Bug fixing, Upgrade, Enhancement
Bug fixing – bugs arrived due to some untested
scenarios.
Upgrade – Upgrading the application to the newer
versions of the software.
Enhancement - Adding some new features into the
existing software.
Most Common Software problems
Incorrect calculation
Incorrect data edits & ineffective data
edits
Incorrect matching and merging of data
Data searches that yields incorrect
results
Incorrect processing of data
relationship
Incorrect coding / implementation of
business rules
Inadequate software performance
Confusing or misleading data
Software usability by end users &
Obsolete Software
Inconsistent processing
Unreliable results or performance
Inadequate support of business needs
Incorrect or inadequate interfaces
with other systems
Inadequate performance and security
controls
Incorrect file handling
Objectives of testing
Executing a program with the intent of
finding an error.
To check if the system meets the
requirements and be executed
successfully in the Intended environment.
To check if the system is “ Fit for purpose”.
To check if the system does what it is
expected to do.
Objectives of testing
A good test case is one that has a
probability of finding an as yet
undiscovered error.
A successful test is one that uncovers a
yet undiscovered error.
A good test is not redundant.
A good test should be “best of breed”.
A good test should neither be too simple
nor too complex.
VERIFICATION & VALIDATION
Verification - typically involves reviews and meeting
to evaluate documents, plans, code, requirements,
and specifications. This can be done with checklists,
issues lists, walkthroughs, and inspection meeting.
Validation - typically involves actual testing and
takes place after verifications are completed.
Validation and Verification process continue in
a cycle till the software becomes defects free.
DIFFERENT LEVELS OF
TESTING
Testing Levels
•Unit testing
•Integration testing
•System testing
•Acceptance testing
Unit testing
The most ‘micro’ scale of testing.
Tests done on particular functions or code
modules.
Requires knowledge of the internal program
design and code.
Done by Programmers (not by testers).
Unit testing
Objectives To test the function of a program or unit of
code such as a program or module
To test internal logic
To verify internal design
To test path & conditions coverage
To test exception conditions & error
handling
When After modules are coded
Input Internal Application Design
Master Test Plan
Unit Test Plan
Output Unit Test Report
Incremental integration testing
Continuous testing of an application as and
when a new functionality is added.
Application’s functionality aspects are
required to be independent enough to work
separately before completion of development.
Done by programmers or testers.
Integration Testing
Testing of combined parts of an application to
determine their functional correctness.
‘Parts’ can be
• code modules
• individual applications
• client/server applications on a network.
Integration testing
Objectives To technically verify proper
interfacing between modules, and
within sub-systems
When After modules are unit tested
Input Internal & External Application
Design
Master Test Plan
Integration Test Plan
Output Integration Test report
SOFTWARE TESTING LIFECYCLE -
PHASES
• Requirements study
• Test Case Design and
Development
• Test Execution
• Test Closure
• Test Process Analysis
Requirements study
TestingCycle starts with the study of client’s
requirements.
Understanding of the requirements is very
essential for testing the product.
Analysis & Planning
• Test objective and coverage
• Overall schedule
• Standards and Methodologies
• Resources required, including necessary
training
• Roles and responsibilities of the team
members
• Tools used
Test Case Design and Development
•
Component Identification
•
Test Specification Design
•
Test Specification Review
Test Execution
•
Code Review
•
Test execution and evaluation
•
Performance and simulation
Test Closure
•
Test summary report
•
Project Documentation
Test Process Analysis
Analysis done on the reports and improving the
application’s performance by implementing new
technology and additional features.
TEST CASES
Test case is defined as
A set of test inputs, execution conditions and
expected results, developed for a particular
objective.
Documentation specifying inputs, predicted
results and a set of execution conditions for a test
item.
Specificinputs that will be tried and the
procedures that will be followed when the
software tested.
Sequence of one or more subtests executed as
a sequence as the outcome and/or final state of
one subtests is the input and/or initial state of
the next.
Specifies
the pretest state of the AUT and its
environment, the test inputs or conditions.
The expected result specifies what the AUT
should produce from the test inputs.
Thank You
