S OFTWARE Q UALITY A SSURANCE T EST P LAN

Date:

Version:

Status:

Author:

Reviewed by:

Approved by:
 Revision History

Date Version Description Author

 Software Quality Assurance Test Plan

Table of Contents
1 INTRODUCTION.........................................................................................................................................................5

1.1 PURPOSE....................................................................................................................................................5

1.2 BACKGROUND.............................................................................................................................................5

1.3 SCOPE........................................................................................................................................................5

1.4 ASSUMPTIONS.............................................................................................................................................6

1.5 RISKS AND CONTINGENCIES.........................................................................................................................7

1.6 CONSTRAINTS.............................................................................................................................................8

1.7 PROJECT ARTIFACTS...................................................................................................................................9

2 WORK PRODUCTS UNDER TEST..........................................................................................................................10

2.1 XXXXXXX SUPPORTED VERSIONS............................................................................................................10

2.2 TEST MATRIX............................................................................................................................................11

2.2.1 Topology.....................................................................................................................................11
2.2.2 Roles and Configurations...........................................................................................................13
3 TEST REQUIREMENTS...........................................................................................................................................15

NEW FEATURES SHALL BE TESTED........................................................................................................................15

FAULTS FIXED......................................................................................................................................................15
4 TEST STRATEGY.....................................................................................................................................................16

4.1 TEST SCRIPT EXECUTION..........................................................................................................................16

4.2 REGRESSION TESTING...............................................................................................................................16

4.3 TESTING TYPES.........................................................................................................................................16

4.4 TESTING CRITERIA.....................................................................................................................................17

4.4.1 Test Readiness Criteria..............................................................................................................17
4.4.2 Test Stop Criteria.......................................................................................................................17
4.4.3 Test Success Criteria.................................................................................................................17
4.4.4 Regression Test Criteria............................................................................................................17
4.4.5 Engineering Documentation System Criteria.............................................................................18

4.5 TOOLS......................................................................................................................................................18
5 RESOURCES...........................................................................................................................................................18
 Software Quality Assurance Test Plan

5.1 STAFFING..................................................................................................................................................18

5.2 HARDWARE/DEVICES & SOFTWARE............................................................................................................19

5.2.1 Hardware and Devices...............................................................................................................19
5.2.2 Software.....................................................................................................................................20
5.2.3 Machine Setup Model................................................................................................................20
6 COMMUNICATIONS CHANNELS............................................................................................................................20
7 ESTIMATION............................................................................................................................................................21
8 DELIVERABLES.......................................................................................................................................................22

8.1 TEST ARTIFACTS.......................................................................................................................................22

8.2 TEST LOGS...............................................................................................................................................22

8.3 Defect Reports.........................................................................................................................................23

 Software Quality Assurance Test Plan

Test Plan
1 Introduction

1.1 Purpose

This test plan supports the following objectives:

 Identify existing project information and the software components that should be tested
 List the recommended test requirements (high level)
 Recommend and describe the testing strategies to be employed
 Identify the required resources and provide an estimate of the test efforts
 List the deliverable elements of the test project

1.2 Background

VMware is an operating system that provides for the definition of multiple virtual server operating
environments, each running a different O/S potentially, using a single physical server. VMware is
growing in popularity due to the ROI incurred from power and cooling savings along with intangibles such
as reduced administration costs from consolidating multiple physical machines onto a single machine
that is partitioned. Many XXXXXXX partners are shipping hardware with a VMware option and field sales
is reporting an increase in the number of prospects looking for VMware support by their BAR vendor.
Summary benefits of VMware Server:
 Provision a new server in minutes without investing in new hardware.
 Run Windows and Linux operating systems and applications on the same physical server.
 Increase the utilization of a physical server.
 Move virtual machines from one physical host to another without re-configuration.

It is the intention of this document to outline the requirements for testing and validation of the XXXXXXX
7.1.2, and 7.4.2 product s within this operating environment (VMWare ESX 3.0) in order to deem the
solution as supported by the Research and Development organization within the scope of requirements
set forth by the ‘XXXXXXX Software Project Scoping Document - XXXXXXX and VMWare Support’
artifact. This Plan does NOT cover testing of the range of guess operating system support environments
nor the Applications support in guest operating system environments. The intention of this testing will be
to validate the backup and restoration on console and virtual disks on an ESX server version 3.0.

1.3 Scope

The testing is limited to specific tests to cover the functionality addressed by the test suites outlined in
table 1.
 Software Quality Assurance Test Plan

Table 1.Target Test Suites

Test Suite Name Version

Test Suite.doc 1.1

For specific functionality being tested against the proposed environments and configurations please refer
to the respective test suites mentioned above at DMS.

1.4 Assumptions

 All test binaries shall be downloaded from the Binary Management System
 Detailed testscript(s) shall be downloaded from the Document Management System unless otherwise
specified
 If necessary and for XXXXXXX own benefits, XXXXXXX may translate or convert the existing test
script(s) to XXXXXXX own latest format test script(s) but there won’t be any resource time allocate for
this task.
 XXXXXXX may need to ‘specify’ reduced port test sections from the current test script.
 The testscript should be updated with testcases for all fault fixed/new features including in BMSes
under test.
 The modular architecture of the XXXXXXX product limits the scope of faults to impact on modules
other than the module where the fault occurs.
 This test plan is created based on high-level requirements from BKB emails/meetings. Detailed
information should be added during test phases if needed.
 Test artifacts are either resident on the BMS or attached to their relevant FMS/Jira.
 All test documentation is resident on the DMS or official VMware websites.
 XXXXXXX has all necessary equipments and knowledge to setup environment.
 If XXXXXXX is unable to use or is unable to implement the testing with the hardware/test cells in
offshore, then XXXXXXX would need onshore to setup the testing environment. Then new
setup/prepare schedule would need to allocate. It is responsibility of XXXXXXX to notify XXXXXXX if
this is the case.
 If XXXXXXX is unable to perform both XXXXXXX1.x and XXXXXXX4.x at the same time due to
resource problem, it is possible that testing will be serialized. It is responsibility of XXXXXXX to notify
XXXXXXX if this is the case.
 Testing Staff are competent in the operating environments outlined in table 2.0 and they also have a
degree of understanding of VMWare backup and restore methodologies.
 VMWare ESX 3.0 Server Software and Licensing (can be found at Wiki)
 Software Quality Assurance Test Plan

 Technical Contact at VMWare specifically geared towards providing the means for 3 rd Party Software
Validation. If this is not possible technical contacts that can provide thorough and precise support for
technical alliance related issues will require.
 Technical Leads responsible for QA Test Effort issue escalation required.

Table 2.Target Test Guest Operating Systems

X86-32 bits –Target Test Guest Operating Systems

Windows Linux
Windows 2003 SP1 RHELV3U4

X86-64 bits –Target Test Guest Operating Systems

Windows Linux
Windows 2003 SP1 RHELV3U4

Note: Again this testing does not cover a testing of neither the range of guess operating system support
environments nor the Applications support in guess operating system environments

1.5 Risks and contingencies

GENERAL:
 No formal meeting within the Development, QA and PM team for scoping the work before starting a
project.
 XXXXXXX core software may have (known and unknown) issues that could be impact to the
application module.
 There wouldn’t be any new features, or new fault fixes for this release
 Testing being performed by XXXXXXX, lack of experiences of XXXXXXX and VMware may produce
lots of clarification and help request. There should be some buffer time, contingency time allocated for
the project.
 If XXXXXXX has problems executing the test script, it could affect the delivery schedule.
 XXXXXXX will be using hardware/test cells offshore. Remote access to XXXXXXX Lab machines may
be limited and may affect the testing schedule.
 If XXXXXXX unable to use or unable to implement the testing with the hardware/test cells in offshore,
then XXXXXXX would need onshore to setup the testing environment. Then new setup/prepare
schedule would need to allocate. It is responsibility of XXXXXXX to notify XXXXXXX if this is the case.

VMWare:
A1 – XXXXXXX Client on Service Console Validation:
 Software Quality Assurance Test Plan

 Risk1 – XXXXXXX Client software may have issues with ‘/vmfs’ related mount points (Refer to
Article ID 1166 within VMWare Knowledge Base).
 Risk2 – XXXXXXX Client software may have issues with installation on Service Console as the
Service Console runs a proprietary version of Linux (Refer to Article ID 193 within VMWare
Knowledge Base).
 Contingency1 – Development Support may be required if this issue arises and prevents progress
with test efforts.
 Contingency2 – Development Support may be required if this issue arises and prevents progress
with test efforts.
B1 – XXXXXXX Smart Client on Service Console Validation:
 Risk1 – XXXXXXX Client software may have issues with ‘/vmfs’ related mount points (Refer to
Article ID 1166 within VMWare Knowledge Base).
 Risk2 – XXXXXXX Client software may have issues installation as the Service Console runs a
proprietary version of Linux (Refer to Article ID 193 within VMWare Knowledge Base).
 Risk3 – Since the Service Console runs a proprietary version of Linux our SCSI pass-through
driver may not work properly.
 Contingency1 – Development Support may be required if this issue arises and prevents progress
with test efforts.
 Contingency2 – Development Support may be required if this issue arises and prevents progress
with test efforts.
 Contingency3 – Development Support may be required if this issue arises and prevents progress
with test efforts.
C1 – Guest Operating System Virtual Disk File Backup Investigation:
 Risk1 – Not all Linux commands and third-party backup software such as XXXXXXX can access
VMFS directly. Also, this method places a heavy load on the service console, since it has to run
the backup agent software and has to pass all the virtual machine data to tape. As the virtual
disk file grows so does the burden on the system and the network.
 Risk 2 – This may require integration and test efforts that may yield unsatisfactory results.
 Risk3 – If the Service Console Crashes due to issues related to Virtual Disk Backup / Restore
operations then ALL virtual clients will be inaccessible.
 Contingency1 – Other methods to backup Virtual Disk Files will be explored if possible.
 Contingency2 – Other methods to backup Virtual Disk Files will be explored if possible.
 Contingency3 – Other methods to backup Virtual Disk Files will be explored if possible.

1.6 Constraints

A2 – XXXXXXX Client on Service Console Validation:

 Constrain 2.1 – VMFS object files and logs may not be visible or properly accessible to the
XXXXXXX Client Software hence not allowing full recovery of Service Console.
 Software Quality Assurance Test Plan

 Constrain 2.2 – Service Console runs a proprietary version of Linux some standard XXXXXXX
Client Software functions and features may not be available and may require further R&D efforts.
B2 – XXXXXXX Smart Client on Service Console Validation:
 Constraint 4.1 – If Virtual Machine is not available devices and media will also not be available
for backup / recovery operations. These Virtual Machines are recommended to be ALWAYS
accessible to the XXXXXXX Backup Server. If they are not, interaction with the VMWare product
will be required.
 Constraint 4.2 – Dynamic Drive Sharing is currently not supported. Preliminary investigations
related to drive locking/unlocking between virtual clients seems to indicate reboots are required.
The investigation has been limited by external resources.
C1 – Guest Operating System Virtual Disk File Backup Investigation:
 Constraint 5.1 – We are limited by the access level provided by the XXXXXXX Client Software
with relation to the VMFS filesystem. Although there are Pearl API functions that can be
leveraged, the exact result of such integration work is not yet known. This may result in
unsatisfactory results and may require further R&D efforts.
NOTE 1: There are other tools to export the Virtual Disk Files so that they may be backed up and restored but
this is not a area of expertise hence integration efforts may yield substandard solutions. The following are
alternatives to indirectly access to the VMFS filesystem:
o vmkstools (export to NFS mount)
o SAN Image using 3 rd party application

*NOTE 2: It is expected that the XXXXXXX will carry out the test plan. The access to all the necessary test
environments and equipment will be made available where possible, particularly libraries and servers to outside
members of this test team. Although local access for test purposes is not an issue, and remote access can be
made available for coding efforts, limitations by external variables may vary the effectiveness of the test plan
execution.

 The completion date of this project may also depend on the number of defects found during testing and
feedback rate from XXXXXXX development team.
 Physical tape drives and library may not available in offshore for testing. Offshore shall use virtual drive
/ library or shall remote use the devices in SD office. Offshore shall notify XXXXXXX about the
limitation of testing result, due to the lack of hardware.

1.7 Project Artifacts

The table below identifies the documentation and availability pertaining to the project:

Document Created or Received or Author or Notes

(and version / date) Available Reviewed Resource
Requirements Specification  Yes  No  Yes  No Reduced Version has been
provided
 Software Quality Assurance Test Plan

Functional Specification  Yes  No  Yes  No No Functional Spec has been

provided for API work
Use Case  Yes  No  Yes No This methodology has not been
implemented at this time
Project Plan  Yes  No  Yes No No project plan has been provided
Design Specifications  Yes  No  Yes  No No Design Specification has been
provided
Prototype  Yes  No  Yes  No
Users Manuals  Yes  No  Yes  No VMWare Documents are available
via xxxxxxxx or DMS
Data Model / Flow  Yes  No  Yes  No No Data Model / Flow
Specification have been
generated
Project / Business Risk  Yes  No  Yes  No No Risk Assessment has been
Assessment provided

2 Work Products under Test

2.1 XXXXXXX Supported Versions

 XXXXXXX 7.4.2 (BMS ID 8345) would be the primary version for Full test scenario and XXXXXXX
7.1.2 (BMS ID 6566) would be version for Reduced test scenario.

Various binaries will be used to certify specific configurations for use within target VMWare environments. Table
3 outlines those binaries which will be targeted for test and validation.

Table 3.AUT - XXXXXXX Server / Client

X86 Based System – XXXXXXX Server / Client / Related Software

VMWare Server Guest Xxxx Xxxx Testing Binary Xxxx
Operating Installed BMS ID Type? available Server
Systems on (Full or on? BMS ID
VMWare Reduced)
Server
ESX Server 3.0 – x86 based system Windows 7.4.2 8345(GA) Full Now 8368(GA)
2003 latest
sp, Linux
RHEL V3U4
ESX Server 3.0 - x86 based system Windows 7.1.2 6566(GA) Reduced Now 8345(GA)
2003 latest
sp, Linux
RHEL V3U4
 Software Quality Assurance Test Plan

X86-64 Based System – XXXXXXX Server / Client / Related Software

VMWare Server Guest Xxxx Xxxx Testing Binary Xxxx
Operating Installed BMS ID Type? available Server
Systems on (Full or on? BMS ID
VMWare Reduced)
Server
ESX Server 3.0 – x86-64 based system Windows 7.4.2 8363(GA) Full Now 8368(GA)
2003 latest
sp, Linux
RHEL V3U4
ESX Server 3.0 - x86-64 based system Windows 7.1.2 6610(GA) Reduced Now 8345(GA)
2003 latest
sp, Linux
RHEL V3U4

The primary goal will be to conduct basic backup and restore testing on the ESX Server 3.0 based on the
VMWare test suite.
Test environments breakdown:
ESX Server 3.0 will have two guess operating systems:
 Windows 2003 latest sp
 Linux RHELV3U4

2.2 Test Matrix

The following matrix is reviewed by XXXXXXX. For each of the combinations, XXXXXXX selects the type
of testing needed. Some of the combinations can be skipped. Some others may not be available and not
need to be validated. In the table below, only the ones that offshore shall test are listed. For a complete
list of all combinations, please find it in the spreadsheet attached below.
The table also contains the BMS ID’s used for testing. It shall be updated with the IDs during the
execution phase.

# Tier Priority VMWare Server Xxxx Xxxx Testing Binary Xxxx Duration Start/Finish
Installed on BMS ID Type? (Full available Server Date
VMWare or Reduced) on? BMS ID
Server
1 1 1 ESX Server 3.0 on 7.4.2 8345(GA) Full Now 8368 (GA) 07 days 07/13/2006
x86 based system 07/25/2006
2 1 2 ESX Server 3.0 on 7.1.2 6566(GA) Reduced Now 8345 (GA) 05 days 07/26/2006
x86 based system 08/1/2006
3 2 3 ESX Server 3.0 on 7.4.2 8363(GA) Full Now 8368 (GA) 07 days On Hold
x86-64 based system
4 2 4 ESX Server 3.0 on 7.1.2 6610(GA) Reduced Now 8345 (GA) 05 days On Hold
x86-64 based system
Note: The 64-bit testing project is on hold until further notice from XXXXXXX and the decision whether to support 64-
bit environment will be determined.
 Software Quality Assurance Test Plan

2.2.1 Topology

Table 4 outlines the topology and ESX / Virtual Machine relationship which will be targeted for test and
validation. There are various approaches to testing based on hardware availability. Topologies A through C are
based on limited resource availability. Topology D is based on abundant resource availability.

Note: Increases in hardware availability for testing yields more parallelism and allows for adjustments which can
be advantageous to the test schedule.

Table 4.VMWare Topologies

A B C
 Software Quality Assurance Test Plan

Figure 1.VMWare Validation Topology

2.2.2 Roles and Configurations

The configurations targeted for test and validation include various operating systems and binaries
running as guest operating environments within Virtual Machines hosted by the ESX server. These
environments will be targeted for backup and restore operations via two main Backup Server Domains.
These environments are listed in table 4 and should be reviewed for approval.
 Software Quality Assurance Test Plan

Table 5.Environments Under Test - Roles and Configurations

Configuration
System Operating System Role

1 CPU: 1.5 Ghz

MEM: 512MB
Primary Backup Server
Storage: 50GB Disk Space
Domain A
A Windows 2003 SP1 NetWork: 1 10/100BT
(Will be used for this
1 SCSI / Fibre HBA
testing)
1 Dual Drive Library

1 CPU: 1.5 Ghz

MEM: 512MB
Secondary Backup Server Storage: 50GB Disk Space
B RHEL V4 U1 Domain B NetWork: 1 10/100BT
(Optional) 1 SCSI / Fibre HBA
1 Dual Drive Library

1 CPU: 1.5 Ghz

MEM: 512MB
Tertiary Backup Server Storage: 50GB Disk Space
C Windows 2003 SP1 Domain C NetWork: 1 10/100BT
(Optional) 1 SCSI / Fibre HBA
1 Dual Drive Library

2 CPU: 1.5 Ghz

MEM: 4GB*
Storage: 500GB Disk Space
ESX Server
D Primary VMWare Server NetWork: 1 10/100BT
Version 3.0
1 SCSI / Fibre HBA
1 RAID Subsystem

E Windows 2003 SP1 Virtual Client 1 24MB+192MB+(1.06*1*(256MB+54MB))

Core Testing

F RHELV4U3 Virtual Client 2 24MB+192MB+(1.06*1*(256MB+54MB))

Core Testing
 Software Quality Assurance Test Plan

*Total System Memory will depend on minimum guest operating system requirements (highlighted in bold within
table 5) and a formula which outlines ESX server / Console and virtual system requirements. This formula is as
follows:
 24MB_192MB+(1.06*N*(M+54MB)) where N=number of virtual machines and M=total target
memory for each virtual machine.

3 Test Requirements
This section states testing scope for VMWare ESX 3.0 backup and restoration.
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:

Configurations
1. XXXXXXX Server running on Windows 2003 SP1 with XXXXXXX 7.4.2 and 7.1.2
2. XXXXXXX Client running on ESX Server 3.0 with XXXXXXX 7.4.2 and 7.1.2
Operations
1. Filesystem Backup to Primary Servers via locally attached device(s). Data from Virtual Machines
(Refer to table 2 for details) and ESX Service Console.
2. Filesystem Restore from Primary via locally attached device(s). Data to Virtual Machines (Refer
to table 2 for details) and ESX Service Console.
3. Filesystem Backup² to Primary and Secondary Servers via Smart Client with remotely attached
device(s). Data from Virtual Machines (Refer to table 2 for details) and ESX Service Console.
4. Filesystem Restore² from Primary and Secondary Servers via Smart Client with remotely
attached device(s). Data to Virtual Machines (Refer to table 2 for details) and ESX Service
Console.
5. VMFS – Virtual Machine File direct Backup and Recovery.
Major Components to be tested for backup and recovery
 Virtual disks
 Virtual machine configuration files
 The configuration of the ESX Server itself
New features shall be tested

This is strictly a compatibility/validation testing with new version of VMWare ESX server 3.0 for a GA
XXXXXXX server and client products. So no new features validation required for this project.
Faults Fixed

This is strictly a compatibility/validation testing with new version of VMWare ESX server 3.0 for a GA
XXXXXXX server and client products. So no faults validation required for this project.
 Software Quality Assurance Test Plan

4 Test Strategy
The Test Strategy presents the recommended testing approaches. The previous section on Work Products Under
Test and Test Requirements described what should be tested; this describes how it shall be tested.
Phase 1: The primary strategy will be to determine if there are any issues with simple backup and restore operations
when conducting said operations on ESX Server 3.0 service console server which also has two guest operating
environments hosted by VMWare Virtual Machines. The primary tool for this will be the VMWare ESX Test Suite.doc,
the file system plugin test script (if applicable), test data generation, and test data validation tools. In addition there
may be a need to run subsequent test cases based on findings resulting from those efforts.

4.1 Test Script Execution

Test Suite Name Version

Test Suite.doc 1.1

 Full Test: All of the test cases in the related test scripts and common plugin test script must be run.
 Reduced Test (Port Test): All of the test cases marked as “Port Test” in related testscripts must be run.
(Note: XXXXXXX may need to ‘specify’ or define reduced port test sections from the current test script)
 QA cannot skip any test cases in the test scripts without approval from QA lead engineer.

4.2 Regression Testing

 New fault found during regression testing shall be retested again, once XXXXXXX provides new binary that
addresses the issues. However, it is the right of XXXXXXX to determine whether the fixes should be
included in the release or not.
 When receiving new binary to address bad fixed FMSes, only FMSes retested not fixed and not started in
previous binaries shall be tested in this new binary.
 Testing shall be completed when all tests in the test plan (Testscript execution and regression testing) pass
on the designated platforms and documentation is uploaded to DMS.

4.3 Testing Types

Phase Unit Test Integration Test Testing Type

Phase 1 N/A N/A System Testing (Test script Execution)
Phase 2 N/A N/A Regression Testing

The following table outlines the test iterations to be executed per platform targeted for validation (outlined in table 2)
as follows:
 Software Quality Assurance Test Plan

Table 6. Test Iterations

Iteration Unit Test Integration Test System Test/Acceptance Test

<Iteration 1> N/A N/A VMWare – Full and Reduced
Outstanding FMS Testing

4.4 Testing Criteria

4.4.1 Test Readiness Criteria

 Test plans are reviewed, updated and approved.

 Testcases for faults fixed/new features in related ERN must be added to testscript.
 All related hardware devices to setup test environment are ready for testing.
 XXXXXXX Core and xxxx binaries are available.
 XXXXXXX build available, test environment / equipment available and configured, tests reviewed
and a testing order determined.

4.4.2 Test Stop Criteria

 Successful completion of all specified tests (see test success criteria)

 Critical/High faults found during testing are not fixed.
 When no targeted functionality is testable for whatever reason.
 Note a showstopper in one area of functionality should not be allowed to hold up the continuation
of testing in other areas of the build.
 All Test Deliverables have been produced and uploaded.

4.4.3 Test Success Criteria

 No Severity 1 level issues. As defined in the XXXXXXX Customer Support Handbook, Severity 1
issues are defined as: “Customer cannot recover data critical to its business, and there is no
workaround available.”
 For test specifications being run pass criteria is stated in those documents.
 No compatibility issues with ESX Server 3.0. XXXXXXX should support ESX Server 3.0 constantly
as it does with previous VMWare ESX Server versions being supported (ESX 2.5.x…)
 Finish all test scripts and all are marked as Passed for designated platforms in the scope.
 Finished all other test cases in the scope and the result is reviewed/accepted/approved by QA
Lead Engineer.

4.4.4 Regression Test Criteria

 Software Quality Assurance Test Plan

 Regression testing coverage shall be determined by consultation with development and the QA
lead engineer.
 The trigger for regression testing shall be changed which put critical or high importance
functionality at any real risk

4.4.5 Engineering Documentation System Criteria

 Any limitations or restrictions of the plugin shall be documented in the Engineering Release Notes
(ERN)
 Based on SQA process, Application Note or ERN for this project should be created and completed
by test team if needed.

4.5 Tools

The following tools shall be employed for this project:

Tools Name Tool Vendor/In-house Version Location
Testing Process SQA Process.doc In house 2.2 xxxxxx
Defect Tracking Jira system In house 3.0 xxxxxx
Project Management Project Microsoft 1.0 xxxxxx
Schedule.mpp
DBMS tools xxxx specific N/A N/A xxxxxx
Test Data Test Data Generator In house TBA xxxxxx
VMWare Account xxxxxxx In house N/A xxxxx
Information
VMWare Technical xxxxxxx N/A N/A xxxxx
Information

5 Resources
This section presents the recommended resources for the testing of VMWare ESX 3.0 project, their main
responsibilities, and their knowledge or skill set.
This table shows the staffing assumptions for the project. More QA resources shall/can be staffed in the future based
on workload and deadline of the release.

5.1 Staffing

Worker Minimum Resources Recommended Specific Responsibilities/Comments

(Number of workers allocated full-
time)
Test Manager xxxx  Provides management oversight
 Software Quality Assurance Test Plan

Worker Minimum Resources Recommended Specific Responsibilities/Comments

(Number of workers allocated full-
time)
 Acquire appropriate resources
 Management reporting
QA Lead Engineer xxxxx  Generate test plan
 Identifies, prioritises, and implements test cases
 Provide technical direction
 Evaluate effectiveness of test effort
 Participate partly in testing activities
QA Engineer XXXXXXX x 2  Update testscript with testcases for new features
 Execute tests
 Log results
 Recover from errors
 Document defects
 Report progress and test run issues

5.2 Hardware/Devices & Software

5.2.1 Hardware and Devices

5.2.1.1 On x86 Based System

 1 ESX Server: Use test cells offshore.

 1 XXXXXXX Backup Server: Use test cells offshore
 Tape Device (use VTL or physical device)

5.2.1.2 On x86-64 Based System

 1 ESX Server: Use remote test cells from SD Lab.

 1 XXXXXXX Backup Server: Use remote test cells from SD Lab.
 Real Tape Device

The following table sets forth the system resources for the testing project.

System Resources
 Software Quality Assurance Test Plan

Resource Name / Type

Network/Subnet Required
Required – Type dependant on build under
Server XXXXXXX platforms
test. - See Section 2 above.
Required – Type dependant on appliance
VMWare ESX Server platform
under test. - See Section 2 above.
Required – Type dependant on build under
Client XXXXXXX platforms
test. - See Section 2 above.
Required – Must be compatible with ESX
Tape Library or Equivalent
Server Software
Required – Must be compatible with ESX
RAID
Server Software

5.2.2 Software

XXXXXXX will download ESX Server 3.0 ISO from VMWare web site.
xxxxxxxxxxxxxxxxxxxxx

5.2.3 Machine Setup Model

This section states the machine setup model for the execution of this project.
 01 ESX Server 3.0 for each testing (71.2 and 7.4.x)
 01 xxxxx for each testing (7.1.2 and 7.4.x)
 If possible, use real tape drive or tape drive library. Otherwise, use VTL.

6 Communications Channels
All project communications/issues/problems are handling following the channels in the chart above:
Contact information:
xxxxxxxxxxxxxxxxxxxxxxxxxxxx

7 Estimation
The below table presents the estimation for this project. The project cycle is broken down into Plan /
Prepare / Execute / Closure phase with appropriate high-level tasks. Please refer to project schedule
(MPP) file to get more detail information about tasks, progress, and milestones with appropriate start
dates, end date, assigned resources

Phase Task Effort (man-day)

Gather and review requirements, specifications 1
Plan
 Software Quality Assurance Test Plan

Create test plan 1

Review Test plan 1
Total Plan Effort: 3
Add/Modify testcases 0
Prepare
Review/Approve new testscript (XXXXXXX and XXXXXXX) 0
Total Prepare Effort: 0
Installation and ENV configuration (for each x86/x86-64 based system)
3
Full Test Scenario
Execute
Test_Suite_v10_OCT_2005
4
Reduced Test Scenario
Test_Suite_v10_OCT_2005
3
Total Execution Effort for 1 Full Test and 1 Reduced Test: 10
Total Execution Effort on 2 systems (2 Full Test, 2 Reduced Test): 20
Review/approve test result 0.5
Closure
Create test summary report 0.5
Total Closure Effort: 1
Total Effort (man-days): 24
Total Duration (2 engineers) - Working Days: 12
Tentative Schedule (Execution & Closure only) - Calendar Days: July 13– August 1

8 Deliverables
This is the list of deliverable items necessary for this project. It includes deliverable items from XXXXXXX
to XXXXXXX and from XXXXXXX to XXXXXXX. For all test specs run:
A copy of the specification that has been run, renamed to reflect the test build under test.

# Deliverable Name From Status/Action Comment

1 Test Plan Tham Nguyen XXXXXXX/ This document will be updated during the
Reviewed course of the project, for any changes in
scope / requirement.
2 Test Script XXXXXXX XXXXXXX/
Reviewed/
Updated
 Software Quality Assurance Test Plan

3 Binaries for Testing XXXXXXX GA/MA Binaries for XXXXXXX and other plugins
if applicable
4 Test Result XXXXXXX N/A Completed testscripts, ERN
5 Test Summary Report, Fault XXXXXXX N/A
Report
8 Project Plan Vu Pham N/A To monitor and report tasks
Don Le
Brandon Pham

8.1 Test Artifacts

 Test Plan (this document)

 Related test scripts
 Engineering Release Notes of related binaries.
 Test Suites
 Jira Audit
 Specific data sets created and used in the testing.
 Application Notes
 Training Materials
8.2 Test Logs

 Completing testscripts document

 Fault Report of the project (FR)
 Test Summary Report of the project (TSR)
 Completing worksheet of fixed faults new features (ERN)
8.3 Defect Reports

 Defects are to be recorded in fault records raised or resubmitted in the Jira system. Any fault that is to
be tested shall be included in this test plan, Test Report and/or Engineering Release Notes (ERN) of
related BMS.
 Defects are included also in Test Summary Report in Closure phase.
 Please remember to refer to the software quality assurance (SQA) process document found at the following
location in DMS, for process guidelines: Documents/Test and Quality Assurance/Process, Procedures and
Guides/SQA Process Document/SQA Process.doc