Professional Documents
Culture Documents
Contents
SOFTWARE TESTING 2 / 50
Contents
• Requirement Management
• Configuration Management
• Software Testing Fundamentals
• Testing Policy Vs Quality Policy
• Testing Economics and Testing Cost
• Testing Levels
• Testing Techniques
SOFTWARE TESTING 3 / 50
Contents
SOFTWARE TESTING 4 / 50
Software Testing
STATIC DYNAMIC
Logical Errors
Structural Testing Functional Testing
SOFTWARE TESTING 5 / 50
• Testing
A Process of evaluating a particular
product to determine whether the product contain
any defects
• Software Testing
SOFTWARE TESTING 6 / 50
• Why Software Testing ?
Error Free
Efficient
Secured
Flexible
SOFTWARE TESTING 7 / 50
QUALITY PRINCIPLES
Quality is defined as meeting the Customer’s
requirements in the First time and Every time.
SOFTWARE TESTING 8 / 50
Software Quality
• Critical Quality • Other Attributes
– Completeness
Attributes – Compatibility
– Portability
– Maintainability – Internationalization
– Understandability
– Dependability
– Scalability
– Efficiency
– Robustness
– Usability – Testability
– Reusability
– Customizability
SOFTWARE TESTING 9 / 50
Five perspective of quality
• 1. Transcendent-I know when I see it.
• 2. Product based- possesses desired
features
• 3. User based – Fitness for use.
• 4. Development and manufacturing based –
Confirms to requirements.
• 5. Value based – At an acceptable cost.
SOFTWARE TESTING 10 / 50
Why Quality?
SOFTWARE TESTING 11 / 50
Cost of Quality
• The three categories of costs associated with
producing quality products are
SOFTWARE TESTING 14 / 50
Software Process
• Process – Projects – Products
A software process specifies a method of
developing software.
A software project, on the other hand, is a
development project in which a software
process is used.
A Software product is the outcome of a
software project.
SOFTWARE TESTING 15 / 50
PLAN Planning & Designing
Necessary Actions
ACT DO
CHECK
Testing & Evaluating
SOFTWARE TESTING 16 / 50
• Plan : Device a plan. Define your objective and
determine and strategy and supporting methods
required to achieve that objective.
SOFTWARE TESTING 17 / 50
SDLC
(SOFTWARE DEVELOPMENT
LIFE CYCLE)
SOFTWARE TESTING 18 / 50
Agenda
• Team Organization Deliverable Turn-in
– Project Assignments to be posted on the web-
site
• Introduction to Software Development
Activities
• Survey of Lifecycle Models
SOFTWARE TESTING 19 / 50
Software Engineering
• Layered Technology
– Key Process Areas
Tools
Methods
Process
Quality
SOFTWARE TESTING 20 / 50
Capability Maturity Model
• Developed by SEI(Software Engineering
Integration)
• Five Process Maturity Levels
– Level 0: Chaos
– Level 1: Initial
– Level 2: Repeatable
– Level 3: Defined
– Level 4: Managed
– Level 5: Optimizing
SOFTWARE TESTING 21 / 50
Process Principles
• Prescribes all major activities
• Uses resources, within a set of constraints, to
produce intermediate and final products
• May be composed of sub-processes
• Each activity has entry and exit criteria
• Activities are organized in a sequence
• Has a set of guiding principles to explain goals
• Constraints may apply to activity, resource or
product
SOFTWARE TESTING 22 / 50
• The six Stages of SDLC process are
Requirement Analysis
Design
Development
Testing
Implementation
Maintenance
SOFTWARE TESTING 23 / 50
Requirement Analysis
• Study done by organization against customer’s
requirement is documented as SRAS( software
requirement analysis specification)
Design Process
Low Level Design
High Level Design
HCD LLD
SOFTWARE TESTING 25 / 50
HLD
• High-Level Design (system Design)
SOFTWARE TESTING 26 / 50
LLD
• Low Level Design (Detailed Design)
SOFTWARE TESTING 27 / 50
Coding and unit testing
SOFTWARE TESTING 28 / 50
Testing
• Unit testing
• STATIC(Reviewing)
• Integration testing • DYNAMIC (Execution)
• System testing
SOFTWARE TESTING 29 / 50
Integration testing
SOFTWARE TESTING 30 / 50
System Testing
SOFTWARE TESTING 31 / 50
Acceptance and Installation
SOFTWARE TESTING 32 / 50
Project Management
• Project Management is nothing but
organising, Planning,ans scheduling
software projects.
– Project staffing
– Project planning
– Project scheduling
– Project monitoring
SOFTWARE TESTING 33 / 50
Risk Management
Software Risks
SOFTWARE TESTING 34 / 50
Requirements Management
• Requirements management is managing changes
in the evolving software in a cost effective
manner. Changes may come externally or
internally.
• External changes may be due to
problem,customer, environment.
• Internal changes may be due to requirements,
design, implementation, testing, maintenance
SOFTWARE TESTING 35 / 50
Configuration Management
• Standards and procedures for managing changes in
an evolving software product is configuration
management.
• New versions of software systems are created as
they change for different machines/OS, offering
different functionality.
• Software systems are sometimes called baselines
as they are a starting point for further
development.
SOFTWARE TESTING 36 / 50
Verification and release
management
• Invent identification scheme for system
versions plan when new system version is to
be produced. Ensure that version
management procedures and tools and
properly applied. Plan and distribute new
system releases.
SOFTWARE TESTING 37 / 50
version/variants/releases
• Version : An instance of a system, which is
functionally distinct in some way from
other system instances.
• Variant: An instance of a system, which is
functionally identical but non-functionally
distinct from other instances of a system.
• Release : An instance of a system, which is
distributed to users outside of the
development team.
SOFTWARE TESTING 38 / 50
Version derivation structure
V 1.1b V 1.1.1
V 1.1a
SOFTWARE TESTING 39 / 50
Software Testing Fundamentals
• Primary role of software testing?
SOFTWARE TESTING 40 / 50
STF
• What is Defects ?
– The purpose of testing is to find defects. A
defect is a variance from a desired product
attribute. Two categories of defects are
1. Variance from product specifications.
SOFTWARE TESTING 41 / 50
Defects
• 1. Wrong : The specifications have been implemented
incorrectly. This defect is a variance from customer / user
specification. (correctly mentioned in specification but
wrongly implemented)
• 2. Missing : A specified or wanted requirement is not in the
built product. This can be a variance from specification, an
indication that the specification was not implemented.
( given in specification but missed out in application)
• 3. Extra : A requirement incorporated into the product that
was not specified. This is always a variance from
specifications, but may the user of the product desire an
attribute. (any thing that dissatisfies)
SOFTWARE TESTING 42 / 50
Test case
• Set of procedures written by a tester which
execute in our system to find defect.
SOFTWARE TESTING 43 / 50
Testing Economics & Cost
Traditional Testing Continuous Testing
Accumulated Accumulated
SOFTWARE TESTING 44 / 50
TESTING LEVELS
• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing
SOFTWARE TESTING 45 / 50
Unit Testing
• Unit testing is a testing in which the
individual unit of the software are tested in
isolation from other parts of a program.
Advantage :
• To catch the defects that occurs at the early
stage of software development.
• To minimize the ration of defects before
moving to next level
SOFTWARE TESTING 46 / 50
Integration Testing
• Integration testing refers to the testing in
which software units of an application
combined and tested for a communication
interfaces between them.
SOFTWARE TESTING 47 / 50
Big Bang Testing
Module - 1
Module - 6 Module - 2
System
Module - 5 Module - 3
Module - 4
SOFTWARE TESTING 48 / 50
Big Bang Testing
• A type of integration in which software
components of an application are combined
all at once into a overall system according
to this approach
Advantage :
• To check the data flow from one module to
another
• Communication between various modules is
checked
SOFTWARE TESTING 49 / 50
Integration
• Bottom-up Integration testing :
In bottom up integration, all modules are added
or combined from lower level hierarchy to
higher level hierarchy I.e., the lower level
model is tested in isolation first, then the next
set of higher level modules are tested with the
previously tested lower modules.
• Worker modules are grouped into builds and
integrated.
SOFTWARE TESTING 50 / 50