In this Quality Assurance Training session, you will learn about Types of Testing , Test Strategy and Planning, and Test Estimation Techniques. Topic covered in this session are: • Test Planning, • Test Estimation Techniques For more information, about this quality assurance training, visit this link: https://www.mindsmapped.com/courses/quality-assurance/software-testing-training-with-hands-on-project-on-e-commerce-application/

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

2. Page 2Classification: Restricted
Agenda
• Test Planning,
• Test Estimation Techniques

3. Page 3Classification: Restricted
STLC (Software Testing Life Cycle)

4. Page 4Classification: Restricted
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.

5. Page 5Classification: Restricted
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.

6. Page 6Classification: Restricted
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

7. Page 7Classification: Restricted
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.

8. Page 8Classification: Restricted
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.

9. Page 9Classification: Restricted
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

10. Page 10Classification: Restricted
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.

11. Page 11Classification: Restricted
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.

12. Page 12Classification: Restricted
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.

13. Page 13Classification: Restricted
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.

14. Page 14Classification: Restricted
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

15. Page 15Classification: Restricted
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.
www.mindsmapped.com

16. Page 16Classification: Restricted
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.
www.mindsmapped.com

17. Page 17Classification: Restricted
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.
www.mindsmapped.com

18. Page 18Classification: Restricted
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.

19. Page 19Classification: Restricted
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
www.mindsmapped.com

20. Page 20Classification: Restricted
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.

21. Page 21Classification: Restricted
Thank You