Institutional and Sector Modernisation Facility

ICT Standards
Project Funded by the European Union
ICT Acceptance procedures

Document number: ISMF-ICT/3.17
Version: 1.00

1 Document control

1.1 List of Abbreviations

Abbreviation Description
E-Gov E-Government
ISMF Institutional and Sector Modernisation Facility
MoCT Ministry of Communications and Technology
MoAg Ministry of Agriculture
MoEl Ministry of Electricity
MoET Ministry of Economy and Trade
MoF Ministry of Finance
MoI Ministry of Industry
MoP Ministry of Petroleum
MoT Ministry of Transport
NISFED National Information System For Economic Development
PICU Project Implementation and Coordination Unit (from ISMF)
PMO Office of the Prime-Minister
SCS Syrian Computer Society
SPC State Planning Commission
STE Syrian Telecommunications Establishment
TOR Terms Of Reference
TFIP Task Force Industrial Policy
SVGA Super Video Graphics Array
OS Operating System
DDR Double Data Rate
CD Compact Disc
CD-RW Compact Disc Re Writable
DVD Digital Versatile Disk
DVD RW Digital Versatile Disk Re Writable
Wi-Fi Wireless Fidelity
LCD Liquid Crystal Display
S/N Serial Number
CPU Central Processing Unit
USB Universal Serial Bus
SMART Self-Monitoring, Analysis, and Reporting Technology
RAID Redundant Array of Independent Disks
IP Internet Protocol
MAC Media Access Control
SNMP Simple Network Management Protocol
VLAN Virtual Local Area Network
QOS Quality Of Service
1.2 Purpose of the document
The purpose of this document is to define the standards and deliverables for User Acceptance
Testing for the Syrian Public Sector (Ministries and their directorates, public institutions and
organizations). This document also provides a template and instructions for developing a User
Acceptance Test Plan for a specific application.

2 Introduction
The user acceptance test standard guide aims to implement a program of acceptance
procedures for the Syrian Public Sector information systems and/or related studies.
This document is to be used by the Project Managers or anyone tasked with preparing a User
Acceptance Test Plan.
This document consists of two major parts:
Software and Integrated Systems Acceptance Test Plan
Hardware and Network Acceptance Test Plan
2.1 User Acceptance Test Standards
The purpose of this section is to define the levels of testing required for User Acceptance
Testing, depending on the extent of change being applied to the system.
2.1.1 Overview
This section is a descriptive overview, which will assist in developing a User Acceptance Test
Plan.
The possible levels of testing required in a User Acceptance Test Plan are:
New System Test: where the system to be tested is entirely new (is not an enhancement
or system upgrade).
Regression Test: where the amount of change in an existing system requires a full
system retest.
Limited Test: where the amount of change in an existing system requires only change
specific testing.

2.1.2 New System Test
The Purpose is:
To ensure that the system meets all specified objectives;
To ensure that all requirements are included in the new system.
The planning of the User Acceptance Test must be as early in the life cycle as possible. It is
important that the original project scope is verified in the User Acceptance Test Plan by
including the key points of the original project documentation in the test scripts.

The Following Material can contribute to the Test Plan (if available):
Systems Analysis documentation, System Design Document, Project Statement, Technical
documentation, Online Help/Documentation, User Training material, User Manual, Application
Change Requests, Contractor Test plans, Contractor Test Results, Similar User Acceptance
Test Plans (from other systems).

2.1.3 Regression Test
The Purpose is:
To ensure the "entire" system is working correctly;
To ensure that system changes have not changed existing functionality;
To ensure that the new development work meets all requirements.

The planning of the User Acceptance Test must begin as early in the life cycle as possible. It is
important that the original project scope is verified in the User Acceptance Test Plan by
including the key points of the original project documentation in the test scripts.

The Following Material can contribute to the Test Plan (if available):
Requirement documentation, System Design documentation, Project Statement, Technical
documentation specific to the changes, Online Help/Documentation, User Training material,
User Manual, Contractor Test plans, Contractor Test Results, Previous User Acceptance Test
Plans.

2.1.4 Limited Testing
The Purpose is:
To ensure the "entire" system is working correctly;
To ensure that system changes have not changed existing functionality;
To ensure that the new development work meets all requirements;
2.2 Methodology
The key to a successful project is gaining acceptance from the customer that each
deliverable produced meets (or exceeds) his/ her requirements. To clarify the criteria used to judge each
deliverable for customer acceptance, an Acceptance Test Plan is produced. The Acceptance Test Plan provides
the criteria for obtaining customer acceptance, a schedule of acceptance reviews within which customer
acceptance will be sought and a summary of the process used to gain acceptance of each deliverable
from the customer.

The acceptance test plan incorporates four phases:
Defining the acceptance test criteria;
Developing an acceptance test plan;
Executing the acceptance test plan;
Reaching an acceptance decision based on the test results.

The testing process begins by developing a comprehensive plan to test the general
functionality and special features on a variety of platform combinations. Strict quality control
procedures are used. The process verifies that the application meets the requirements
specified in the system requirements document and is bug free. At the end of each testing day,
the team prepares a summary of completed and failed tests. A report is prepared at the end of
testing to show exactly what was tested and to list the final outcomes.
Without a testing methodology, the actual test tends to be all over the place. The real answer is
that a methodology is required to test anything thoroughly.

Acceptance committee should perform inspections and testing for samples from the delivered
hardware, software or network devices to ensure that they are conformity with the contract.
The delivered equipments should be conformity with contract requirements in quantity and
specifications.

2.3 Assessing the Test Types for a Test Plan
The purpose of this section is to describe the process of planning and assessing the level of
testing required for a specific application.

2.3.1 Overview
To complete a User Acceptance Test Plan for a specific system, the tests must first be planned
based on the initial system project documentation. By researching the purpose of the
development work, and the degree to which this development work will affect the rest of the
system, the scripts needed for testing can then begin to be created. (A test script ' includes the
individual test steps to be executed in order to verify a system is working as expected).

The development of a User Acceptance Test Plan involves a number of iterative steps:
Assess the type of testing required
Develop the procedures and instructions for testing
Develop the necessary test scripts
Execute the test scripts
Report any defects
Retest any fixes
2.3.2 Assessing the Test Type Required
The criteria for determining the degree and type of testing that may be required are listed
below. They can be used as a guide for determining what test scripting will be required for a
particular User Acceptance Test Plan. If the system changes to be tested fall in more than one
criterion, then multiple test script types may be required. Once the appropriate test types to
follow have been determined, the User Acceptance Test Plan can be completed.

New System (not replacing an existing system).

When developing the User Acceptance Test Plan there should be involvement in the
design and reviews of the new system with the contractor. The User Acceptance Test
Plan should be developed with communication from the contractor and with as much
information gathered through the system documentation as possible.

New System (replacing an existing System).

The Test Plan should be developed using the required aspects of the system that is
being replaced. Test scripts for any enhancements to the new (replacement system)
should be developed as if the system is a new system basing information of
requirement and design documents. Running a parallel test with the old system, and
comparing critical report results would be the optimal test scenario for any functionality
that is to be duplicated in the new system.

Database Change (no other change to the System)

In this case running a parallel test with the system using the old database and the
system using the new database is advised. Comparing critical report results would be
the optimal test scenario to ensure that the new database and drivers are producing
identical results to the old system. Performance testing should be included in these test
criteria. Create a User Acceptance Test Plan to manage the parallel test.

System Enhancement (the existing system is enhanced with new functionality).

Test scripts should be developed and tested to ensure that the new functionality is
integrated with the existing system correctly, and to ensure that no existing functionality
has been lost in the enhancement process. Test scripts should be developed based on
the specific requirements for new functions. In this case, unchanged functions may not
require testing, if they are not involved in any business processes which have been
changed.

System Enhancement (the existing system is being enhanced to change the existing
functionality).

Test scripts should be developed based on the requirements documents to ensure that
the system meets its enhanced requirements. Existing test scripts can be amended in
this case. Test scripts should also be developed and tested to ensure that the
enhanced functionality is integrated with the existing system correctly, and to ensure
that no existing functionality has been lost in the enhancement process. In this
scenario, for every function that has been changed, or is affected by a change, new
data or new functionality should be tested to assure that existing functionality is not lost.
This will ensure that the new requirements are being met.

Infrastructure Change (the system is not changing but a test is required to port it to a new
environment, new server, or the system be being utilized for a new division or purpose).

In this case, a full test of test scripts and all business processes should be repeated as
new environments can create unexpected problems for an existing system.

2.4 Testing Environment
The hardware, software and network environment within which a system will be tested must be
defined.
2.5 Status Reporting
Test preparation and testing progress should be formally reported during a weekly Status
Meeting. The status report will be prepared by the Test Controller.
2.6 Test Schedules
A test schedule that shows a high level view of the project must be defined.
Test schedule is a timeline for software and integrated systems tests, hardware and network
tests.
2.7 Roles and Resources

Roles and Resources must be defined, giving the time frame that their tasks must be finished.
The following table can be used for initial planning, assignment and subsequent follow up.

Resource Type Resource Title No. Date
Required
Who Status
Project
Mgmt/Functional
Business Analyst 1
Testing Test Controller 1
Testers 4
Test Support Team Support Programmers 4
Technical Support 1
Network Support 1
Technical - External 1
External Liaison
Support
1
Business Business Expert/
Business
Representative
1
3 Appendix A: Software and Integrated Systems Acceptance Test
Plan
3.1 Testing Approach
The test mechanism that will be adopted on the project can be defined from the following or a
combination of them:
Manual Test ;
GUI testing tools ;
Code ;
Script.
3.2 Test Reports
A status report will be prepared by the Test Controller. This report will contain the following
information:
Current Status v. Plan (Ahead/Behind/On Schedule) ;
Progress of tasks planned for previous week ;
Tasks planned for next week including tasks carried from previous week ;
Error Statistics from Error Measurement system ;
Issues/Risks.
3.3 Software Tools
The software tools that will be used during the test process must be defined (if applicable).
3.4 Testing Process
The diagram below outlines the test process approach that should be followed.
Organise Project involves creating a System Test Plan, Schedule & Test Approach, and
requesting/assigning resources;
Design/Build System Test involves identifying Test Cycles, Test Cases, Entrance & Exit
Criteria, Expected Results, etc. In general, test conditions/expected results will be
identified by the test team in conjunction with the project business analyst or business
expert. The test team will then identify test cases and the data required. the test conditions
are derived from the business design and the transaction requirements documents.
Design/Build Test Procedures includes setting up procedures such as error management
systems and Status reporting, and setting up the data tables for the automated testing tool;
Build Test Environment includes requesting/building hardware, software and data set-ups;
Execute Project Integration Test ;
Execute Operations Acceptance Test ;
Signoff - Signoff happens when all pre-defined exit criteria have been achieved.

Testing Process Roles and Responsibilities
Project Manager:
Creating a System Test Plan;
Creating Schedule & Test Approach;
Assigning Resources;
Signoff.
Testing Team & Business Analyst:
Identify Test Cycles;
Identify Test Cases;
Identify Entrance & Exit;
Identify Expected Results;
Build Test Environment.
Testers:
Execute Project Integration Test;
Execute Operations Acceptance Test ;

Testing Process
Design/Build System Execute Organise Project
System Test
Plan
identify Test
Cycles
all pre-defined
exit criteria
have been
achieved
Identify
Expected
Results
Execute Project
Integration Test
Execute
Operations
Acceptance
Test
identify Test
Cases
Build Test
Environment
Signoff
Identify
Entrance & Exit
Criteria
End
YES
Schedule & Test
Approach
requesting/
assigning
resources
NO

3.5 Testing Scope
Outlined below are the main test types that will be performed. All system test plans and
conditions will be developed from the functional specification and the requirements catalogue.
3.5.1 Functional Testing
The objective of this test is to ensure that each element of the application meets the functional
requirements of the business as outlined in the:
Requirements Catalogue;
Business Design Specification ;
Development Standards ;
Other functional documents i.e. resolution to issues/change requests/feedback.
This stage will also include Validation Testing - which is intensive testing of the new Front end
fields and screens. Windows GUI Standards; valid, invalid and limit data input; screen & field
look and appearance, and overall consistency with the rest of the application.
The third stage includes Specific Functional testing - these are low-level tests which aim to test
the individual processes and data flows.
3.5.2 Integration Testing
This test proves that all areas of the system interface with each other correctly and that there
are no gaps in the data flow. Final Integration Test proves that system works as integrated unit
when all the fixes are complete.
3.5.3 Business (User) Acceptance Test
This test, which is planned and executed by the Business Representative(s), ensures that the
system operates in the manner expected, and any supporting material such as procedures,
forms etc. are accurate and suitable for the purpose intended. It is high level testing, ensuring
that there are no gaps in functionality.
3.5.4 Performance Testing
These tests ensure that the system provides acceptable response times.
3.5.5 Regression Testing
A Regression test will be performed after the release of each Phase to ensure that:
There is no impact on previously released software, and
To ensure that there is an increase in the functionality and stability of the software.
The regression testing can be automated using an automated testing software (if applicable).
3.5.6 Bash & Multi-User Testing
Multi-user testing will attempt to prove that it is possible for an acceptable number of users to
work with the system at the same time. The object of Bash testing is an ad-hoc attempt to
break the system.
3.5.7 Technical Testing
Technical Testing will be the responsibility of the Development Team.
3.5.8 Operations Acceptance Testing (OAT)
This phase of testing is to be performed by the Systems Installation and Support group, prior to
implementing the system in a live site. The testing team will define their own testing criteria,
and carry out the tests.

3.5.9 Types of Testing

There are three types of testing:

Form-Based Testing

To verify that individual application forms are performing correctly;
To ensure that all required fields and buttons exist on the application forms;
To ensure that the flow of information and data entry is logical and correct based on
the applications business requirements;
To ensure that a new form added to an existing application is functioning according to
specifications;
To verify that new functionality added to an existing form has not adversely affected
the existing functionality on that form;
To ensure that the flow of fields on a new form is sensible;
To check common relationships of fields between forms;
To verify navigation between forms.

Material to Review:

Requirement documentation;
Technical documentation;
Analysis documentation ;
Contractor Test plans;
Contractor Test Results;

Business Process Testing:

To ensure that all business related functions and processes are supported by the
application;
To ensure that the flow of data and screens is logical for each business process;
To ensure that security and access requirements are met;
To test the application with "real" scenarios;
To test all batch processes;
To test for performance related problems;
To test the applications interfaces.

Material to Review:

Requirement documentation ;
Technical documentation ;
Analysis documentation;
Contractor Test plans;
Contractor Test Results;
Previous User Acceptance Test Plans;
Security Information;
Business Process Documentation.

Report Testing:

To ensure that the new report meets its requirements;
To ensure that the data extracted for the new report is correct;
To ensure that the report format is correct and logical;
To ensure that the print process is working correctly;

Material to Review:

Requirement documentation;
System Design Documentation;
Technical Specifications;
Contractor Test Plans;
Contractor Test Results;
3.6 Creating a Software and Integrated Systems Acceptance Test Plan
3.6.1 Instructions for the User Acceptance Tester
New System and Regression Testing Instructions
The purpose of regression testing and new system testing is to assure that the entire
application is functioning correctly. This test plan is designed to ensure that all components of
the application are tested. Complete all test scripts included within this test plan for all
applicable user levels and modules as listed.
Form-Based Testing Procedures
The purpose of testing the individual forms and the user interface is to assure that all of the
Menus and Graphical Interface buttons, pull down lists, scrolling lists, and check boxes are
performing correctly. It is important to perform each interface for each module/screen as not all
modules have the same buttons or menus.
Business Process Testing Procedures
The purpose of testing the Business Processes is to ensure that all of the functional
requirements for the application are performing correctly. It is important to complete all test
cases for each User Security level (e.g. System Administrator, Processing Clerk etc.) This will
assure that each Security Level has access to the appropriate functions.
Report Testing Procedures
Ask Users to specify which data they would like to report on. It is important that this process is
tested for each module. If the result of printing is not as expected be sure to fill out a defect
report form for that test.

It is important to repeat each test script for the different user Security levels listed in the User
Security Matrix to ensure that report security rules are functioning correctly.
Defect Reporting
Defect Tracking Form
A Defect Tracking Form must be completed at the time that a problem is found in order to
assure that all details are documented correctly.
Defect Tracking Log
3.6.2 Form-Based Testing
Listed below are the modules to be tested. Each Screen should be reviewed for correctness
as per the Form-Based Test Script.
List of Modules to be reviewed for Form-Based Testing

Module ID Module name
Form-Based Test Script
This checklist must be completed for ALL modules as listed above. Photocopy this page for
each online module and fill in the module identifier in the space provided. Complete the test
environment information. Attach a Defect Report if necessary to describe any anomalies.

MODULE: ____________________

TEST ENVIRONMENT:
Operating System: _____________ Network: _____________________
Workstation Memory: __________

Form Based Testing Component Pass/Fail Date Initials
1. Are all fonts, colours, shading and toolbars consistent with
standards and project guidelines?

2. Is the online help module available?
3. Are all date formats correct (DD-MON-YYYY) Are the
date edits being correctly applied? Are dates greater than
2000 accepted?

4. Does all text wrap when displayed in the text editor?
Form Based Testing Component Pass/Fail Date Initials
5. Is there a scroll bar on every applicable block?
6. Is the Toolbar List button enabled only when a list of
values is available for an item?

7. Do the window titles correctly identify each module?
8. Is there hint text available for all applicable items?
9. Do all of the initial 'window display' sizes fit entirely on
the screen (assuming an SVGA 800x600 resolution)?

10. Are the correct items case sensitive? (i.e. Do fields allow
lower case text if they should only accept upper case?)

11. Are error, warning and information messages accurate and
understandable?

12. Do all DELETE operations display a Delete
Confirmation alert?

13. Is the field tab order correct
14. Are the appropriate edits done on all fields (range of
values, valid values etc.)

15. Are defaults appropriate?
16. Are the correct fields mandatory?
17. Is the tool bar present and appropriate buttons enabled?
18. Are screen & field labels appropriate?
19. Are fields & buttons ordered appropriately?
20. Are all codes valid?
21. Are all field labels are consistent across the application
3.6.3 User Security Matrix
List all User IDs available for testing:
Examples:
SYS_ADMIN System Administrator access to all
CLERK Processing Clerk limited access
REPORT Reporting Clerk Access reports only
List all security access availability for each user level in the spreadsheet below.
User Security/Access Level Matrix
USER ROLE Module
Label
Module Description Details Module
Type
1
2
3
4

3.6.4 User Acceptance Business Process Test Scripts

Sample- Main Menu
Using module <insert module ID>, complete the following checklist. Complete the User
Security Level information and Test Environment information at the top of each form. Attach a
Defect Report if necessary to describe any anomalies.

USER SECURITY LEVEL: ___________________________

TEST ENVIRONMENT:
Operating System: _____________ Network: ______________
Workstation Memory: __________

Acceptance Testing Action Pass/Fail Date Initials
Does each button navigate to the correct module?
Is the correct module name/date/version # displayed at the
top of the window?

Are the appropriate buttons available, (based on the security
matrix)?

Are the appropriate menu options available, (based on the
security matrix)?

Access to application not allowed unless user is set up in
Staffs and as an active application user (as defined in user
detail maintenance)

Does the message/text box display text correctly?
Do the graphics appear clearly and display correctly?
Does the menu bar appear at the top of the page?
3.6.5 Report Test Scripts
Sample- Detailed Information Report
Using report <insert report ID>, complete the following checklist. Complete the User Security
Level information and Test Environment information at the top of each form. Attach a Defect
Report if necessary to describe any anomalies.

USER SECURITY LEVEL: ___________________________

TEST ENVIRONMENT:
Operating System: _____________ Network: ______________
Workstation Memory: __________

Acceptance Testing Action Pass/Fail Date Initials
Can you access the Report module from the main menu?
Are all appropriate reports listed based on the Security of the
user being tested?

Can you access the Detailed Information Report from the list
of available reports?

Is the correct report name/date/version # displayed at the top
of the window?

Are the appropriate buttons available (based on the security
matrix)?

Are the appropriate menu options available (based on the
security matrix)?

Can you pull up the report to view on screen?
Does all appropriate information list correctly?
Does all information sort correctly?
Do all dates display correctly DD-MM-YYYY?
Are the fields available appropriate to the data displaying?
Does the report display with adequate room for each column
(no overlapping test or columns running into other columns)

Is all formatting correct (bold, italics, underline)?
Can you print to the printer?
Does all appropriate information list correctly?
Does all information sort correctly?
Do all dates display correctly DD-MM-YYYY?
Are the fields available appropriate to the data displaying?
Does the report display with adequate room for each column
(no overlapping test or columns running into other columns)

Is all formatting correct (bold, italics, underline)?
3.6.6 Defect Tracking Form
User Acceptance Testing DEFECT #
Application Defect Tracking Form Test case Step #:
Tester Name:
Module ID:
Date:
User Security Level tested:
APPMAN CRS_APPLICATION_MANAGER Access available to all functions
CLERK1 CRS_PROCESSING_CLERK Data Entry Functionality
CLERK2 CRS_PROCESSING_CLERK Data Entry Functionality
CLERK3 CRS_PROCESSING_CLERK Data Entry Functionality

Problem Severity (Check One):
1. System Crash (Data Loss)
2. System Crash (No Data Loss)
3. Incorrect Functionality (No Work Around)
4. Incorrect Functionality (Workaround)
5. Cosmetic

Can be Reproduced (Check One):
(E) Every Time
User Acceptance Testing DEFECT #
Application Defect Tracking Form Test case Step #:
(S) Sometimes
(O) Occasionally
(1x) Happened Once

Defect Summary Description (One sentence description of problem):

Defect Description: (please print)
Screen Print/Error Message Attached

Steps to Reproduce:

3.6.7 Defect Tracking Log
Defect # Tester Description Date Reported User
Level
Tested
Severity
(1,2,3,4,
5)
Repeated Date
Reported
to
Contractor
Status
(Open
or
Fixed)
4 Appendix B: Hardware and Network Acceptance Test Plan
In accordance to the Ministry Acceptance test plan this document outlines the procedures and
suggested tools used to test and accept delivered new systems (workstations, servers and
networks).
The purpose for the Computer Acceptance procedure is to have a standard common process
within the ministry for acceptance testing.
It must be noted here, that for large volumes of similar hardware (e.g. 2000 PCs), since it is
not feasible to pass all the hardware from individual testing, a sampling method is advised.
4.1 Acceptance procedure for New Workstations
In order to ensure new delivered workstations are comply to the required specifications and in
proper working and have not been damaged due to the effect of manufacturing defects,
shipping damage or other possible sources of infant mortality failure (early failure in the span of
a component), a Burn-in test is performed. This test is done to ensure that all major
subcomponents are operating within the devices specified parameters at the maximum rated
operating condition.

The test should include at least the following components:
4.1.1 Processor
Tests:
Execute a processor intensive operation where faults can be quantitatively measured.

Requirements to Pass: No Faults must be recorded during the duration of test.
4.1.2 Memory
Tests:
Test memory using software that requires a small OS/kernel footprint (i.e. Freedos) and
use various test algorithms/patterns. Test with all available algorithms/patterns once.

Requirements to Pass: No errors detected.

Test memory bandwidth using software that detect/measure memory bandwidth

Requirements to Pass: Expected bandwidth achieved (e.g. DDR-400 memory should
achieve 3.2GB with FSB 200MHz)
4.1.3 Video Card
Testes:
Test 2D&3D with XP based application.

Requirements to Pass: Picture should look stable on test monitor at the test duration.
4.1.4 Hard Drive
Tests:
Execute a read test. Test should be executed a minimal of one time.

Requirements to Pass: Test should report no error
4.1.5 Optical Drive
Tests:
Perform a write test (a read test is perform on write validation) on a 700MB CD-RW or DVD
RW(+or-) The test data should consist of multiple files of various sizes and should have a total
size of approx. 700MBor 4.7GB Fastest write speed that the optical drive will support should be
configured. A quick erase should be first done on the CD-RW or DVD RW Validate the files
written. Note the write and read throughput.

Requirements to Pass: Test should report no errors
4.1.6 Network Interface Card
Tests:
(Wired) Test the auto-sensing and clocking of the 10/100 and/or 1000 Mbps mode by
connecting to the Ethernet port the highest rated Ethernet speed network.

Requirements to Pass: Verify that link light on network card is lit and the OS should
report the connection at the correct Ethernet speed

(Wireless) Test the auto-sensing and clocking of the Wi-Fi interface by connecting to an
802.11a, 802.11b or 802.11g network.

Requirements to Pass: The OS should report the connection at the correct 802.11
network
4.1.7 Sound Card
Tests:
Test line in / line output via using a loop-back cable and an application that can playout and
record simultaneously. Application should compare the capture audio file to the playout for
distortion.

Requirements to Pass: Distortion should be minimal.
4.1.8 Motherboard
Tests:
For onboard audio, see tests under sound card
For onboard network, see tests under Network Interface Card
For onboard video, see tests under Video Card
P/S2 Keyboard &mouse
4.1.9 Monitor
Tests:
For all monitors, display the following solid colour test patterns (black, white, red, green, blue,
yellow, cyan and magenta). For each colour pattern, look to see if the colours of the test
pattern are uniform and that there are no dead or dark spots. For LCD monitors, look for
constantly dark or lit pixels.

Requirements to Pass: No significant uniformity in the test pattern and no more than 2 bright
or dark pixels or 4 malfunctioning sub-pixels should be seen on monitors with native
resolutions 1024x768, 3 bright or dark pixels or 4 malfunctioning sub-pixels should be seen on
monitors with native resolutions 1280x1024.
Sample Test Report for Workstation Acceptance
Workstation Brand Name:
Workstation S/N:
Test Date:
Tester:

Specification Test Results Test
Duration
S/W Tools Notes and
records
CPU
Motherboard
Keyboard&mouse
USB
Firewire
Audio
Network
Video Card
2D&3D
Memory Bandwidth :
Hard Drive
Write Test-
SMART
Optical Drive
Write / Read Test
CD

Write / Read Test
DVD

Floppy Drive
Chassis&power
supply voltage

Network Card
Sound Card
4.2 Acceptance procedure for New Servers
The following components should be tested during the acceptance test procedure In order to
ensure that the delivered servers are comply to the required specifications and in proper
working and have not been damaged due to the effect of manufacturing defects.
The test should include at least the following components
Processor:
Memory
Internal storage
CD/DVD-ROM Drive
Tape drive
Power supply
Console
External storage
RAID controller
Hot plug and redundant power supplies
4.3 Acceptance procedure for Network Devices
The aim of this procedure is to provide a thorough acceptance test procedures for the delivered
network devices to ensure that it is comply to the required specifications

The test procedure include the following devices:
4.3.1 Switches
Rechecking the IP address(es) of the switch and its default gateway
Checking that switch is appropriately labelled and named
Recording the MAC address of the switch
Checking that the SNMP is available
Checking that the VLANs are operating
Checking the 100 or 1000 Megabit uplink(s)
Verifying that the correct number of RJ45 (or RJ21) ports are delivered
Verifying QOS works
Possible checking of protocols
Possibly verifying that Multicast is functioning properly
4.3.2 Firewalls
The following specifications should be tested during the acceptance test procedure In order to
ensure that the delivered firewalls are comply to the required specifications
Security Credentials
Performance and Reliability
Manageability
Versatility
Application Proxies
Routing
4.3.3 Twisted pair cabling
Verify that the identification number (label) is identical for both the jacks in the workstation
wall plate and in the corresponding patch panel jacks to be tested.
Verify that a mechanically sound connection exists for each wire at each of the attached
terminations on an RJ-11 or RJ-45 jack.
Verify correct straight-through correspondence of all four (4) wires at each RJ-11 or RJ-45
termination of the cable.
If a single-end test device is to be used, verify the pin-to-pin continuity of each pair within
the loopback plugs to be used at the opposite end.
4.4 Recommended testing software for workstations and servers
Memtest86+ (for memory testing)
MicroProbe 2005 (for motherboard, hard drive and memory)
Speed Fan (for voltage, temperature, fan and SMART monitoring)
Nero CD-DVD Speed (for DVD+/-R testing)
CheckeMon (for test patterns during monitor testing)
IPerf (for network test)
Passmark BurnIn Test (for CPU, hard drive, video card, USB, serial, audio, firewire,
network, optical drive, floppy)
4.5 Recommended testing software for network devices and performance
Acceptance of the network devices, workstations, and servers should be followed by an overall
testing and management process to ensure that the performance of the network is up to the
needed level many software packages can be used to do that, such as:
HP OpenView
IBM Tivoli
SolarWinds