CO3: Prepare Test Plan For An Application
CO3: Prepare Test Plan For An Application
CO3: Prepare Test Plan For An Application
Test Plan
• A document describing the scope, approach, resources and schedule of intended test
activities. It identifies amongst others test items, the features to be tested, the testing
tasks, who will do each task, degree of tester independence, the test environment, the test
design techniques and entry and exit criteria to be used, and the rationale for their choice,
and any risks requiring contingency planning. It is a record of the test planning process.
• Test deliverables
Scope
Methodology
Requirements
Schedule
• Master Test Plan: A single high-level test plan for a project/product that unifies all other
test plans.
• Testing Level Specific Test Plans :Plans for each level of testing.
• Testing Type Specific Test Plans: Plans for major types of testing like Performance
Test Plan and Security Test Plan.
• Make the plan concise. Avoid redundancy and superfluousness. If you think you do not
need a section that has been mentioned in the template above, go ahead and delete that
section in your test plan.
• Be specific. For example, when you specify an operating system as a property of a test
environment, mention the OS Edition/Version as well, not just the OS Name.
• Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
• Have the test plan reviewed a number of times prior to base lining it or sending it
for approval. The quality of your test plan speaks volumes about the quality of the
testing you or your team is going to perform.
• Update the plan as and when necessary. An outdated and unused document stinks and
is worse than not having the document in the first place.
Pass or fail: - Specify the criteria that will be used to determine whether each test item
has passed or failed testing.
Resume Criteria: - Specify the criteria which must be redone when testing is resumed.
Identifying Responsibilities
• A testing project requires different people to play different roles. There are roles of test
engineers, test leads and test managers. There is also role definition on the dimensions of
the modules being tested or the type of testing. These different roles should complement
each other.
Ensure there is clear accountability for a given task, so that each person knows what he or
she has to do,
Clearly list the responsibilities for various functions to various people, so that everyone
knows how his or her work fits into the entire project.
Supplement each other, so that no task is left unassigned. Role definition should not only
address technical roles, but also list the management and reporting responsibilities. This
includes frequency, format and recipients of status reports and other project-tracking
mechanism.
Staff training
This activity of test planning will give the idea about the following points:
1. How many staff needs training?
2. Who are the attendees?
3. What training needs to be given?
4. What are the pre requisites of the training?
Course Coordinator : Mrs. Kshirsagar S.R. M.M.Polytechnic , Thergaon Page 3
Unit 3: Test Management
Resource requirements
Factors to be considered while selecting the resource requirements are:
People: How many people are required? How much experience they should possess? What kind
of experience is needed? What should they be expertise in? Should they be full-time, part-time,
contract, students?
Equipment: How many Computers are required? What configuration computers will be
required? What kind of test hardware is needed? Any other devices like printers, tools etc.
Office and lab space: Where will they be located? How big will they be? How will they be
arranged?
Software: Word processors, databases, custom tools. What will be purchased, what needs to be
written?
Outsource companies: Will they be used? What criteria will be used for choosing them?
How much will they cost?
Miscellaneous supplies: Disks, phones, reference books, training material. What else might be
necessary over the course of the project? The specific resource requirements are very project-,
team-, and company-dependent, so the test plan effort will need to carefully evaluate what will
be needed to test the software.
Test Plan
Testing Strategy
Test Scripts
Test Data
Test Results/reports
Install/config guides
Defect Reports
Release notes
• The test plan describes the overall method to be used to verify that the software meets the
product specification and the customer's needs. It includes the quality objectives, resource
needs, schedules, assignments, methods, and so forth.
• Test cases list the specific items that will be tested and describe the detailed steps that
will be followed to verify the software.
• Bug reports describe the problems found as the test cases are followed. These could be
done on paper but are often tracked in a database.
• Test tools and automation are listed and described which are used to test the software. If
the team is using automated methods to test software, the tools used, either purchased or
written in-house, must be documented.
• Metrics, statistics, and summaries convey the progress being made as the test work
progresses. They take the form of graphs, charts, and written reports.
• Milestones: milestones are the dates of completion given for various tasks to be
performed in testing. These are thoroughly tracked by the test manager and are kept in the
documents such as Gantt charts, etc.
Test Management
• It concerned with both test resource and test environment management. It is the
role of test management to ensure that new or modified service products meet
business requirements for which they have been developed or enhanced.
A test case database (TCDB) (additional): A test case database captures all
the relevant information about the test cases in an organization. Some of the
entities and the attributes are given in following table
Defect Repository
occurrence
Test case- product cross Provides a mapping between Test case ID
reference the tests and the Modulate ID
corresponding product
features ; enables
identification of tests for a
given feature
Test case run history Gives the history of when a Test case ID
test was run and what was Run date
the result; provides inputs on Time taken
selection of tests for Run status
regression runs (see chapter (success/failure)
8)
Test case – Defect cross Gives details of test cases Test case ID
reference introduced to test certain Defect reference#
specific defects detected in (points to a record in
the product ;provides inputs the defect repository)
on the selection of tests for
regression runs
• People management is an integral part of any project management and test planning.
• People management also requires the ability to hire, motivate, and retain the right people.
• These skills are seldom formally taught.
• Testing projects present several additional challenges.
• We believe that the success of a testing organization depends vitally on judicious people
management skills
• Test Plan Identifier: Provide a unique identifier for the document. (Adhere to the
Configuration Management System if you have one.)
• Introduction:
1. Project Plan
2. Configuration Management Plan
• Test Items: List the test items (software/products) and their versions.
• Features to be Tested:
1. List the features of the software/product to be tested.
2. Provide references to the Requirements and/or Design specifications of the
features to be tested
• Features Not to Be Tested:
1. List the features of the software/product which will not be tested.
2. Specify the reasons these features won’t be tested.
• Approach:
1. Mention the overall approach to testing.
2. Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing
methods [Manual/Automated; White Box/Black Box/Gray Box]
• Item Pass/Fail Criteria:
1. Specify the criteria that will be used to determine whether each test item
(software/product) has passed or failed testing.
• Suspension Criteria and Resumption Requirements:
1. Specify criteria to be used to suspend the testing activity.
2. Specify testing activities which must be redone when testing is resumed.
• Test Deliverables: List test deliverables, and links to them if available, including the
following:
– Test Plan (this document itself)
– Test Cases
– Test Scripts
– Defect/Enhancement Logs
– Test Reports
• Test Environment:
1. Specify the properties of test environment: hardware, software, network etc.
2. List any testing or related tools.
• Estimate: Provide a summary of test estimates (cost or effort) and/or provide a link to
the detailed estimation.
• Schedule: Provide a summary of the schedule, specifying key test milestones, and/or
provide a link to the detailed schedule.
• Staffing and Training Needs:
1. Specify staffing needs by role and required skills.
2. Identify training that is necessary to provide those skills, if not already acquired.
• Responsibilities: List the responsibilities of each team/role/individual.
• Risks:
1. List the risks that have been identified.
2. Specify the mitigation plan and the contingency plan for each risk.
• Assumptions and Dependencies:
1. List the assumptions that have been made during the preparation of this plan.
Test Specification Items are must for each test specification should contain the following
items:
1. Case No.: The test case number should be a three digit identifier of the following
form:c.s.t, where: c- is the chapter number, s- is the section number, and t- is the test case
number.
9. Data: (Tx Data, Predicted Rx Data): Describes the data flows between the Implementation
under Test (IUT) and the test engine.
10. Script: (Pseudo Code for Coding Tests): Pseudo code (or real code) used to conduct the
test.
Test Reporting
1) Executing Test Cases
Test execution is the process of executing the code and comparing the expected and actual results.
Following factors are to be considered for a test execution process:
Based on a risk, select a subset of test suite to be executed for this cycle.
Assign the test cases in each test suite to testers for execution.
Report status, adjust assignments, and reconsider plans and priorities daily.
2) Test Reporting
Test reporting is a means of achieving communication through the testing cycle. There
are 3 types of test reporting.
1. Test incident report:
A test incident report is communication that happens through the testing cycle as and
when defects are encountered .A test incident report is an entry made in the defect
repository each defect has a unique id to identify incident .The high impact test incident
are highlighted in the test summary report.
2. Test cycle report:
A test cycle entails planning and running certain test in cycle , each cycle using a
different build of the product .As the product progresses through the various cycles it is
expected to stabilize.
Test cycle report gives
1. A summary of the activities carried out during that cycle.
2. Defects that are uncovered during that cycle based on severity and impact
3. Progress from the previous cycle to the current cycle in terms of defect fixed
4. Outstanding defects that not yet to be fixed in cycle
5. Any variation observed in effort or schedule
3 Test summary report:
The final step in a test cycle is to recommend the suitability of a product for release. A
report that summarizes the result of a test cycle is the test summary report.
There are two types of test summary report:
1. Phase wise test summary, which is produced at the end of every phase
2. Final test summary report.
A Summary report should present
1. Test Summary report Identifier
2 Description: - Identify the test items being reported in this report with test id
3 Variances: - Mention any deviation from test plans, test procedures, if any.
Course Coordinator : Mrs. Kshirsagar S.R. M.M.Polytechnic , Thergaon Page 11
Unit 3: Test Management
4 Summary of results: - All the results are mentioned here with the resolved incidents and
their solutions.
5 Comprehensive assessment and recommendation for release should include Fit for
release assessment and recommendation of release