Template - Test Plan

FPT SOFTWARE
<Name of the project>

Test Plan
Project Code: <Code of the project>
Document Code: <Code of the document >– v<x.x>
<Location, issued date of the Document>

<Project code>-Test plan v<xxx>
RECORD OF CHANGE
*A - Added M - Modified D - Deleted
Effective Changed Items A* Change Description New Version

Date M, D
02-BM/PM/HDCV/FSOFT v1.2 2/19

SIGNATURE PAGE
Effort: Sự cố gắng. (Từ điển) Trong dự án phần mềm Effort tức là thời gian dùng để hoàn
thành công việc.
Effort ước lượng ( nằm ở trong kế hoặch)
Effort thực sự đã xảy ra ( ghi lại sự kiện xảy ra trong thực tế)
Ví dụ quen thuộc về test plan
Data đầu vào:

1. Số lượng sv đi thi
2. Số ngày thi trong đợt thi
3. Số ca thi
Dựa trên data đầu vào ở trên người ta ước lượng số người đi coi thi.
Áp dụng sang làm phần mềm.

Data đầu vào
1. Tổng h cần phải có để làm hoàn thành dự án. Tổng số h này lấy từ kế hoạch dự án.
2. Số % h trong tổng số h để làm dự án cần dùng để test sản phẩm phần mềm. (Ví dụ:
Quản lý dự án là 10%, Coding 35%, Testing 30%).
3. Số ngày cho phép test sản phẩm phần mềm.
Ví dụ nhỏ hơn: Cần 100h để test sản phẩm phần mềm. Cho phép test trong 10 ngày
Tính được chỉ cần 1 tester.
Cần 100h để test sản phầm phần mềm. Cho phép test chỉ trong 2 ngày cần 5 tester.
Test plan phải chỉ ra số người cần làm tester, test từ ngày nào đến ngày nào kế hoạch
tuyển dụng hoặc sếp điều chuyển người từ dự án khác sang.
Đối với tester mới phải có kế hoạch đào tạo chuyên môn như qui trìnhm sử dụng tools
để làm được trong dự án. Ai đứng ra đào tạo, cần bao nhiêu thời gian để đào tạo, cụ thể
những ngày nào. Ở đâu? Online hay offline?....
Các kế hoạch cần được viết ra để sếp có thể phối hợp với dự án khác, hoặc tuyển dụng
Có 2 loại plan.
1. Master plan ( Kế hoạch dự án, do Project Manager làm, trong đó có kế hoạch
khoảng thời gian thực hiện test phần mềm) Hiểu na ná như kế hoạch của cả học kỳ
từ ngày nào đến ngày nào do trường làm.
2. Detail Plan do tester làm, cụ thể cho từng ngày. Hiểu na ná như khảo thí làm cụ thể
cho từng ngày. Thi môn gì, slot mấy, ở đâu cần bao nhiêu người coi thi
Chú ý
Các plan xoay quanh liên quan đến con người thực hiện công việc, sử dụng tool
dùng chung (na ná phòng dùng để thi). Sử dụng lại được nhiều người cho nhiều dự
án thì càng tốt. Sử dụng tools (Phần mềm dùng chung, server dùng chung…) cho
nhiều dự án càng tốt do sẽ giảm chi phí của doanh nghiệp.

ORIGINATOR: <Name> <Date>
<Position>
REVIEWERS: <Name> <Date>
<Position>
<Name, if it’s needed> <Date>
<Position>
APPROVAL: <Name> <Date>
<Position>

TABLE OF CONTENTS
1 INTRODUCTION............................................................................................................5
1.1 Purpose.............................................................................................................................5
1.2 Background information......................................................................................................5
1.3 Scope of testing.................................................................................................................5
1.4 Constraints........................................................................................................................5
1.5 Risk list.............................................................................................................................6
2 REQUIREMENTS FOR TEST...........................................................................................6
3 TEST STRATEGY............................................................................................................6
3.1 Test types.........................................................................................................................9

3.1.1 Functional Testing...................................................................................................9
3.1.2 Performance testing...............................................................................................12
3.1.3 Security and Access Control Testing........................................................................15
3.1.4 Regression Testing................................................................................................16
3.2 Test stage.......................................................................................................................16
3.3 Tools...............................................................................................................................17
4 RESOURCE..................................................................................................................17
4.1 Human Resource..............................................................................................................17

4.2 System............................................................................................................................17
5 TEST MILESTONES......................................................................................................17
6 DELIVERABLES...................................................................................................................18

1 INTRODUCTION
1.1 Purpose
<Describe briefly about the purpose and organization of the documents. How many sections?
What each section describes about? >
1.2 Background information
<Enter a brief description of the target-of-test (components, application, system, etc.) and its
goals. Include the information such as major functions and features, its architecture, and a brief
history of the project. >
1.3 Scope of testing
<Describe the stages of testingfor example, Unit, Integration, or Systemand the types of
testing that will be addressed by this plan, such as Function or Performance.
Provide a brief list of the target-of-test’s features and functions that will or will not be tested.
List any assumptions made during the development of this document that may impact the
design, development or implementation of testing.
Define trigger for regression test (applied for maintenance projects), period and scope of
regression test.
The defects found are in range of defect expectation (refer to Planned defect in Fsoft Insight)>
1.4 Constraints
<Address any constraints on testing. They may be:
- Test environment difference or lack of some external systems that interface to the system-
under-test (Reference to SRS document may be included here if the constraints have been
stated in SRS)
- Constraints on resource, schedules, lack of tools, etc.>

1.5 Risk list
<List any risks and corresponding mitigation and contingencies that may affect the design,
development or implementation of testing. >
2 REQUIREMENTS FOR TEST
The listing below identifies those items (use cases, functional requirements, non-functional
requirements) that have been identified as targets for testing. This list represents what will be
tested.
<Enter a high level list of major test requirements>
3 TEST STRATEGY
<The Test Strategy presents the recommended approach to the testing of the target-of-test.
State clearly the type of test being implemented, the test objectives and how you will conduct
the test.
If a type of test will not be implemented and executed, state this explicitly, such as “This test
will not be implemented or executed. This test is not appropriate.”
The main considerations for the test strategy are the techniques to be used and the criterion
for knowing when the testing is completed.
For each type of test, it should explain technique, completion criteria, and special
considerations
Technique: The technique should describe how testing will be implemented and executed.
Include what will be tested, the major actions to be taken during test execution, and the
method(s) used to evaluate the results
Completion criteria: Completion criteria are stated to for two purposes:
 Identify acceptable product quality
 Identify when the test effort has been successfully implemented
A clear statement of completion criteria should include the following items:
 Function, behavior, or condition being measured
 Method of measurement

Criteria or degree of conformance to measurement
Special considerations:
This section should identify any influences or dependencies, which may impact or influence the
test effort describe in the test strategy. Influences might include:
Human resources (such as availability or need for non-test resources to support / participate in
test)
Constraints, (such as equipment limitations or availability, or the need / lack of special

equipment)
Special requirements, such as test scheduling or access to systems
Testing may be stopped when
 It becomes unproductive
 It requires a certain coverage
 It requires a certain number of errors to be found
 Schedule time runs out
A sample of Test type description:
Technique:
- Functional Test:
For each use case flow of events, a representative set of transactions will identified, each
representing the actions taken by the actor when the use case is executed.
A minimum of two test cases will be developed for each transaction; one test case to reflect the
positive condition and one to reflect the negative (unacceptable) condition.
In the first iteration, use cases 1 - 4, and 12 will be tested, in the following manner:
Use Case 1 begins with the actor already logged into the application and at the main window,
and terminates when the user has specified SAVE.
Each test case will be implemented and executed using Rational Robot.
Verification and assessment of execution for each test case will be done using the following
methods:
Test script execution (did each test script execute successfully and as desired?)

Window Existence, or Object Data verification methods (implemented in the test scripts) will be
used to verify that key windows display and specified data is captured / displayed by the target-
of-test during test execution.
The target-of-test's database (using Microsoft Access) will be examined before the test and
again after the test to verify that the changes executed during the test are accurately reflected
in the data.
- Performance Test:
For each use case, a representative set of transactions, as identified in the workload analysis
document will be implemented and executed using Rational Suite PerformanceStudio and
Rational Robot (GUI scripts).
At least three workloads will be reflected in the test scripts and test execution schedules
including the following:
Stressed workload: 750 users (15 % managers, 50 % sales, 35 % marketing)
Peak workload: 350 users (10 % managers, 60 % sales, 30 % marketing)
Nominal workload: 150 users (2 % managers, 75% sales, 23 % marketing)
Test scripts used to execute each transaction will include the appropriate timers to capture
response times, such as total transaction time (as defined in the workload analysis document),
and key transaction activity or process times.
The test scripts will execute the workloads for one hour (unless noted differently by the
workload analysis document).
Verification and assessment of execution for each test execution (of a workload) will include:
Test execution will be monitored using state histograms (to verify that the test and workloads
are executing as expected and desired)
Test script execution (did each test script execute successfully and as desired?)
Capture and evaluation of the identified response times using the following reports:
 Performance Percentile
 Response Time
Completion criteria:
 All planned test cases have been executed
 All identified defects have been addressed to an agreed upon resolution

 All planned test cases have been re-executed and all known defects have been addressed
as agreed upon, and no new defects have been discovered
Or
 All high priority test cases have been executed.
 All identified defects have been addressed to an agreed upon resolution.
 All Severity 1 or 2 defects have been resolved (status = fixed or postponed).
 All high priority test cases have been re-executed and all known defects have addressed as
agreed upon, and no new defects have been discovered.
Special considerations
 Test databases will require the support of a database designer / administrator to create,
update, and refresh test data.
 System performance testing will use the servers on the existing network (which supports
non-test traffic). Testing will need to be scheduled after hours to ensure no non-test traffic
on the network.
 The target-of-test must synchronize the legacy system (or synchronization simulated) for
full functional testing to be implemented and executed
 Testing may be stopped when <defect number is over the norm...>
 Tester can stop the test when developers do not perform unit test....
3.1 Test types
3.1.1 Functional Testing
3.1.1.1 Function Testing
< Function testing of the target-of-test should focus on any requirements for test that can be
traced directly to use cases or business functions and business rules. The goals of these tests
are to verify proper data acceptance, processing, and retrieval, and the appropriate
implementation of the business rules. This type of testing is based upon black box techniques;
that is verifying the application and its internal processes by interacting with the application via
the Graphical User Interface (GUI) and analyzing the output or results. Identified below is an
outline of the testing recommended for each application:>

Test Objective: <Ensure proper target-of-test functionality, including navigation, data entry,
processing, and retrieval. >
Technique: <Execute each use case, use-case flow, or function, using valid and invalid
data, to verify the following:
- The expected results occur when valid data is used.
- The appropriate error or warning messages are displayed when invalid

data is used.
- Each business rule is properly applied. >
Completion Criteria: - <All planned tests have been executed.

- All identified defects have been addressed. >
Special <Identify or describe those items or issues (internal or external) that impact
Considerations: the implementation and execution of function test>
3.1.1.2 User Interface Testing
<User Interface (UI) testing verifies a user’s interaction with the software. The goal
of UI testing is to ensure that the User Interface provides the user with the
appropriate access and navigation through the functions of the target-of-test. In
addition, UI testing ensures that the objects within the UI function as expected and
conform to corporate or industry standards. >
<Verify the following:
 Navigation through the target-of-test properly reflects business

functions and requirements, including window-to-window, field-to-field, and
Test Objective:
use of access methods (tab keys, mouse movements, accelerator keys)
 Window objects and characteristics, such as menus, size, position, state,

and focus conform to standards. >
<Create or modify tests for each window to verify proper navigation and
Technique:
object states for each application window and objects. >
<Each window successfully verified to remain consistent with benchmark

Completion Criteria:
version or within acceptable standard>
Special
<Not all properties for custom and third party objects can be accessed. >
Considerations:
3.1.1.3 Data and Database Integrity Testing
<The databases and the database processes should be tested as a subsystem within the
Project. These subsystems should be tested without the target-of-test’s User Interface as the
interface to the data. Additional research into the DataBase Management System (DBMS) needs
to be performed to identify the tools and techniques that may exist to support the testing
identified below. >

<Ensure database access methods and processes function properly and

Test Objective:
without data corruption. >
 <Invoke each database access method and process, seeding each with
valid and invalid data or requests for data.
Technique:  Inspect the database to ensure the data has been populated as
intended, all database events occurred properly, or review the returned data
to ensure that the correct data was retrieved for the correct reasons>
<All database access methods and processes function as designed and

without any data corruption. >
 <Testing may require a DBMS development environment or drivers to

enter or modify data directly in the databases.
Special
 Processes should be invoked manually.
Considerations:
 Small or minimally sized databases (limited number of records) should be
used to increase the visibility of any non-acceptable events. >
3.1.1.4 Business Cycle Testing
<Business Cycle Testing should emulate the activities performed on the <Project Name> over
time. A period should be identified, such as one year, and transactions and activities that would
occur during a year’s period should be executed. This includes all daily, weekly, and monthly
cycles and, events that are date-sensitive, such as banking application. >
<Ensure proper target-of-test and background processes function according

Test Objective
to required business models and schedules. >
<Testing will simulate several business cycles by performing the following:
 The tests used for target-of-test’s function testing will be modified or

enhanced to increase the number of times each function is executed to
simulate several different users over a specified period.
 All time or date-sensitive functions will be executed using valid and

invalid dates or time periods.
 All functions that occur on a periodic schedule will be executed or

Technique: launched at the appropriate time.
 Testing will include using valid and invalid data to verify the
following:
 The expected results occur when valid data is used.
 The appropriate error or warning messages are displayed when

invalid data is used.
 Each business rule is properly applied.
 <All planned tests have been executed.

 All identified defects have been addressed.}
Special  <System dates and events may require special support activities
Considerations:

 Business model is required to identify appropriate test requirements

and procedures. >
3.1.2 Performance testing
3.1.1.5 Performance Profiling
<Performance profiling is a performance test in which response times, transaction rates, and
other time-sensitive requirements are measured and evaluated. The goal of Performance
Profiling is to verify performance requirements have been achieved. Performance profiling is
implemented and executed to profile and tune a target-of-test's performance behaviors as a
function of conditions such as workload or hardware configurations.
Note: Transactions below refer to “logical business transactions”. These transactions are
defined as specific use cases that an actor of the system is expected to perform using the
target-of-test, such as add or modify a given contract. >
<Verify performance behaviors for designated transactions or business

functions under the following conditions:
Test Objective:
 normal anticipated workload
 anticipated worst case workload>
 <Use Test Procedures developed for Function or Business Cycle Testing.
 Modify data files to increase the number of transactions or the scripts to

increase the number of iterations each transaction occurs.
Technique:
 Scripts should be run on one machine (best case to benchmark single
user, single transaction) and be repeated with multiple clients (virtual or
actual, see Special Considerations below). >
 <Single Transaction or single user: Successful completion of the test

scripts without any failures and within the expected or required time allocation
Completion Criteria: per transaction. >
 <Multiple transactions or multiple users: Successful completion of the
test scripts without any failures and within acceptable time allocation. >
Special <Comprehensive performance testing includes having a background workload

Considerations: on the server.
There are several methods that can be used to perform this, including:
 “Drive transactions” directly to the server, usually in the form of

Structured Query Language (SQL) calls.
 Create “virtual” user load to simulate many clients, usually several

hundred. Remote Terminal Emulation tools are used to accomplish this
load. This technique can also be used to load the network with “traffic”.
 Use multiple physical clients, each running test scripts to place a load on
the system.

Performance testing should be performed on a dedicated machine or at a

dedicated time. This permits full control and accurate measurement.
The databases used for Performance Testing should be either actual size or
scaled equally. >
3.1.1.6 Load Testing
<Load testing is a performance test which subjects the target-of-test to varying workloads to
measure and evaluate the performance behaviors and ability of the target-of-test to continue to
function properly under these different workloads. The goal of load testing is to determine and
ensure that the system functions properly beyond the expected maximum workload.
Additionally, load testing evaluates the performance characteristics, such as response times,
transaction rates, and other time sensitive issues). >
<Note: Transactions below refer to “logical business transactions”. These transactions are
defined as specific functions that an end user of the system is expected to perform using the
application, such as add or modify a given contract. >
<Verify performance behavior time for designated transactions or business

Test Objective:
cases under varying workload conditions. >
 <Use tests developed for Function or Business Cycle Testing.

Technique:  Modify data files to increase the number of transactions or the tests to
increase the number of times each transaction occurs. >
<Multiple transactions or multiple users: Successful completion of the tests

without any failures and within acceptable time allocation. >
 <Load testing should be performed on a dedicated machine or at a

Special dedicated time. This permits full control and accurate measurement.
Considerations:  The databases used for load testing should be either actual size or scaled
equally. >
3.1.1.7 Stress Testing
<Stress testing is a type of performance test implemented and executed to find errors due to
low resources or competition for resources. Low memory or disk space may reveal defects in the
target-of-test that aren't apparent under normal conditions. Other defects might result from
competition for shared resources like database locks or network bandwidth. Stress testing can
also be used to identify the peak workload the target-of-test can handle. >
<Note: References to transactions below refer to logical business transactions. >

<Verify that the target-of-test functions properly and without error under the
following stress conditions:
 little or no memory available on the server (RAM and DASD)
 maximum actual or physically capable number of clients connected or

simulated
Test Objective:  multiple users performing the same transactions against the same data
or accounts
 worst-case transaction volume or mix (see Performance Testing above).
Notes: The goal of Stress Testing might also be stated as identify and
document the conditions under which the system FAILS to
continue functioning properly. >
 <Use tests developed for Performance Profiling or Load Testing.
 To test limited resources, tests should be run on a single machine, and

RAM and DASD on server should be reduced or limited.
Technique:
 For remaining stress tests, multiple clients should be used, either running
the same tests or complementary tests to produce the worst-case transaction
volume or mix.
<All planned tests are executed and specified system limits are reached or
Completion Criteria: exceeded without the software failing or conditions under which system failure
occurs is outside of the specified conditions. >
 <Stressing the network may require network tools to load the network
with messages or packets.
Special  The DASD used for the system should temporarily be reduced to restrict
Considerations: the available space for the database to grow.
 Synchronization of the simultaneous clients accessing of the same

records or data accounts. >
3.1.1.8 Volume Testing
<Volume Testing subjects the target-of-test to large amounts of data to determine if limits are
reached that cause the software to fail. Volume Testing also identifies the continuous maximum
load or volume the target-of-test can handle for a given period. For example, if the target-of-
test is processing a set of database records to generate a report, a Volume Test would use a
large test database and check that the software behaved normally and produced the correct
report. >
Test Objective: <Verify that the target-of-test successfully functions under the following high
volume scenarios:
 Maximum (actual or physically- capable) number of clients connected, or

simulated, all performing the same, worst case (performance) business
function for an extended period.

 Maximum database size has been reached (actual or scaled) and multiple
queries or report transactions are executed simultaneously. >
Technique:  <Use tests developed for Performance Profiling or Load Testing.
 Multiple clients should be used, either running the same tests or

complementary tests to produce the worst case transaction volume or mix
(see Stress Testing above) for an extended period.
 Maximum database size is created (actual, scaled, or filled with

representative data) and multiple clients used to run queries and report
transactions simultaneously for extended periods. >
Completion Criteria:  <All planned tests have been executed and specified system limits are
reached or exceeded without the software or software failing. >
Special <What period of time would be considered an acceptable time for high
Considerations: volume conditions, as noted above? >
3.1.3 Security and Access Control Testing
<Security and Access Control Testing focus on two key areas of security:
 Application-level security, including access to the Data or Business Functions
 System-level Security, including logging into or remote access from the system.
Application-level security ensures that, based upon the desired security, actors are restricted to
specific functions or use cases, or are limited in the data that is available to them. For example,
everyone may be permitted to enter data and create new accounts, but only managers can
delete them. If there is security at the data level, testing ensures that” user type one” can see
all customer information, including financial data, however,” user two” only sees the
demographic data for the same client.
System-level security ensures that only those users granted access to the system are capable of
accessing the applications and only through the appropriate gateways. >
Test Objective:  Application-level Security: <Verify that an actor can access

only those functions or data for which their user type is provided
permissions. >
 System-level Security: Verify that only those actors with

access to the system and applications are permitted to access them. >
Technique:  Application-level Security: <Identify and list each user type

and the functions or data each type has permissions for. >
 <Create tests for each user type and verify each permission by
creating transactions specific to each user type. >
 Modify user type and re-run tests for same users. In each case,

verify those additional functions or data are correctly available or

denied.
 System-level Access: <See Special Considerations below>
Completion Criteria: <For each known actor type the appropriate function or data are
available, and all transactions function as expected and run in prior
Application Function tests. >
Special Considerations: <Access to the system must be reviewed or discussed with the
appropriate network or systems administrator. This testing may not be
required as it may be a function of network or systems administration.
>
3.1.4 Regression Testing
<Regression testing is a necessary maintenance activity aimed at showing that code has not been
adversely affected by changes>
Regression testing is to validate modified parts of the software, to make sure

Test Objective:
that the modification does not cause errors in other parts.
 <Reuse the set of test cases from an existing test suite to test a
modified module>.
 <Use Rational Robot tool: Creating some functional test scripts.

Define automated test execution schedule here >
Technique:
 < 80% Test cases is randomly select from >
 < Construct a program-analysis infrastructure. We are building an

extensible infrastructure to implement and evaluate a program-analysis.
Basing on the analysis result, we identify scope of regression test>
 <All test cases are performed and passed>

 <All selected test cases are performed and passed>
Special
Considerations:
3.2 Test stage
<Clearly state the stage in which the test will be executed. Identified below are the stages in
which common test are executed>
Stage of Test
Type of Tests
Unit Integration System Acceptance
<Functional Tests
X X X X
(Function, User Interface)>
<Performance Tests X X

Stage of Test
Type of Tests
Unit Integration System Acceptance
(Performance profiles of
individual components)>
<Performance Tests
X X
(Load, Stress, Contention)>
<Reliability
X X
(Integrity, Structure)>
3.3 Tools
<List tools will be employed for this project>
Purpose Tool Vendor/In-house Version
4 RESOURCE
4.1 Human Resource
This table shows the staffing assumptions for the project.
Worker/Doer Specific Responsibilities/Comments
4.2 System
<List of required hardware and software resources>
5 TEST MILESTONES
Testing of v1.2 should incorporate test activities for each of the test efforts identified in the
previous sections. Separate project milestones, which should be identified to communicate
project status accomplishments.
Milestone Task Effort Start Date End Date

6 DELIVERABLES
No Deliverables Delivered Date Delivered by Delivered to

<Test cases>
<Test procedures>
<Defect log>
<Defect reports>

Template - 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

Template - Test Plan

Uploaded by

Copyright:

Available Formats

FPT SOFTWARE

<Name of the project>

Project Code: <Code of the project>

Document Code: <Code of the document >– v<x.x>

<Location, issued date of the Document>

*A - Added M - Modified D - Deleted

Effective Changed Items A* Change Description New Version

02-BM/PM/HDCV/FSOFT v1.2 2/19

Effort ước lượng ( nằm ở trong kế hoặch)

Ví dụ quen thuộc về test plan

Data đầu vào:

Áp dụng sang làm phần mềm.

02-BM/PM/HDCV/FSOFT v1.2 3/19

ORIGINATOR: <Name> <Date>

REVIEWERS: <Name> <Date>

<Name, if it’s needed> <Date>

APPROVAL: <Name> <Date>

02-BM/PM/HDCV/FSOFT v1.2 4/19

2 REQUIREMENTS FOR TEST...........................................................................................6

3.1 Test types.........................................................................................................................9

4.1 Human Resource..............................................................................................................17

02-BM/PM/HDCV/FSOFT v1.2 5/19

1.2 Background information

1.3 Scope of testing

<Address any constraints on testing. They may be:

- Constraints on resource, schedules, lack of tools, etc.>

02-BM/PM/HDCV/FSOFT v1.2 6/19

1.5 Risk list

2 REQUIREMENTS FOR TEST

<Enter a high level list of major test requirements>

Completion criteria: Completion criteria are stated to for two purposes:

 Identify acceptable product quality

 Identify when the test effort has been successfully implemented

A clear statement of completion criteria should include the following items:

 Function, behavior, or condition being measured

02-BM/PM/HDCV/FSOFT v1.2 7/19

Criteria or degree of conformance to measurement

Constraints, (such as equipment limitations or availability, or the need / lack of special

Special requirements, such as test scheduling or access to systems

Testing may be stopped when

 It requires a certain coverage

 It requires a certain number of errors to be found

 Schedule time runs out

A sample of Test type description:

02-BM/PM/HDCV/FSOFT v1.2 8/19

Stressed workload: 750 users (15 % managers, 50 % sales, 35 % marketing)

Peak workload: 350 users (10 % managers, 60 % sales, 30 % marketing)

Nominal workload: 150 users (2 % managers, 75% sales, 23 % marketing)

 All planned test cases have been executed

 All identified defects have been addressed to an agreed upon resolution

02-BM/PM/HDCV/FSOFT v1.2 9/19

 All high priority test cases have been executed.

 All identified defects have been addressed to an agreed upon resolution.

 All Severity 1 or 2 defects have been resolved (status = fixed or postponed).

 Testing may be stopped when <defect number is over the norm...>

3.1 Test types

3.1.1 Functional Testing

3.1.1.1 Function Testing

02-BM/PM/HDCV/FSOFT v1.2 10/19

- The expected results occur when valid data is used.

- The appropriate error or warning messages are displayed when invalid

- Each business rule is properly applied. >

Completion Criteria: - <All planned tests have been executed.