SE401 - Software Quality Assurance and Testing: Test Plan

SE401 - Software Quality Assurance
and Testing
Test Plan
Outlines
 Test Plan
 Importance of a Test Plan
 Test Case Documentation
 Elements of a Test Plan
College of Computer and Information Systems - Prince Sultan University These slides are prepared from: https://www.guru99.com/software-testing.html and Software Testing and Analysis: 2
Process, Principles and Techniques (2008)
Test Plan
▪ A test plan is a detailed document that outlines the test strategy,

testing objectives, resources (manpower, software, hardware)
required for testing, test schedule, test estimation and test
deliverables.
▪ The test plan serves as a blueprint to conduct software testing
activities as a defined process which is minutely monitored and
controlled by the test manager.
College of Computer and Information Systems - Prince Sultan University These slides are prepared from: https://www.guru99.com/software-testing.html and 4
Software Testing and Analysis: Process, Principles and Techniques (2008)
Objectives of a Test Plan
▪ To create a set of testing tasks
▪ Assign resources to each testing task
▪ Estimate completion time for each testing task
▪ Document testing standards
Importance of a Test Plan
▪ Test Plan helps us determine the effort needed to validate the
quality of the application under test (AUT).
▪ Help people outside the test team such as developers, business
managers, customers understand the details of testing.
▪ Test Plan guides our thinking. It is like a rule book, which needs to
be followed.
▪ Important aspects like test estimation, test scope, Test
Strategy are documented in Test Plan, so it can be reviewed by
Management Team and re-used for other projects.
Test Plans – Contents vs. Structure
▪ The most common question about testing is
“ How do I write a test plan? ”
▪ This question usually comes up when the focus is on the document,
not the contents
▪ It’s the contents that are important, not the structure
− Good testing is more important than proper documentation
− However – documentation of testing can be very helpful
▪ Most organizations have a list of topics, outlines, or templates

Good Test Plans
▪ Developed and Reviewed early
▪ Clear, Complete and Specific
▪ Specifies tangible deliverables that can be inspected
▪ Staff knows what to expect and when to expect it
▪ Realistic quality levels for goals
▪ Includes time for planning
▪ Can be monitored and updated
▪ Includes user responsibilities
▪ Based on past experience
▪ Recognizes learning curves
Standard Test Plan
▪ ANSI / IEEE Standard 829-1983 is ancient but still used:
Test Plan
▪ A document describing the scope, approach, resources, and schedule
of intended testing activities. It identifies test items, the features to be
tested, the testing tasks, who will do each task, and any risks requiring
contingency planning
▪ Many organizations are required to adhere to this standard
▪ Unfortunately, this standard emphasizes documentation, not actual
testing – often resulting in a well documented vacuum
Test Planning and Preparation
▪ Major testing activities:
− Test planning and preparation
− Execution (testing)
− Analysis and follow-up
▪ Test planning:
− Goal setting
− Overall strategy
▪ Test preparation:
− Preparing test cases & test suite(s)
o systematic
− Preparing test procedure
Test Planning: Goal setting and strategic planning
▪ Goal setting
− Quality perspectives of the customer
− Quality expectations of the customer
− Mapping to internal goals and concrete (quantified) measurement
− Example: customer's correctness concerns => specific reliability target
▪ Overall strategy, including:

− Specific objects to be tested
− Techniques to use
− Measurement data to be collected
− Analysis and follow-up activities
− Key: Plan the“whole thing"!
Types of Test Plans
▪ Mission plan – tells “why”

− Usually one mission plan per organization or group
− Least detailed type of test plan
▪ Strategic plan – tells “what” and “when”

− Usually one per organization, or perhaps for each type of project
− General requirements for coverage criteria to use
▪ Tactical plan – tells “how” and “who”

− One per product
− More detailed
− Living document, containing test requirements, tools, results and issues such as integration order
Test Case Documentation
▪ Required elements of a Test Case:
− ID – unique identifier of a test case
− Features to be tested
− Steps – what you need to do
− Input data
− Expected result – what you are supposed to get from application
− Actual result – what you really get from application
− Pass / Fail
▪ Optional elements of a Test Case:
− Title – verbal description indicative of test case objective
− Goal / objective – primary verification point of the test case
− Project / application ID / title – for TC classification / better tracking
− Functional area – for better TC tracking
− Bug numbers for Failed test cases – for better error / failure tracking (ISO 9000)
− Positive / Negative class – for test execution planning
− Manual / Automatable / Automated parameter etc. – for planning purposes
− Test Environment
▪ Inputs ▪ Outputs
− Through the UI − To UI
− From interfacing systems or − To interfacing systems or devices
devices
− Files
− Files
− Databases
− Databases
− State
− State
− Response time
− Environment
▪ Format – follow company standards; if no standards – choose the one that

works best for you
− MS Word document
− MS Excel document
− Memo-like paragraphs (MS Word, Notepad, Wordpad)
▪ Classes
− Positive and Negative
− Functional, Non-Functional and UI
− Implicit verifications and explicit verifications
− Systematic testing and ad-hoc
Elements of a Test Plan
Test Plan
Test plan outline how your application will be tested in detail
▪ What:
− a document describing the scope, approach, resources and schedule of
intended testing activities; identifies test items, the features to be tested, the
testing tasks, and any risks requiring contingency planning
▪ Who:
− who will do each task
− divide responsibilities between teams involved - if more than one Software
Testing team is involved (i.e., manual / automation, or English / Localization)
Test Plan
▪ When:
− planning/design/coding/testing stage(s)
▪ How:
− Plan for test resources / timelines
− Plan for test coverage
− Plan for OS / DB / software deployment and configuration models coverage
After Completion:
− Create and maintain the document
− Analyze for completeness
− Have it reviewed and signed by Project Team leads/managers
How to write a simple Test Plan?
▪ Eight steps to create a test

plan as per IEEE 829
1. Analyze the Project
▪ Can you test a 1. Review
product without any information 3. Interview
product and
client, designer
about it? and developer
project
documentation
▪ No… You must learn a
product thoroughly before
testing it.
▪ You can use the following
approach to analyze the 2. Perform
product
product: walkthrough
2. Develop Test Strategy
▪ Test Strategy is a critical step in making a Test Plan. This document
defines:
− The project’s testing objectives and the means to achieve them
− Determines testing effort and costs
▪ To develop Test Strategy for testing a product, you should follow steps
below:
Step 2.1) Define Scope of Testing
▪ Before the start of any test activity, scope of the testing should be
known.
− The components of the system to be tested (hardware, software, middleware,
etc.) are defined as "in scope"
− The components of the system that will not be tested also need to be clearly
defined as being "out of scope."
Step 2.1) Define Scope of Testing
▪ To determine scope, you must consider:
− Customer requirement
− Project Budget
− Product Specification
− Skills & talent of your test team
Step 2.2) Identify Testing Type
▪ A Testing Type is a standard test procedure that gives an expected
test outcome. (many are available..)
▪ The commonly used testing types are:
− Unit Test: test the smallest piece of verifiable software in the application.
− API Test: test the API’s created for the application
− Integration Test: individual software modules combined and tested as group
− System Test: conducted on a complete, integrated system to evaluate
system’s compliance with its specified requirements
− And more …
Step 2.3) Document Risk & Issues
▪ Risk is future’s uncertain event with a probability
of occurrence and a potential for loss. When the risk actually
happens, it becomes the ‘issue’.
▪ You should document those risks in the Test Plan.
Step 2.3) Document Risk & Issues (Example)
Risk Mitigation
Team member lack the required skills for Plan training course to skill up your members
website testing.
The project schedule is too tight; it's hard to Set Test Priority for each of the test activity
complete this project on time
Test Manager has poor management skill Plan leadership training for manager
A lack of cooperation negatively affects your Encourage each team member in his task, and inspire them to greater
employees' productivity efforts.
Wrong budget estimate and cost overruns Establish the scope before beginning work, pay a lot of attention to project
College of Computer and Information Systems
planning and constantly track and measure the progress
- Prince Sultan University These slides are prepared from: https://www.guru99.com/software-testing.html and 29
Step 2.4) Create Test Logistics
▪ In Test Logistics, the Test Manager should answer the following
questions:
− Who will test?
− When will the test occur?
3. Define Test Objective
▪ Test Objective is the overall goal and achievement of the test
execution
▪ A sample of the Objectives for an online bank website:
“The test objectives are to verify the functionality of the website of the bank, the
project should focus on testing the banking operation such as Account
Management, Withdrawal, and Balance…etc. to guarantee all these operations
can work normally in real business environment.”
4. Define Test Criteria
▪ Test Criteria is a standard or rule on which a test procedure or test
judgment can be based. There’re 2 types of test criteria as
following:
− Suspension Criteria: Specify the critical suspension criteria for a test. If the
suspension criteria are met during testing, the active test cycle will
be suspended until the criteria are resolved.
Example:
“If testing team report that there are 40% of test cases failed, you
should suspend testing until the development team fixes all the failed cases.”
4. Define Test Criteria
▪ Test Criteria is a standard or rule on which a test procedure or test
judgment can be based. There’re 2 types of test criteria as
following:
− Exit Criteria: It specifies the criteria that denote a successful completion of a
test phase. The exit criteria are the targeted results of the test and are
necessary before proceeding to the next phase of development.
Example:
“95% of all critical test cases must pass.”
5. Resource Planning
▪ Resource plan is a detailed summary of all types of resources
required to complete project task.
▪ Resource could be human, equipment and materials needed to
complete a project
▪ The resource planning is important factor of the test planning
because it helps in determining the number of resources
(employee, equipment…) to be used for the project. Therefore, the
Test Manager can make the correct schedule & estimation for the
project. (check the Sample Test Plan on Moodle for an example)
6. Plan Test Environment
▪ How do you plan for setting up a test environment for a product?
▪ To finish this task, you need a strong cooperation between Test Team and
Development Team
▪ Test team should ask the development team all required details about the
product to run to be able to clearly understand the product under test.
▪ Sample of questions:
− What is the maximum user connections which this product can handle at the same time?
− What are hardware/software requirements to install this product?
− Does the user's computer need any particular setting to browse the website?
− Other questions …
7. Schedule & Estimation
▪ To do the Schedule and time estimation it is better to break down
the whole project into small tasks and add the estimation for How can we
estimate
each task separately. An example is provided below: required effort?
Task Members Estimate effort
Create the test specification Test Designer 170 man-hour
Perform Test Execution Tester, Test Administrator 80 man-hour
Test Report Tester 10 man-hour

Test Delivery 20 man-hour

Total 280 man-hour
▪ Then you create the schedule to complete these tasks.
▪ To create the project schedule, the Test Manager needs several
types of input as below:
− Employee and project deadline: The working days, the project deadline,
resource availability are the factors which affected to the schedule
− Project estimation: Base on the estimation, the Test Manager knows how
long it takes to complete the project. So he/she can make the appropriate
project schedule
− Project Risk : Understanding the risk helps Test Manager add enough extra
time to the project schedule to deal with the risks
▪ Example:
− Suppose that you need to complete testing of your project in one month, you
already estimated the effort for each tasks in Test Estimation (in slide 57). You
can create a schedule similar to the one below:
8. Test Deliverables
▪ Test Deliverables is a list of all the documents, tools and other

components that has to be developed and maintained in support of
the testing effort.
▪ There are different test deliverables at every phase of the software
development lifecycle:
− Before Testing (e.g. test plans, test cases, test design specifications)
− During Testing (e.g. test scripts, test data, test traceability matrix, error logs)
− After Testing (e.g. test results and reports, defect report, installation
guidelines, release notes)
Elements of a test plan
1. Title
2. Identification of software (incl. version/release #s)
3. Revision history of document (incl. authors, dates)
4. Table of Contents
5. Purpose of document, intended audience
6. Objective of testing effort
7. Software product overview
8. Relevant related document list, such as requirements, design documents, other
test plans, etc.
9. Relevant standards or legal requirements
10. Traceability requirements
11.Relevant naming conventions and identifier conventions
12.Overall software project organization and personnel/contact-info/responsibilities
13.Test organization and personnel/contact-info/responsibilities
14.Assumptions and dependencies
15.Project risk analysis
16.Testing priorities and focus
17.Scope and limitations of testing
18.Test outline - a decomposition of the test approach by test type, feature, functionality,
process, system, module, etc. as applicable
19.Outline of data input equivalence classes, boundary value analysis, error classes
20. Test environment - hardware, operating systems, other required software, data
configurations, interfaces to other systems
21. Test environment validity analysis - differences between the test and production
systems and their impact on test validity
22. Test environment setup and configuration issues
23. Software migration processes
24. Software CM processes
25. Test data setup requirements
26. Database setup requirements
27. Outline of system-logging/error-logging/other capabilities, and tools such as
screen capture software, that will be used to help describe and report bugs
28.Discussion of any specialized software or hardware tools that will be used by testers to
help track the cause or source of bugs
29.Test automation - justification and overview
30.Test tools to be used, including versions, patches, etc.
31.Test script/test code maintenance processes and version control
32.Problem tracking and resolution - tools and processes
33.Project test metrics to be used
34.Reporting requirements and testing deliverables
35.Software entrance and exit criteria
36.Initial sanity testing period and criteria
37. Test suspension and restart criteria

38. Personnel allocation
39. Personnel pre-training needs
40. Test site/location
41. Outside test organizations to be utilized and their purpose, responsibilities,
deliverables, contact persons, and coordination issues
42. Relevant proprietary, classified, security, and licensing issues
43. Open issues
44. Appendix - glossary, acronyms, etc.
▪ Please check the Test Plan Sample in Moodle
▪ Visit: https://
www.guru99.com/how-precaution-becomes-cure-risk-analysis-and-s
olutions-in-test-management.html
for more information about how to perform risk analysis
▪ Visit: https://
www.guru99.com/an-expert-view-on-test-estimation.html for more
information about effort estimation
Summary
 Test Plan
 Importance of a Test Plan
 Test Case Documentation
 Elements of a Test Plan

SE401 - Software Quality Assurance and Testing: Test Plan

Uploaded by

Copyright:

Available Formats

SE401 - Software Quality Assurance and Testing: Test Plan

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SE401 - Software Quality Assurance and Testing: Test Plan

Uploaded by

Copyright:

Available Formats

SE401 - Software Quality Assurance

▪ A test plan is a detailed document that outlines the test strategy,

▪ Most organizations have a list of topics, outlines, or templates

▪ Overall strategy, including:

▪ Mission plan – tells “why”

▪ Strategic plan – tells “what” and “when”

▪ Tactical plan – tells “how” and “who”

▪ Format – follow company standards; if no standards – choose the one that

▪ Eight steps to create a test

Test Manager has poor management skill Plan leadership training for manager

Task Members Estimate effort

Create the test specification Test Designer 170 man-hour

Perform Test Execution Tester, Test Administrator 80 man-hour

Test Report Tester 10 man-hour

▪ Test Deliverables is a list of all the documents, tools and other

37. Test suspension and restart criteria

You might also like