Types of Testing

Quality Assurance /
Software Testing Training
Types of Testing , Test Strategy and Planning,
and Test Estimation Techniques

Classification: Restricted
Agenda
• Types of Testing
• Test Strategy and Planning,
• and Test Estimation Techniques

STLC (Software Testing Life Cycle)

Various Types of Testing
Functional testing
• Black box type testing geared to functional requirements of an
application.
• Done by testers.
System testing
• Black box type testing that is based on overall requirements
specifications; covering all combined parts of the system.
End-to-end testing
• Similar to system testing; involves testing of a complete application
environment in a situation that mimics real-world use.
Sanity testing
• Initial effort to determine if a new software version is performing well
enough to accept it for a major testing effort
Regression testing
• Re-testing after fixes or modifications of the software or its
environment

Acceptance testing
• Final testing based on specifications of the end-user or customer
Load testing
• Testing an application under heavy loads.
• Eg. Testing of a web site under a range of loads to determine, when the
system response time degraded or fails.
Install/uninstall testing
• Testing of full,partial or upgrade install/uninstall process.
Recovery testing
• Testing how well a system recovers from crashes, HW failures or other
problems.
Compatibility testing
• Testing how well software performs in a particular HW/SW/OS/NW
environment
Exploratory testing / ad-hoc testing
• Informal SW test that is not based on formal test plans or test cases;
testers will be learning the SW in totality as they test it.

Performance testing
Term often used interchangeably with ‘stress’ and ‘load’ testing. To check
whether system meets performance requirements. Used different
performance and load tools to do this.
Usability testing
User-friendliness check. Application flow is tested, Can new user understand
the application easily, Proper help documented whenever user stuck at any
point. Basically system navigation is checked in this testing .
Security testing
Can system be penetrated by any hacking way. Testing how well the system
protects against unauthorized internal or external access. Checked if system,
database is safe from external attacks.
Alpha testing
Testing done when development is nearing completion; minor design
changes may still be made as a result of such testing.
Beta-testing
Testing when development and testing are essentially completed and final
bugs and problems need to be found before release.

Start and Stop of Testing
• When to Start Testing?
• An early start to testing reduces the cost, time to rework and error free
software that is delivered to the client. However in Software Development
Life Cycle (SDLC) testing can be started from the Requirements Gathering
phase and lasts till the deployment of the software.
• For example in Water fall model formal testing is conducted in the Testing
phase, but in incremental model, testing is performed at the end of every
increment/iteration and at the end the whole application is tested.
• When to Stop Testing?
• Unlike when to start testing it is difficult to determine when to stop testing,
as testing is a never ending process and no one can say that any software is
100% tested.
• Following are the aspects which should be considered to stop the testing:
• Testing Deadlines.
• Completion of test case execution.
• Completion of Functional and code coverage to a certain point.
• Bug rate falls below a certain level and no high priority bugs are
identified.
• Management decision.

Test Strategy and Planning
Test Strategy
A test strategy is an outline that describes the testing approach of the
software development cycle This document defines “Software Testing
Approach” to achieve testing objectives. The Test Strategy is normally
Derived from the Business Requirement Specification document.
Some companies include the “Test Approach” or “Strategy” inside the Test
Plan, which is fine and it is usually the case for small projects. However, for
larger projects, there is one Test Strategy document and different number of
Test Plans for each phase or level of testing.

Test Strategy Document
• Scope and Objectives
• Business issues
• Roles and responsibilities
• Communication and status reporting
• Test deliverability
• Industry standards to follow
• Test automation and tools
• Testing measurements and metrices
• Risks and mitigation
• Defect reporting and tracking
• Change and configuration management
• Training plan

Test Planning
The Test Plan document on the other hand, is derived from the Product
Description, Software Requirement Specification SRS, or Use Case
Documents.
The Test Plan document is usually prepared by the Test Lead or Test
Manager and the focus of the document is to describe what to test, how to
test, when to test and who will do what test.
Objectives
• To create a set of testing tasks.
• Assign resources to each testing task.
• Estimate completion time for each testing task.
• Document testing standards.

Purpose of preparing a Test Plan
• Validate the acceptability of a software product.
• Help the people outside the test group to understand ‘why’ and ‘how’ of
product validation.
A Test Plan should be
• Thorough enough (Overall coverage of test to be conducted)
• Useful and understandable by the people inside and outside the test
group.

A document that describes the
• Introduction
• Scope
• Approach
• Resources
• Roles and Responsibilities
• Entry and Exit criteria
• Hardware and Software requirement
• Schedule
• Risk and Mitigation
• Tools to be used
• Deliverables
• References
• Annexure

Scope
• The areas to be tested by the QA team.
• Specify the areas which are out of scope (screens,database,
mainframe processes etc).
Test Approach
• Details on how the testing is to be performed.
• Any specific strategy is to be followed for testing (Including CM)
Entry Criteria
• Various steps to be performed before the start of a test i.e. Pre-
requisites.
E.g.
• Timely environment set up
• Starting the web server/app server
• Successful implementation of the latest build etc.
Resources
List of the people involved in the project and their designation etc.

Tasks/Responsibilities
• Tasks to be performed and responsibilities assigned to the various team
members.
Exit Criteria
• Contains tasks like Bringing down the system / server ,Restoring system
to pre-test environment, Database refresh etc.
Schedule / Milestones
• Deals with the final delivery date and the various milestones dates.
Hardware / Software Requirements
• Details of PC’s / servers required to install the application or perform
the testing
• Specific software to get the application running or to connect to the
database etc.

Risks & Mitigation Plans
• List out the possible risks during testing
• Mitigation plans to implement incase the risk actually turns into a
reality.
Tools to be used
• List the testing tools or utilities
Eg.WinRunner, LoadRunner, Test Director, Rational Robot, QTP, JIRA
etc
Deliverables
• Various deliverables due to the client at various points of time i.e.
Daily / weekly / start of the project end of the project etc.
• These include test plans, test procedures, test metric, status reports,
test scripts etc.

References
• Procedures
• Templates (Client specific or otherwise)
• Standards / Guidelines e.g. Qview
• Project related documents (RSD, ADD, FSD etc).
Annexure
• Links to documents which have been / will be used in the course of
testing
Eg. Templates used for reports, test cases etc.
• Referenced documents can also be attached here.
Sign-off
• Mutual agreement between the client and the QA Team.
• Both leads/managers signing their agreement on the Test Plan.

Test Estimation Techniques
Estimating effort for test is one of the major and important tasks in SDLC.
Correct estimation helps in testing the Software with maximum coverage.
This section describes some of the techniques which can be useful during
the estimating of effort for testing.
List of Different Estimation Techniques
• Best guess
• Ad-hoc method
• Experience Based - Analogies and experts
• WBS
• Delphi technique
• Three-point estimation (successive calculation)
• Function points / Test point Analysis

Best Guess
This technique is purely guesswork and based on the some sort of
experience.
The method is very common, but since it is based on your gut feeling, its
uncertainty contingency is probably around 200% or even higher.
Ad-hoc method
The test efforts are based on tentative timeframe. The timeline set by
managerial or marketing personnel or by client without any guess
/experience. Alternatively, it is done until the budgeted finances run out.
This is very common practice in extremely immature organizations and has
error margins of over 100% at times.

Experience Based:
Analogies and experts: Metrics collected from previous tests. You already
tested similar application in previous project .Inputs are taken from Subject
Matter experts who know the application (as well as testing) very well.
Delphi Technique:
This is one of the widely used software testing estimation technique.
In the Delphi Method is based on surveys and basically collects the
information from participants who are experts. In this estimation technique
each task is assigned to each team member & over multiple rounds surveys
are conduct unless & until a final estimation of task is not finalized. In each
round the thought about task are gathered & feedback is provided. By using
this method, you can get quantitative and qualitative results.
In overall techniques this technique gives good confidence in the
estimation. This technique can be used with the combination of the other
techniques.

Work Breakdown Structure (WBS):
A big project is made manageable by first breaking it down into individual
components in a hierarchical structure, known as the Work breakdown
structure, or the WBS.
The WBS helps to project manager and the team to create the task
scheduling, detailed cost estimation of the project. By using the WBS
motions, the project manager and team will have a pretty good idea
whether or not they’ve captured all the necessary tasks, based on the
project requirements, which are going to need to happen to get the job
done.
Using this you can easily figure out the what all task needs to completed &
they are breakdown into details task so estimation to details task would be
more easier than estimating overall Complex project at one shot.

Work Breakdown Structure has four key benefits:
• Work Breakdown Structure forces the team to create detailed steps:
In The WBS all steps required to build or deliver the service are divided into
detailed task by Project manager, Team and customer. It helps to raise the
critical issues early on, narrow down the scope of the project and create a
dialogue which will help make clear bring out assumptions, ambiguities, narrow
the scope of the project, and raise critical issues early on.
• Work Breakdown Structure help to improve the schedule and budget.
WBS enables you to make an effective schedule and good budget plans. As all
tasks are already available so it helps in generating a meaningful schedule and
makes scheming a reliable budget easier.
• Work Breakdown Structure creates accountability
The level of details task breakdown helps to assign particular module task to
individual, which makes easier to hold person accountable to complete the task.
Also the detailed task in WBS, people cannot allow hiding under the “cover of
broadness.”
• Work Breakdown Structure creation breeds commitment
The process of developing and completing a WBS breed excitement and
commitment. Although the project manager will often develop the high-level
WBS, he will seek the participation of his core team to flesh out the extreme
detail of the WBS. This participation will spark involvement in the project.

Three Point Estimation:
Three point estimation is the estimation method is based on statistical data. It is
very much similar to WBS technique, task are broken down into subtasks &
three types of estimation are done on this sub pieces.
Optimistic Estimate (Best case scenario in which nothing goes wrong and all
conditions are optimal.) = A
Most Likely Estimate (most likely duration and there may be some problem but
most of the things will go right.) = M
Pessimistic Estimate (worst case scenario which everything goes wrong.) = B
Formula to find Value for Estimate (E) = A + (4*M) + B / 6
Standard Deviation (SD) = = (B – A)/6

Functional Point Method:
Functional Point is measured from a functional, or user, point of view.
It is independent of computer language, capability, technology or
development methodology of the team. It is based on available
documents like SRS, Design etc.
In this FP technique we have to give weightage to each functional point. Prior
to start actual estimating tasks functional points are divided into three
groups like Complex, Medium & Simple. Based on similar projects &
Organization standards we have to define estimate per function points.
Total Effort Estimate = Total Function Points * Estimate defined per
Functional Point
Advantages of the Functional Point Method:
• In pre-project stage the estimates can be prepared.
• Based on requirement specification documents the method’s reliability
is relatively high.

Thank You

Types of Testing

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Types of Testing

Similar to Types of Testing (20)

More from Murageppa-QA

More from Murageppa-QA (18)

Recently uploaded

Recently uploaded (20)

Types of Testing