1. TEST PLANNING & ESTIMATION,
TEST PLANNING & ACTIVITIES,
TEST ESTIMATION
BY KAYLA AND LESLIE

2. TEST PLANNING & ESTIMATION
• Test planning is the most important activity undertaken by a test leader in any test project.
• Ensures there is a list of tasks and milestones in a baseline plan to track progress .
• Defining the shape and size of the test effort.

3. WHEN IS TEST PLANNING USED?
• Used in development and implementation projects as well as maintenance (Change and fix) activities.

4. DOCUMENTS IN TEST PLANNING
• The main document produced in test planning is called a master test plan or project test plan.
• This document defines the high level of test activities being planned.
• Normally produced in early stages of project.
• Provides sufficient information to enable a test project to be established.
• The details of the test-level activities are documented within test-level plans.

9. WAIT… THERE IS AN ACRONYM??? SPACEDIRT
To help remember the 16 sections of IEEE 829 test plan

10. TEST PLANNING ACTIVITIES
The following are required activities for Test Planning, for both whole or part systems: Part 1
• Determine the scope and risks that need testing, involve the Project Manager and Subject
Manager.
• Identify and agree on the objectives of testing, with a focus on TIME, QUALITY and COST.
• Objectives assist Manager’s to know when the Test Project is finished.
• A Test Strategy (Overall Approach) ensures that test levels, entry criteria and exit criteria are
defined.
• Liaise with the Project Manager ensuring testing activities have been included within the
Software Life Cycle activities such as:
 Design – the development of Software Design
 Development – the building of the code
 Implementation – the activities surrounding implementation into a live environment

11. TEST PLANNING ACTIVITIES
The following are required activities for Test Planning, for both whole or part systems: Part 2
• Identifying what needs to be tested, who will be performing the testing and in which roles.
• How and when the test activities should take place .
• Deciding on test result evaluation and when to stop testing (Exit Criteria).
• Create a Plan to identify when and who will undertake the test analysis and design activities along
with the documentation of the schedule for test implementation, test execution and test evaluation.
• Sourcing and delegating resources for each defined activity.
• Decide on the format of test project documentation, and which plans and test cases will be
documented.
• Define Management information including the metrics required, establishing processes to monitor
and control test preparation and execution along with defect resolution and risk issues.
• Ensure that test documentation generates test assets i.e. test cases.

12. ENTRY CRITERIA
• Entry Criteria defines when a test activity can start.
• Can include the start of a level of testing, start of test design and/or start of test execution.
• The stages of Entry Criteria to Test Execution are as follows:
1. Test tools installed in the environment are ready for use.
2. Testable code is available.
3. All test data is available and correct.
4. All test design activity has completed.

13. EXIT CRITERIA
• Exit Criteria is used to decide when a test activity has been completed or needs to stop.
• Exit Criteria can be defined for all test activities such as planning, specification and execution or
for a specific test level for test specification and execution.
• Examples of Exit Criteria are as follows:
 All tests planned have been run.
 A certain level of requirements coverage has been achieved.
 All high risk areas have been fully tested, leaving only minor risk outstanding.
 Cost – when the budget has been spent.
 The schedule has been achieved i.e. Product has to go live due to reaching its release date.
• Exit Criteria should have been agreed as early as possible in the life cycle. However, often subject
to change as the project progresses.

14. TEST ESTIMATION
• There are two very different Test Estimation approaches. They are:
• The Metrics based approach – data based.
• The Expert based approach – subjective based.

15. TEST ESTIMATION
• The Metrics-based approach
• Relies upon data collected from previous or similar projects. Data collected might included the
following:
 Number of Test Conditions.
 Number of Test Cases written.
 Number of Test Cases executed.
 Time taken to develop Test Cases.
 Time taken to run Test Cases.
 Number of defects found.
 Number of environment outages and average length as to how long each one lasted.
• It is essential for this approach to be a success is that actual costs and time for testing is
accurately recorded.
• The record cards from one project can be used for the metrics for the next project.

16. TEST ESTIMATION
• The Expert-based approach Part 1
• Also known as the Wide Band Delphi approach. Relies on the experience of owners of relevant tasks
or from experts to derive an estimate.
• In this context experts might be as follows:
 Business Experts.
 Test Process Consultants.
 Developers.
 Technical Architects.
 Analysts and Designers.
 Others with knowledge of the applications to be tested or the tasks involved in the process.

17. TEST ESTIMATION
• The Expert-based approach Part 2
• Examples of how the Expert-based approach can be applied.
1. Distribute to task owners requirement specification, and ask them in private (or when alone) to
estimate their task. Then amalgamate all the individual estimates and arrive at an estimate with built in
any required contingency.
2. Distribute requirement specifications to experts to develop their individual view of the overall
estimate, and then meet collectively to decide upon an agreed estimate.
Expert estimating can be done individually or collectively using either or both the examples given above.

18. CONCLUSION
• Many things affect the level of effort required to fulfil the test requirements of a project.
These can be split into three main categories, as listed below.
1. Product characteristics
2. Development process characteristics
3. Expected outcome of testing

19. CONCLUSION
• Product characteristics:
 Size of the test basis
 Complexity of the final product
 The amount of non-functional requirements
 The security requirements (perhaps meeting BS 7799, the security standard)
 How much documentation is required (e.g. some legislation-driven changes demand a certain
level of documentation that may be more than an organisation would normally produce)
 The availability and quality of the test basis (e.g. requirements and specifications)

20. CONCLUSION
• Development process characteristics:
• Timescales.
• Amount of budget available.
• Skills of those involved in the testing and development activity (the lower the skill level in
development, the more defects could be introduced, and the lower the skill level in testing, the
more detailed the test documentation needs to be).
• Which tools are being used across the life cycle (i.e. the amount of automated testing will affect
the effort required).

21. CONCLUSION
• Expected outcome of testing:
 The amount of errors.
 Test cases to be written.
The Final Word!
• Taking all of this into account, once the estimate is developed and agreed the test leader can set about
identifying the required resources and building the detailed plan.