SlideShare a Scribd company logo
Verification and
Validation Testing

1
Verification and Validation
Requirements
review

Requirements
Functional
Specifications

Release
for use

Functional
Specs Review

Design

Code

Design
Review

Build
System
Build
Software
Code
Review

Acceptance
Testing
System
Testing

Integration
Testing
Unit
Testing

2
Verification and Validation
What is VV Model?
This Model is called a Verification and Validation
Model.
VV model is the classic software development model
and testing model.
For each phase, the subsequent phase becomes the
verification (QA) phase and the corresponding testing
phase in the other arm of the V becomes the
validating (QC) phase.
Testing of the product is planned in parallel with a
corresponding phase of development
3
Verification
 Verification also known as quality
assurance.
 Verification typically involves reviews and
meetings to evaluate documents, plans,
code, requirements and specifications.
 It determines of consistency, correctness
and completeness of Program at each
stage
 Verification checks whether we are building
the product right.
4
Verification
 Disciplined approach to evaluate whether a
software product fulfills the requirements or
conditions imposed on them.
 Are we doing the job right?
 Also called as static testing.
 Done by systematically reading the contents
of a software product with the intention of
detecting defects.
 Helps in identifying not only the defects but
also their location
5
Types of Verification
 Walkthrough – A step-by-step presentation by the author of
the document in order to gather information and to establish a
common understanding of its content.
 Inspection – A type of peer review that relies on visual
examination of documents to detect defects. This is the most
formal review technique and therefore always based on a
documented procedure.
 Technical Review – An evaluation of a product or project
status to ascertain discrepancies from planned results and to
recommend improvements.
 Audits:
 Internal: Done by the organization
 External: Done by people external to the organization to
check the standards and procedures of project

6
Walkthrough
 Meeting led by author
 Open-ended sessions
 To explain (knowledge transfer) and evaluate the
contents of the document
 To establish a common understanding of the
document
 The meeting is led by the authors; often a separate
scribe is present
 A walkthrough is especially useful for higher-level
documents, such as requirement specifications and
7
architectural documents.
Inspection










Led by trained moderator (not the author)
help the author to improve the quality of the
document under inspection
Formal process based on rules and checklists
Remove defects efficiently, as early as possible
Pre-meeting preparation
Improve product quality, by producing documents
with a higher level of quality
Formal follow-up process
learn from defects found and improve processes in
order to prevent similar defects

8
Technical Review
 It is often performed as a peer review
without management participation
 Ideally it is led by a trained moderator, but
possibly also by a technical expert.
 A separate preparation is carried out during
which the product is examined and the
defects are found.

9
Benefits of Verification
 Include early defect detection and
correction
 Development productivity
improvements
 Reduced development timescales
 Reduced testing time and cost
 Fewer defects and improved
communication
Validation
 Validation typically involves actual
testing and takes place after the
verifications are complete.
 Validation determines the
correctness of a final build with
respect to its requirements.
 Validation checks whether we are
building the right product.
11
Validation
 Disciplined approach to evaluate whether the final,
as built software product fulfills its specific intended
use
 Are we doing the right job?
 Also called as dynamic testing.
 Done by systematically testing a software product
with the intention of finding defects.
 Helps in identifying presence of the defects, not
their location

12
Levels Of Testing

Unit Testing
Integration Testing
System Testing
User Acceptance Testing
13
Unit Testing
 Unit - smallest testable piece of software.
 Unit testing is process of testing the smallest/
individual component of program.
 Unit test is a procedure used to validate that
individual unit of source code is working properly.
 Before entering into the unit testing it should be
gone through code review.
 Tests the functionality of units.
 Typically done by the developers and not by
testers.
 It is typically used to verify control flow, data flow
and memory leak problems.
14
Integration Testing
 Integration is a process of combining and testing
multiple components together.
 Starts at module level when various modules are
integrated with each other to form a system
 Considered interfaces on system
 Focuses on design and construction of software
architecture
 Approaches:
• Bottom Up
• Top Down
• Critical Part First
• Big Bang approach

15
What is Bottom Up Approach
 Process of testing the very lowest layers of
software first is called the bottom up
approach.
 Program is tested from bottom to the top.
 In this approach, programmers use a
temporary program instead of main
program, which is under construction.
 The temporary program is called “ Driver ”
or “ Calling Program” .
16
Bottom Up Approach
* In this approach first Child
Modules are developed.
* After that parent modules
are developed
* Then interconnect Child
Modules with Parent
Modules.
* In the interconnection
Process if there is any main
module is under construction
then the developers create
temporary program that is
called “Driver”.
17
What is Top Down approach
 Process of testing the top most layers of
software first is called the Top-Down
Approach.
 Programmers use temporary programs
called “stubs” instead of sub-programs,
which are under construction.
 The other name for stubs is “ Called
Programs ” .
 A stub returns the control to the main
program.”
18
Top down approach
*In this Approach first Parent
Modules are developed.
* After that Child Modules are
developed
* Then interconnect Parent &
Child Modules.
* In the interconnection
process is there any the submodule is under construction
then the developers create
temporary program Instead of
sub modules that is
called “Stub”.
19
Difference Between STUB &
DRIVER:
DRIVER

20
Hybrid Approach ( Critical Path
First)
First
 Also known as “Sandwich
approach” , this is a combination of
the Top-Down Approach & Bottom-Up
Approach process.
 Both Top-Down & Bottom-Up started
simultaneously and testing is built up
from both sides.
 It needs big team.
21
Hybrid approach

22
Big-Bang Approach
 It is also known as “System
Approach” .
 Big bang approach is the simplest
integration testing approach:
– All the modules are simply put together
and tested.
– This technique is used only for very small
systems.
23
Big-Bang Approach Issues
 Main issues with this approach:
– Errors might be detected very late in the
life-cycle of the project.
– If an error is found:
it is very difficult to localize the error
the error may potentially belong to any of the
modules being integrated.

– Debugging errors found during big bang
integration testing are very expensive to
fix.

24
Build
 An executable file of application which
is released from development team
 An integrated application with all
modules released by the development
team is called as a build.

25
Types Of System Testing
User Interface Testing
Usability Testing

Manual Support Testing

GUI/Behavioural Coverage
Error Handling Coverage

Functional Testing

Functionality Testing
Sanity Testing

Smoke Testing

Input Domain Coverage
Manipulation Coverage
Order Of Functionality
Back End Coverage

Non Functional
Testing
Localization Testing
Internationalization

Performance Testing

Recovery Testing

Load Testing

Compatibility Testing

Stress Testing

Configuration Testing

Data Volume Testing

Inter System Testing
Installation Testing

Parallel Testing 26
Security Testing
System Testing
 System testing is the testing of a finally
integrated product for compliance against user
requirements.
 After development of all required modules, the
development team releases a software build
to be tested on the System Testing
Environment.
 System testing is classified into 3 levels as
 Usability Testing
 Functional Testing (Black Box Testing
Techniques)
 Non Functional Testing

27
Usability Testing
 Also called as accessibility testing
 To check the ease of use for the user
 And how easy is to understand the
application and process execution for the
user
 This Usability testing consists of two SubTechniques:
a) User – Interface Testing
b) Manual Support Testing

28
User Interface testing

29
Functional Testing
 Testing team concentrates on customer
requirements in terms of functionality.
 Concentrating on requirements correctness
and completeness.
 This testing is classified into 2 sub tests as
follows:
–
–
–

Functionality Testing
Sanity testing
Smoke testing
30
Functionality testing
 Also called as Requirement Testing.
 Concentrates on correctness of every
functionality with respect to
requirements.
 Process of verifying whether product
meets its design and functional
specifications
31
Functionality Testing
 Validating the correctness of every functionality
through below coverage’s:
 GUI coverage or Behavioral coverage (valid
changes in properties of objects and windows in our
application build).
 Error handling coverage (the prevention of
wrong operations with meaningful error messages
like displaying a message before closing a file
without saving it).
 Input Domain coverage (the validity of i/p
values in terms of size and type like while giving
alphabets to age field).

32
Functionality Testing
 Manipulations coverage (the
correctness of o/p or outcomes).
 Order of functionalities (the existence of
functionality w.r.t. customer requirements).
 Back end coverage (the impact of front
end’s screen operation on back end’s table
content in corresponding functionality).

33
Smoke Testing
 Also called as Basic functional testing.
 Checking the testability of the
software.
 Shallow and wide approach of testing.
 Each major function of the software is
tested without bothering finer details.
34
Sanity Testing
 Also called as Narrow regression
testing.
 Checking the behavior of the software.
 Narrow and depth approach of testing.
 One or few parts of the system is
tested without going into depth.
35
Non-Functionality Testing
 Testing team concentrates on characteristics of
S/W.
• Recovery Testing
• Compatibility Testing
• Configuration Testing
• Inter system Testing
• Installation Testing
• Performance Testing
• Load Testing
• Stress Testing
• Data Volume Testing
• Parallel Testing
• Security testing

36
Installation Testing
 Checks the installing and uninstalling
of the s/w in customer site.

37
Performance Testing
 Checks the response time of
application.
 Performance means that speed of the
processing.

38
Load Testing
Also called as scalability testing
Tests the performance of an application on loading
the system with max users at same time. Ex:
websites, yahoo—G-mail.
 Load or Scale means that the number of concurrent
users (at the same time) who are operating a s/w.
 The execution of our s/w build under customer
expected configuration and customer expected load
to estimate the performance is LOAD TESTING.
(Inputs are customer expected configuration and
output is performance).



39
Stress Testing
 The execution of our s/w build under
customer expected configuration and
various load levels to estimate Stability
or continuity is called Stress Testing.
 Checks how the system can behave
under extremes such as insufficient
memory, inadequate hardware etc.
40
Volume Testing
 It’s also known as storage testing or
memory testing.
 Find weaknesses in the system with respect
to its handling of large amounts of data
during short time periods.
 For example, this kind of testing ensures
that the system will process data across
physical and logical boundaries such as
across servers and across disk partitions on
one server.
41
Parallel testing
 It is also known as comparative or
competitive testing.
 Comparison of two different systems.
(old version vs. new version)
 Compares with the competitive
software in market to estimate
competitiveness.
 Applicable to S/W product only.
42
Security Testing
 It is also known as Penetration testing.
 During this the testing team is validating for:

– Authorization: Access to the valid user
and Deny to the invalid users
– Access control: Giving access
permissions to the valid users to use specific
services like features or functionalities in s/w.
– Encryption or Decryption: Deny to third
party access to enter into the system. Code
conversion is in between client process and
server process.

43
Availability Testing
 Availability testing is running an application
for a planned period, and collecting failure
events with repair times.
 It is conducted to check both reliability
(finding defects and reducing the number of
failures) and availability (measuring and
minimizing the actual repair time) of an
application.
44
Internationalization Testing
 Checks the compatibility of an application to all
possible languages.
 Internationalization is the process of designing a
software application so that it can be adapted to
various languages and regions without engineering
changes.
 Globalization testing is the testing technique that
ensures compatibility of an application to all
possible languages

45
Localization Testing
 Localization is the process of adapting a
globalized application to a particular
culture/locale.
 Localization is the process of customizing a
software application that was originally
designed for a domestic market so that it
can be released in foreign markets.

46
Other Types of Testing
 Mutation testing
 Progression Testing
 Re-Testing
 Regression Testing
 Sanity Testing
 Smoke testing
47
Mutation testing
 Introducing the known defects in the
software to check the effectiveness of
testing process.
 Mutation means a change in a
program. Programmers are performing
changes in tested program to estimate
completeness and correctness of that
program testing.
48
Progression Testing and
retesting
 Execute the test cases for the first
time, it is called progression testing.
 Re-executing all the failed test cases
to check fixing done by development
team is really fixed or not as called as
retesting.

49
Regression Testing

50
Regression Testing
 Ensuring that a bug is fixed without any side
effects is called Regression Testing.
 The Re-Execution of selected test cases on
modified build to estimate completeness
and correctness of the application without
any ripple effects due to bug fixes

51
User Acceptance Testing
 Both testers and developers are involved
 After completion of system testing, the
project management concentrates on UAT
to collect feed back from real customer or
model customer.
 There are 2 ways to conduct UAT.
• Alpha Testing
• Beta Testing

52
Alpha Testing and Beta
Testing
Alpha Testing
Performed by end users inside
the development organization.

Beta Testing

Done in controlled environment

Performed by end users outside
the development organization
and inside the end user
organization.
Environment is not under control

Defects found by end users are
noted down by the development
team and fixed before release

Defects found by end users are
reported to the development
organization

Developers are present

Developers are not present

53
Ad-hoc Testing or informal

Testing

 In general, every testing team conducts
planned testing, but testing team adopts
informal testing sometimes due to some
challenges or risks.
E.g : Lack of time, lack of resources, lack of
team size, lack of skill, etc.
 There are different ways of Ad-hoc testing.

54
Ways of Adhoc Testing
 Monkey Testing

Due to lack of time, the testing team
concentrates on some of the main activities in the
software build for testing. This style of testing is
known as “Monkey testing” or “Chimpanzee
testing” or “Gorilla testing” .

 Buddy Testing

Due to lack of time, the management groups
programmers & testers as “Buddies” . Every buddy
group consists of programmers & testers.
E.g.: 1:1 (or) 2:1 (or) 3:1 (preferable)
55
Ways of Adhoc Testing
 Exploratory Testing
Due to lack of proper documentation of
the software being built, the test engineers
depend on past experience, discuss with
others, browse the Internet or Operate similar
projects and contact customer side people if
possible. This style of testing is called
“Exploratory Testing”.
Ways of Adhoc Testing
 Pair Testing

Due to lack of knowledge on project domain the
management groups a senior tester & a Junior
Programmers and conducted testing, these all are
called Pair testing.

 Defect Seeding
To estimate the efficiency of test engineers,
the programmers add some bugs to the build.
This task is called defect seeding / debugging.
57
Question














What is VV model ?
Difference between Verification and Validation?
What is Walkthrough and Inspection?
How many basic types of testing are there and what is the difference ?
Which are the different approaches in Integration testing ?
What are the different coverage in functional testing ?
What is alpha and beta testing?
What is stub and driver ?
What is functionality testing ?
What is Load and stress testing . Explain with example?
Difference between smoke and sanity testing ?
Difference between re-testing and regression testing ?
What is ad-hoc testing ?
Contact Us
Address
MindScripts Technologies,
2nd Floor, Siddharth Hall,
Near Ranka Jewellers,
Behind HP Petrol Pump,
Karve Rd,
Pune 411004
Call
9595957557
8805674210
9764560238
9767427924
9881371828

Address
MindScripts Technologies,
C8, 2nd Floor, Sant Tukaram Complex ,
Pradhikaran, Above Savali Hotel,
Opp Nigdi Bus Stand,
Nigdi,
Pune - 411044
www.mindscripts.com
info@mindscripts.com

More Related Content

PPTX
Software testing
PPT
Test Levels & Techniques
PPTX
Software Testing
PPS
Test Process
PPT
Testing Metrics
PDF
software testing and quality assurance .pdf
PPTX
Unit 1 basic concepts of testing & quality
PPTX
Software testing and process
Software testing
Test Levels & Techniques
Software Testing
Test Process
Testing Metrics
software testing and quality assurance .pdf
Unit 1 basic concepts of testing & quality
Software testing and process

What's hot (20)

PPTX
Software Engineering- Types of Testing
PPT
Manual testing concepts course 1
PPTX
Intro to Manual Testing
PDF
Software testing
PDF
Software testing
PPT
Automated Testing with Agile
PPT
Testing fundamentals
PPT
Software Testing Process
PPTX
Unit Testing And Mocking
PPTX
Agile Testing: The Role Of The Agile Tester
PDF
Software Testing Life Cycle (STLC) | Software Testing Tutorial | Edureka
DOC
Manual Testing Notes
PPTX
An Introduction to Unit Testing
PPT
Testing concepts ppt
PPTX
Fundamentals of testing
PPTX
Software Testing or Quality Assurance
PPTX
7 testing principles
PDF
Manual Testing
PPTX
Quality Assurance and Software Testing
Software Engineering- Types of Testing
Manual testing concepts course 1
Intro to Manual Testing
Software testing
Software testing
Automated Testing with Agile
Testing fundamentals
Software Testing Process
Unit Testing And Mocking
Agile Testing: The Role Of The Agile Tester
Software Testing Life Cycle (STLC) | Software Testing Tutorial | Edureka
Manual Testing Notes
An Introduction to Unit Testing
Testing concepts ppt
Fundamentals of testing
Software Testing or Quality Assurance
7 testing principles
Manual Testing
Quality Assurance and Software Testing
Ad

Viewers also liked (16)

PPTX
Software testing ppt
PDF
Software testing methods, levels and types
PPT
Software Testing Fundamentals
PPSX
Introduction to software testing
PPT
testing strategies and tactics
PPTX
Software engineering- system testing
PPT
Ch22
PPTX
Multidimensional data models
PPTX
Multi dimensional model vs (1)
PPT
Multidimensional Database Design & Architecture
PPT
Manual testing ppt
PDF
Multidimentional data model
PPT
Verification & Validation
PPTX
verification and validation
PPTX
Software Testing Basics
Software testing ppt
Software testing methods, levels and types
Software Testing Fundamentals
Introduction to software testing
testing strategies and tactics
Software engineering- system testing
Ch22
Multidimensional data models
Multi dimensional model vs (1)
Multidimensional Database Design & Architecture
Manual testing ppt
Multidimentional data model
Verification & Validation
verification and validation
Software Testing Basics
Ad

Similar to Software Testing Tutorials - MindScripts Technologies, Pune (20)

PPTX
Software Testing Strategies ,Validation Testing and System Testing.
PPT
PDF
Testing Interview Questions.pdf
PPTX
Verification and Validation in Manual Testing
ODP
QA Process Overview
PDF
Manual Testing software testing all slide
PDF
manualtesting-170218090020 (1).pdf
PPT
Software Engineering (Testing Overview)
PDF
Software Testing.pdf
DOCX
Softwaretestingstrategies
PPT
Software Testing Presentation in Cegonsoft Pvt Ltd...
PPT
Testing strategies
PPT
Unit 4 chapter 22 - testing strategies.ppt
PPT
Innovative Approaches to Software Dev go the hell
PPT
Testing strategies in Software Engineering
PPT
SOFTWARE ENGINEERING unit4-1 CLASS notes in pptx 2nd year
PPTX
Types of testing
PPTX
CTFL Module 02
PPTX
software testing technique
PPTX
Software Testing
Software Testing Strategies ,Validation Testing and System Testing.
Testing Interview Questions.pdf
Verification and Validation in Manual Testing
QA Process Overview
Manual Testing software testing all slide
manualtesting-170218090020 (1).pdf
Software Engineering (Testing Overview)
Software Testing.pdf
Softwaretestingstrategies
Software Testing Presentation in Cegonsoft Pvt Ltd...
Testing strategies
Unit 4 chapter 22 - testing strategies.ppt
Innovative Approaches to Software Dev go the hell
Testing strategies in Software Engineering
SOFTWARE ENGINEERING unit4-1 CLASS notes in pptx 2nd year
Types of testing
CTFL Module 02
software testing technique
Software Testing

Recently uploaded (20)

PPTX
Open Quiz Monsoon Mind Game Final Set.pptx
PDF
English Language Teaching from Post-.pdf
PPTX
Pharmacology of Heart Failure /Pharmacotherapy of CHF
PPTX
Nursing Management of Patients with Disorders of Ear, Nose, and Throat (ENT) ...
PDF
PSYCHOLOGY IN EDUCATION.pdf ( nice pdf ...)
PPTX
Onica Farming 24rsclub profitable farm business
PDF
Origin of periodic table-Mendeleev’s Periodic-Modern Periodic table
PDF
Business Ethics Teaching Materials for college
PDF
O7-L3 Supply Chain Operations - ICLT Program
PPTX
Introduction and Scope of Bichemistry.pptx
PDF
Anesthesia in Laparoscopic Surgery in India
PPTX
Renaissance Architecture: A Journey from Faith to Humanism
PDF
O5-L3 Freight Transport Ops (International) V1.pdf
PDF
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
PDF
102 student loan defaulters named and shamed – Is someone you know on the list?
DOCX
UPPER GASTRO INTESTINAL DISORDER.docx
PPTX
Cell Structure & Organelles in detailed.
PPTX
UNDER FIVE CLINICS OR WELL BABY CLINICS.pptx
PDF
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
PDF
From loneliness to social connection charting
Open Quiz Monsoon Mind Game Final Set.pptx
English Language Teaching from Post-.pdf
Pharmacology of Heart Failure /Pharmacotherapy of CHF
Nursing Management of Patients with Disorders of Ear, Nose, and Throat (ENT) ...
PSYCHOLOGY IN EDUCATION.pdf ( nice pdf ...)
Onica Farming 24rsclub profitable farm business
Origin of periodic table-Mendeleev’s Periodic-Modern Periodic table
Business Ethics Teaching Materials for college
O7-L3 Supply Chain Operations - ICLT Program
Introduction and Scope of Bichemistry.pptx
Anesthesia in Laparoscopic Surgery in India
Renaissance Architecture: A Journey from Faith to Humanism
O5-L3 Freight Transport Ops (International) V1.pdf
BÀI TẬP BỔ TRỢ 4 KỸ NĂNG TIẾNG ANH 9 GLOBAL SUCCESS - CẢ NĂM - BÁM SÁT FORM Đ...
102 student loan defaulters named and shamed – Is someone you know on the list?
UPPER GASTRO INTESTINAL DISORDER.docx
Cell Structure & Organelles in detailed.
UNDER FIVE CLINICS OR WELL BABY CLINICS.pptx
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
From loneliness to social connection charting

Software Testing Tutorials - MindScripts Technologies, Pune

  • 2. Verification and Validation Requirements review Requirements Functional Specifications Release for use Functional Specs Review Design Code Design Review Build System Build Software Code Review Acceptance Testing System Testing Integration Testing Unit Testing 2
  • 3. Verification and Validation What is VV Model? This Model is called a Verification and Validation Model. VV model is the classic software development model and testing model. For each phase, the subsequent phase becomes the verification (QA) phase and the corresponding testing phase in the other arm of the V becomes the validating (QC) phase. Testing of the product is planned in parallel with a corresponding phase of development 3
  • 4. Verification  Verification also known as quality assurance.  Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications.  It determines of consistency, correctness and completeness of Program at each stage  Verification checks whether we are building the product right. 4
  • 5. Verification  Disciplined approach to evaluate whether a software product fulfills the requirements or conditions imposed on them.  Are we doing the job right?  Also called as static testing.  Done by systematically reading the contents of a software product with the intention of detecting defects.  Helps in identifying not only the defects but also their location 5
  • 6. Types of Verification  Walkthrough – A step-by-step presentation by the author of the document in order to gather information and to establish a common understanding of its content.  Inspection – A type of peer review that relies on visual examination of documents to detect defects. This is the most formal review technique and therefore always based on a documented procedure.  Technical Review – An evaluation of a product or project status to ascertain discrepancies from planned results and to recommend improvements.  Audits:  Internal: Done by the organization  External: Done by people external to the organization to check the standards and procedures of project 6
  • 7. Walkthrough  Meeting led by author  Open-ended sessions  To explain (knowledge transfer) and evaluate the contents of the document  To establish a common understanding of the document  The meeting is led by the authors; often a separate scribe is present  A walkthrough is especially useful for higher-level documents, such as requirement specifications and 7 architectural documents.
  • 8. Inspection         Led by trained moderator (not the author) help the author to improve the quality of the document under inspection Formal process based on rules and checklists Remove defects efficiently, as early as possible Pre-meeting preparation Improve product quality, by producing documents with a higher level of quality Formal follow-up process learn from defects found and improve processes in order to prevent similar defects 8
  • 9. Technical Review  It is often performed as a peer review without management participation  Ideally it is led by a trained moderator, but possibly also by a technical expert.  A separate preparation is carried out during which the product is examined and the defects are found. 9
  • 10. Benefits of Verification  Include early defect detection and correction  Development productivity improvements  Reduced development timescales  Reduced testing time and cost  Fewer defects and improved communication
  • 11. Validation  Validation typically involves actual testing and takes place after the verifications are complete.  Validation determines the correctness of a final build with respect to its requirements.  Validation checks whether we are building the right product. 11
  • 12. Validation  Disciplined approach to evaluate whether the final, as built software product fulfills its specific intended use  Are we doing the right job?  Also called as dynamic testing.  Done by systematically testing a software product with the intention of finding defects.  Helps in identifying presence of the defects, not their location 12
  • 13. Levels Of Testing Unit Testing Integration Testing System Testing User Acceptance Testing 13
  • 14. Unit Testing  Unit - smallest testable piece of software.  Unit testing is process of testing the smallest/ individual component of program.  Unit test is a procedure used to validate that individual unit of source code is working properly.  Before entering into the unit testing it should be gone through code review.  Tests the functionality of units.  Typically done by the developers and not by testers.  It is typically used to verify control flow, data flow and memory leak problems. 14
  • 15. Integration Testing  Integration is a process of combining and testing multiple components together.  Starts at module level when various modules are integrated with each other to form a system  Considered interfaces on system  Focuses on design and construction of software architecture  Approaches: • Bottom Up • Top Down • Critical Part First • Big Bang approach 15
  • 16. What is Bottom Up Approach  Process of testing the very lowest layers of software first is called the bottom up approach.  Program is tested from bottom to the top.  In this approach, programmers use a temporary program instead of main program, which is under construction.  The temporary program is called “ Driver ” or “ Calling Program” . 16
  • 17. Bottom Up Approach * In this approach first Child Modules are developed. * After that parent modules are developed * Then interconnect Child Modules with Parent Modules. * In the interconnection Process if there is any main module is under construction then the developers create temporary program that is called “Driver”. 17
  • 18. What is Top Down approach  Process of testing the top most layers of software first is called the Top-Down Approach.  Programmers use temporary programs called “stubs” instead of sub-programs, which are under construction.  The other name for stubs is “ Called Programs ” .  A stub returns the control to the main program.” 18
  • 19. Top down approach *In this Approach first Parent Modules are developed. * After that Child Modules are developed * Then interconnect Parent & Child Modules. * In the interconnection process is there any the submodule is under construction then the developers create temporary program Instead of sub modules that is called “Stub”. 19
  • 20. Difference Between STUB & DRIVER: DRIVER 20
  • 21. Hybrid Approach ( Critical Path First) First  Also known as “Sandwich approach” , this is a combination of the Top-Down Approach & Bottom-Up Approach process.  Both Top-Down & Bottom-Up started simultaneously and testing is built up from both sides.  It needs big team. 21
  • 23. Big-Bang Approach  It is also known as “System Approach” .  Big bang approach is the simplest integration testing approach: – All the modules are simply put together and tested. – This technique is used only for very small systems. 23
  • 24. Big-Bang Approach Issues  Main issues with this approach: – Errors might be detected very late in the life-cycle of the project. – If an error is found: it is very difficult to localize the error the error may potentially belong to any of the modules being integrated. – Debugging errors found during big bang integration testing are very expensive to fix. 24
  • 25. Build  An executable file of application which is released from development team  An integrated application with all modules released by the development team is called as a build. 25
  • 26. Types Of System Testing User Interface Testing Usability Testing Manual Support Testing GUI/Behavioural Coverage Error Handling Coverage Functional Testing Functionality Testing Sanity Testing Smoke Testing Input Domain Coverage Manipulation Coverage Order Of Functionality Back End Coverage Non Functional Testing Localization Testing Internationalization Performance Testing Recovery Testing Load Testing Compatibility Testing Stress Testing Configuration Testing Data Volume Testing Inter System Testing Installation Testing Parallel Testing 26 Security Testing
  • 27. System Testing  System testing is the testing of a finally integrated product for compliance against user requirements.  After development of all required modules, the development team releases a software build to be tested on the System Testing Environment.  System testing is classified into 3 levels as  Usability Testing  Functional Testing (Black Box Testing Techniques)  Non Functional Testing 27
  • 28. Usability Testing  Also called as accessibility testing  To check the ease of use for the user  And how easy is to understand the application and process execution for the user  This Usability testing consists of two SubTechniques: a) User – Interface Testing b) Manual Support Testing 28
  • 30. Functional Testing  Testing team concentrates on customer requirements in terms of functionality.  Concentrating on requirements correctness and completeness.  This testing is classified into 2 sub tests as follows: – – – Functionality Testing Sanity testing Smoke testing 30
  • 31. Functionality testing  Also called as Requirement Testing.  Concentrates on correctness of every functionality with respect to requirements.  Process of verifying whether product meets its design and functional specifications 31
  • 32. Functionality Testing  Validating the correctness of every functionality through below coverage’s:  GUI coverage or Behavioral coverage (valid changes in properties of objects and windows in our application build).  Error handling coverage (the prevention of wrong operations with meaningful error messages like displaying a message before closing a file without saving it).  Input Domain coverage (the validity of i/p values in terms of size and type like while giving alphabets to age field). 32
  • 33. Functionality Testing  Manipulations coverage (the correctness of o/p or outcomes).  Order of functionalities (the existence of functionality w.r.t. customer requirements).  Back end coverage (the impact of front end’s screen operation on back end’s table content in corresponding functionality). 33
  • 34. Smoke Testing  Also called as Basic functional testing.  Checking the testability of the software.  Shallow and wide approach of testing.  Each major function of the software is tested without bothering finer details. 34
  • 35. Sanity Testing  Also called as Narrow regression testing.  Checking the behavior of the software.  Narrow and depth approach of testing.  One or few parts of the system is tested without going into depth. 35
  • 36. Non-Functionality Testing  Testing team concentrates on characteristics of S/W. • Recovery Testing • Compatibility Testing • Configuration Testing • Inter system Testing • Installation Testing • Performance Testing • Load Testing • Stress Testing • Data Volume Testing • Parallel Testing • Security testing 36
  • 37. Installation Testing  Checks the installing and uninstalling of the s/w in customer site. 37
  • 38. Performance Testing  Checks the response time of application.  Performance means that speed of the processing. 38
  • 39. Load Testing Also called as scalability testing Tests the performance of an application on loading the system with max users at same time. Ex: websites, yahoo—G-mail.  Load or Scale means that the number of concurrent users (at the same time) who are operating a s/w.  The execution of our s/w build under customer expected configuration and customer expected load to estimate the performance is LOAD TESTING. (Inputs are customer expected configuration and output is performance).   39
  • 40. Stress Testing  The execution of our s/w build under customer expected configuration and various load levels to estimate Stability or continuity is called Stress Testing.  Checks how the system can behave under extremes such as insufficient memory, inadequate hardware etc. 40
  • 41. Volume Testing  It’s also known as storage testing or memory testing.  Find weaknesses in the system with respect to its handling of large amounts of data during short time periods.  For example, this kind of testing ensures that the system will process data across physical and logical boundaries such as across servers and across disk partitions on one server. 41
  • 42. Parallel testing  It is also known as comparative or competitive testing.  Comparison of two different systems. (old version vs. new version)  Compares with the competitive software in market to estimate competitiveness.  Applicable to S/W product only. 42
  • 43. Security Testing  It is also known as Penetration testing.  During this the testing team is validating for: – Authorization: Access to the valid user and Deny to the invalid users – Access control: Giving access permissions to the valid users to use specific services like features or functionalities in s/w. – Encryption or Decryption: Deny to third party access to enter into the system. Code conversion is in between client process and server process. 43
  • 44. Availability Testing  Availability testing is running an application for a planned period, and collecting failure events with repair times.  It is conducted to check both reliability (finding defects and reducing the number of failures) and availability (measuring and minimizing the actual repair time) of an application. 44
  • 45. Internationalization Testing  Checks the compatibility of an application to all possible languages.  Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes.  Globalization testing is the testing technique that ensures compatibility of an application to all possible languages 45
  • 46. Localization Testing  Localization is the process of adapting a globalized application to a particular culture/locale.  Localization is the process of customizing a software application that was originally designed for a domestic market so that it can be released in foreign markets. 46
  • 47. Other Types of Testing  Mutation testing  Progression Testing  Re-Testing  Regression Testing  Sanity Testing  Smoke testing 47
  • 48. Mutation testing  Introducing the known defects in the software to check the effectiveness of testing process.  Mutation means a change in a program. Programmers are performing changes in tested program to estimate completeness and correctness of that program testing. 48
  • 49. Progression Testing and retesting  Execute the test cases for the first time, it is called progression testing.  Re-executing all the failed test cases to check fixing done by development team is really fixed or not as called as retesting. 49
  • 51. Regression Testing  Ensuring that a bug is fixed without any side effects is called Regression Testing.  The Re-Execution of selected test cases on modified build to estimate completeness and correctness of the application without any ripple effects due to bug fixes 51
  • 52. User Acceptance Testing  Both testers and developers are involved  After completion of system testing, the project management concentrates on UAT to collect feed back from real customer or model customer.  There are 2 ways to conduct UAT. • Alpha Testing • Beta Testing 52
  • 53. Alpha Testing and Beta Testing Alpha Testing Performed by end users inside the development organization. Beta Testing Done in controlled environment Performed by end users outside the development organization and inside the end user organization. Environment is not under control Defects found by end users are noted down by the development team and fixed before release Defects found by end users are reported to the development organization Developers are present Developers are not present 53
  • 54. Ad-hoc Testing or informal Testing  In general, every testing team conducts planned testing, but testing team adopts informal testing sometimes due to some challenges or risks. E.g : Lack of time, lack of resources, lack of team size, lack of skill, etc.  There are different ways of Ad-hoc testing. 54
  • 55. Ways of Adhoc Testing  Monkey Testing Due to lack of time, the testing team concentrates on some of the main activities in the software build for testing. This style of testing is known as “Monkey testing” or “Chimpanzee testing” or “Gorilla testing” .  Buddy Testing Due to lack of time, the management groups programmers & testers as “Buddies” . Every buddy group consists of programmers & testers. E.g.: 1:1 (or) 2:1 (or) 3:1 (preferable) 55
  • 56. Ways of Adhoc Testing  Exploratory Testing Due to lack of proper documentation of the software being built, the test engineers depend on past experience, discuss with others, browse the Internet or Operate similar projects and contact customer side people if possible. This style of testing is called “Exploratory Testing”.
  • 57. Ways of Adhoc Testing  Pair Testing Due to lack of knowledge on project domain the management groups a senior tester & a Junior Programmers and conducted testing, these all are called Pair testing.  Defect Seeding To estimate the efficiency of test engineers, the programmers add some bugs to the build. This task is called defect seeding / debugging. 57
  • 58. Question              What is VV model ? Difference between Verification and Validation? What is Walkthrough and Inspection? How many basic types of testing are there and what is the difference ? Which are the different approaches in Integration testing ? What are the different coverage in functional testing ? What is alpha and beta testing? What is stub and driver ? What is functionality testing ? What is Load and stress testing . Explain with example? Difference between smoke and sanity testing ? Difference between re-testing and regression testing ? What is ad-hoc testing ?
  • 59. Contact Us Address MindScripts Technologies, 2nd Floor, Siddharth Hall, Near Ranka Jewellers, Behind HP Petrol Pump, Karve Rd, Pune 411004 Call 9595957557 8805674210 9764560238 9767427924 9881371828 Address MindScripts Technologies, C8, 2nd Floor, Sant Tukaram Complex , Pradhikaran, Above Savali Hotel, Opp Nigdi Bus Stand, Nigdi, Pune - 411044 www.mindscripts.com [email protected]

Editor's Notes

  • #5: STCT Book - Page 11
  • #12: STCT Book - Page 12
  • #22: Critical Path Analysis is the longest path of planned activities executed in the Shortest Duration to the end of the project.