Enter Security level in

Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.

Approved: Doc. No. G002660 Ver. 0.1 1(24)

Master Test Plan

Table of contents

1 Version history....................................................................................2

2 Introduction.........................................................................................2
2.1 Purpose.................................................................................................2
2.2 Background...........................................................................................2
2.3 Scope....................................................................................................3
2.3.1 Features To Be Tested.............................................................................................. 3
2.4 Introduction...........................................................................................3
2.5 Functional Requirements......................................................................3
2.6 Non-Functional Requirements..............................................................3
2.7 Project Identification..............................................................................4

3 Requirements for Test........................................................................5

4 Test Strategy.......................................................................................6
4.1 Test phases...........................................................................................6
4.1.1 Service-component-level testing..............................................................................10
4.1.2 Service-level testing.................................................................................................10
4.1.3 System Test............................................................................................................. 10
4.1.4 Brugervenlighedtest................................................................................................. 11
4.1.5 Integration Test........................................................................................................ 11
4.1.6 Overtagelseprøve.................................................................................................... 12
4.1.7 Driftsprøve............................................................................................................... 12
4.1.8 Tillslutningstest........................................................................................................ 13
4.2 Testing Types........................................................................................6
4.3 Tools....................................................................................................13

5 Resources..........................................................................................14
5.1 Workers...............................................................................................14
5.2 Test environment................................................................................16

6 Project Milestones............................................................................16

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 2(24)

7 Deliverables.......................................................................................18
7.1 Key Performance Indicators, KPI’s.....................................................18

8 Risks...................................................................................................19

9 References.........................................................................................19

10 Appendix A: Project Tasks..................................................................20

1 Version history
Date Version Author Comments

2010-09-20 0.1 Mahmoud Passikhani First Draft

2 Introduction
2.1 Purpose

To test the Corporate Intranet Portal for Sveaskog, based on the Requirements Traceability Matrix (link
to this file) provided prior to the inception of this portal project. In this Test Plan, Sveaskog expects to
achieve the following:
 Ensure that all business requirements have been met
 Ensure that all functional requirements have been met
 Ensure that branding/graphical elements render correctly in our chosen browser
 Evaluate system performance
 Determine level of user satisfaction

The above objectives will be accomplished by using the use cases outlined in subsequent sections of
this document.

This Test Plan document the following objectives:

 Identify existing project information and the software components that should be tested
 List the recommended Requirements for Test (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

2.2 Background

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 3(24)

[Enter a brief description of the target-of-test (component(s), application, system, etc.) and its goals.
Include information such as major function(s) / features, architecture and a brief history of the project.
This section should only be about 3 - 5 paragraphs.]

2.3 Scope


2.3.1 Features To Be Tested

2.4 Introduction
[This section identifies how the test items should behave. This is defined in Use Cases, Requirement
Specification and/or Functional Specifications.

Identify all software features and combinations of software features to be tested. Identify the test design
specification associated with each feature and each combination of features. Identify the types of tests
that will be performed for each test target, if many.]

2.5 Functional Requirements

[Example:

For each component/application or system, Use Cases will be created. The

components/applications/systems will be tested according to the functional requirements in
respective Use Case during the System Test phases.

See ref [X] for Use Cases.]

2.6 Non-Functional Requirements

[For information regarding non-functional tests, see http://www.testingstandards.co.uk/. Read more
about measuring quality characteristics of software in ISO 9126 “Quality characteristics” standard.]

[Example:

The Supplementary Specifications for each component/application/system will include all non-
functional requirements and the functional requirements that do not apply to Use Cases.

There are test cases that will be addressed during System Test of non-functional
characteristics which do not apply to any requirement in Use Cases or Supplementary
Specifications. The reason for their existence is that there is an obvious need for the test in
order to monitor that the system does not regress in any aspect.

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 4(24)

Following attributes of the complete system will be tested during System test.

 Performance

 Stress

 Reliability

 Security]

[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, functions that will / will not be tested]
[List any assumptions made during the development of this document, that may impact the design,
development or implementation of testing]
[List any risks or contingencies that may affect the design, development or implementation of testing]
[List any constraints affect the design, development, or implementation of testing]

2.7 Project Identification

The table below identifies the documentation and availability, used for developing the test plan
Document Created or Received or Author or Notes
(and version / Available Reviewed Resource
date)
Requirements  Yes  No  Yes  No
Specification
Functional  Yes  No  Yes  No
Specification
Use Case  Yes  No  Yes  No
Reports
Project Plan  Yes  No  Yes  No
Design  Yes  No  Yes  No
Specifications
Prototype  Yes  No  Yes  No
Users Manuals  Yes  No  Yes  No
Business Model  Yes  No  Yes  No
/ Flow
Data Model /  Yes  No  Yes  No
Flow
Business  Yes  No  Yes  No

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 5(24)

Functions and
Rules
Project /  Yes  No  Yes  No
Business Risk
Assessment

3 Requirements for Test

The listing below identifies those components that have been identified as targets for testing. Test cases
will be developed based on use cases, functional requirements and non-functional requirements
associated till every component.
 Kommuneservice web service
 Virksomhedsservice web service
 Virksomhedsdialog
 Virksomhedsadministrationsdialog
 Kommuneadministrationsdialog
 Ekstern kommunikation
 Revisionsspor
 Virksomhedsservice (VS)
 Kommuneservice (KS)
 Indberetninger og tilstandsstyring
 Virksomhedsstamdata
 Venteregister
 Hændelser
 Regler, frister og notifikationer
 Underretningsbreve (UDP)
 Revisionssporbrowser
 Logvisningsværktøj
 Tilgængelighed af eksterne systemer
 Brugsstatistik
 Forandringsbarhed
 Service bus
 Simulatorer (Reducerad eller ikke reducerad)
o Kommunesystem
o Virksomhedssystem

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 6(24)

o Sveaskog
 Integration mod eksterne systemer

4 Test Strategy
The Test Strategy presents the recommended approach to the testing the Sveaskog. The previous
section, Requirements for Test, described what will be tested, this section describes how the Sveaskog
will be tested.
The main considerations for the test strategy are the techniques to be used and the criterion for knowing
when the testing is completed.
In addition to the considerations provided for each test below, testing should only be executed using
known, controlled databases, in secured environments. Test data ska vara anonymiserade.

4.1 Testing Types

Testing Types Short Description Results

Requirements testing

Functional and GUI testing

Usability testing

Integration testing

Migration testing

Security testing

Code review

Automated testing

Performance testing

Cybercom offers SharePoint quality assurance services which are very essential and at the same
time the most overlooked aspects of SharePoint implementation process.

Testing types Short description  Results

Requirements A requirement testing is a method for Verification of requirements

testing detection of logical errors in project compliance with SharePoint
documentation at an early stage, before the restrictions and finding logical
actual development starts. problems in product
requirement at an early stage

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 7(24)

The main purposes of the testing are:

1. Standard: detection of mismatches
in expectations and interpretations allows to:
of the product requirements as well  Get recommendations for
as  cyclic  Improvement of the improving flexibility and
requirements quality (correctness, convenience of the
completeness and adequacy, system.
unambiguity, consistency)
 Improve the quality of the
2. Specific for SharePoint:  future product.
requirements analysis and review
taking into account the peculiarities  Lower the development
of the architecture, configuration and testing costs and  
and structure of SharePoint (for ex. reduce product time of
the usage of standard SharePoint delivery by minimizing
Search, validation, special symbols, expensive rework in case
etc.). As a result QA suggests some of requirements-related
enhancements to increase the defects.
flexibility and configurability of the
system.

Functional Functional and GUI testing of SharePoint Testing allows to:

and GUI based applications consists of the following
testing main parts:
1.  Detection of functional and GUI
defects (testing against business
requirements, sketches, mock-ups
and other project documentation) as
well as finding configuration errors
(for ex., unacceptable quality of the
functionality can be forced not by
problems in code but incorrect
system configuration)
2. Detailed GUI testing to ensure that
the application looks professional,
and is implemented in the uniform
style. It is not so critical for
standard SharePoint objects but
very important for number of
custom grids, forms (search,
 Identify the functional
and GUI defects and
improve product quality
quickly and in time.
 Make appropriate
enhancements and
change requests to the
default configuration and
Administrative Guide. It
helps to avoid  blocking
of the system if the
deployment takes place
on the customer’s side.
 Find workarounds for
some configuration errors
by QA engineers. If it is
possible, QA Engineers
are able to reduce delays

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 8(24)

workflow), navigation trees, and

different branding schemes.
3. Administrative Guide testing. It is
installation process testing in
accordance with the Guide the
system is deployed with. A QA in functional testing and
engineer checks if there is enough reporting without waiting
information to configure the system till a new version of a
properly and  whether the system solution to be delivered.
works correctly under default
configuration. This testing type is
very important in case the system is
to be deployed in geographically-
distributed organization because the
Customer will need to install and
reinstall the system several times.

Usability testing verifies that the

application appeals to the target
audience and meets the customer’s
requirements alongside with the non-
documented requirements and
enhancements which are bound by
usability rules and standards. It is a
method of finding logical and structural
errors.
Usability testing has the following  As a result, QA provides
objectives: recommendation for improving the
Usability usability characteristics of the
testing  Determine if the project allows product to increase the usability
users to easily and efficiently level and ensure that the project
accomplish their tasks meets end users expectations.
 Uncover user difficulties and
frustrations associated with the
site
 Collect significant usability
findings (including positive and
negative findings) with the
purpose of improving usability of
the product

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 9(24)

Performing this test is reasonable and

necessary in case of testing deep
customized applications based on
SharePoint.

QA performs testing of integration between

SharePoint and outer systems:

 Verification of integration with The test results show if

customer external systems, MS integration is able to provide
Integration Office integrated systems (custom smooth interaction of integrated
testing plug-in, add-in and etc.) and etc. systems taking into account
various systems’ constraints
 Verification of the systems which
and peculiarities.
are integrated to SharePoint as
separate modules or web-parts (for
example, Brava! Enterprise,
payment systems).

There can be different goals of

migration testing which depends on the Testing allows to:
migration type:
 Identify defects found
1. Verifying that the projects during migration process.
migration is successful As a result, it reduces the
number of errors and
Migration 2. Checking the process of mistakes during real
testing Projects migration testing from migration.
custom DMS to SharePoint
products   Increase the quality of the
Custom Migration Tool (as
3. Testing of the developed a result of testing migration
Custom Migration Tools to errors handling, GUI issues,
ensure that it can support the etc.)
migration process

Security During security testing of the QA: The customer gets information
testing about the quality of a system in real
1. Checks different configurations of life conditions when users with
Standard SharePoint groups and different rights interact with the
their rights system:

2. Tests functionality under custom

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 10(24)

 Whether Security Policy is

carried out (all users can go
through their business
process and limited users
are restricted from doing
groups  and permissions
some actions, etc.)
3. Check internal (intranet) and
 If a system can be accessed
external (external site) access points
from the outside
to SharePoint based application.
(authentication, correct
pages redirection, etc.
testing) and external users
can operate with
functionality.

QA validates that code is written in

accordance with technical
Testing of code against technical
Code review requirements (source code has
specifications/requirements.
uniform structure, necessary
comments, etc.).

 Automated testing includes the

development of automated scripts mostly  Reduces manual testing
based on predefined functional test cases. efforts for re-testing stable
functionality (regression
Automated scripts are used for the testing)
following objectives:
 Allows more frequent build
delivery and minimal QA of
 Frequent or time-consuming
Automated these builds
functional test case generation
testing
 Reduces efforts on multi-
 Hard-to-reproduce scenario platform and multi-
generation browsers testing
 Data generation  Minimizes routine testing
 Iterative mechanisms check operations and replace them
with automated test.
 Regressions detection.

Performance tests determine end-to-end As a result, the Customer gets

Performance timing (benchmarking) of various time- information how well the software
testing critical business processes and transactions performs under normal, unusual,
under low load but with a production-size and abnormal circumstances,

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 11(24)

database.
Load tests are end-to-end performance tests
establishing the maximum load,
under the anticipated production load,
traffic, data, and other parameters
which determine response time for various
the system can handle.
time-critical transactions and business
processes.

Different testing types will be performed during each test phases:

 Data and Database Integrity Testing
 Functional testing
 Business Cycle Testing
 User Interface Testing
 Performance Profiling
 Load Testing
 Stress Testing
 Volume Testing
 Security and Access Control Testing
o Test af datasikkerhed
o Test af adgang til databasen, og at data er sikrede
o Test af datalovens krav til logning
o Inventoryscanning
o Applicationtest
o Stabilitetstest
o Portscanning
o Sårbarhedstest
o Denial of service attack
o Review af Firewall
o Kontrol af krypteringen af cache
o Sikkerhed i brugergrænsefladen
o scanning efter sårbarheder, fx manglende patches, konfigurationsfejl og lign
o Penetrationstest, hvor Systemet forsøges misbrugt
o Logon procedure, rettigheter og sikerhetsprofiler

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 12(24)

Each test type is described in detail in Appendix V – Test Types.

4.2 Test phases

Testing of the Sveaskogs solution will be organized in the following phases:

 Intern Funktionstest – testen består av tre olika delar:

a) Service-component-level testing

b) Service-level testing

c) System test

 Brugervenlighedtest

 Integration testing

 Overtagelseprøve

a) Process workflow/Orchestration testing

b) Security testing

 Driftsprøve

4.2.1 Service-component-level testing

Prerequisites:
-
Requirements to be tested:
 All functional requirements listed in Iteration Plan
Test Types to be used:
 White box testing to cover all logical paths.
 Black box testing to cover all the functionality
 XHTML validation
 Code review
Test environment:
 Developing environment
Other:
 Developers are responsible for writing the test scripts in accordance to Test Driven
Development, TDD.

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 13(24)

4.2.2 Service-level testing

Prerequisites:
 Service-component-level testing has been completed
Requirements to be tested:
 All functional requirements listed in Iteration Plan
Test Types to be used:
 Black box testing to cover all the functionality
Test environment:
 Developing environment for each project
Other:
 Developer team is responsible for Service-level testing.

4.2.3 System Test

Prerequisites:
 Service-component-level and Service-level testing has been completed
 Smoke test has been performed immediately after installation to internal test environment.
Requirements to be tested:
 All functional requirements
Test Types to be used:
 Regression test (Function Testing) of all functionality
 Function Testing of Web Services
 Belastningstest test
 Skalerbarhedstest
 Performance profiling
 Document verification
Test environment:
 Internal test environment
Other:

4.2.4 Brugervenlighedtest

Der er tre iterationer af prototype; pilot-papirprototype og papirprototype, klikbar prototype (hvis denne
option vælges) og kørende prototype.
Prerequisites:
 At projektet har leveret de nødvendige informationer for at bygge prototyper

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 14(24)

Requirements to be tested:
 Alle kravene vedrørende brugervenlighed vil blive berørt.
Test Types to be used:
Test environment:
 Papir- og klikbar prototype vil køre lokalt.
 Kørende prototype vil køre i Cybercoms Brugervenlighedtest.
Other:

4.2.5 Integration Test

Prerequisites:
 System Testing has been completed
 Smoke test has been performed immediately after installation to the integration test environment
Requirements to be tested:
 Integrationstesten testar bara kommunikationen mellan systemen och meddelandets innehåll.
Den testar inte lösningens forretningsfunktionalitet eller kvalitetsmässiga egenskaper såsom
svarstid, oppetid, sikkerhed, brugervenlighed, etc. Dessa tester genomförs i andra faser.
Test Types to be used:
 Integration Test
Test environment:
 Integration test environment

4.2.6 Overtagelseprøve

Prerequisites:
 Integration Test has been completed
 Smoke test has been performed immediately after installation to pre-production environment
 An extensive Regression test has been completed
Requirements to be tested:
 All functional and non-functional requirements
Test Types to be used:
 Data and Database Integrity Testing
 Function testing
 Business Cycle Testing
 User Interface Testing
 Performance Profiling

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 15(24)

 Scalability testing
 Load Testing
 Stress Testing
 Volume Testing
 Security and Access Control Testing
Test environment:
 Pre-production Test Environment. Kunden ska möjlighet att använda riktige Virksamheds- og
Kommunesystemer under testen.

4.2.7 Driftsprøve

Prerequisites:
 Overtagelseprøve has been completed
 Smoke test has been performed immediately after installation to OTP Test Environment
Requirements to be tested:
 ?
Test Types to be used:
 Installation / Upgrade Test performed by Hosting
 Will be defined by Customer
Test environment:
 OTP Test Environment

4.2.8 Tillslutningstest

Tillslutningsprøve – är en del av drift- och vedligheoldkontraktet. Se kapitel 49 för mer information om

testen.

4.3 Tools
The following tools will be employed for this project:
Name Description Used for Company
Microsoft In house Test Microsoft
Excel framework based monitoring
on Microsoft
Excel for
monitoring and
control of test
process and
activities.
Mantis Web-based bug Bug http://www.mantisbt.org/
tracking system. tracking

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 16(24)

Supports internal
Defect
Management
Process
MbUnit Unit-testing Component http://www.mbunit.com/
integrated with framework for Tests
Microsoft all .NET
Visual Studio languages. Test
cases will be
developed first
before developing
the production
code. These test
cases will be
executed directly
after each built.
Rehino Mock
Cruise- Control
WebAii http://www.artoftest.com/ - Företagets startsida
http://www.artoftest.com/webaiifxproduct.aspx –
Produktens hemsida.
WAST Web Application Mätning av http://www.microsoft.com
Stress Tool systempres
tanda, t.ex.
processor
tid och
minnesåtgå
ng, samt
svarstider
tillsammans
med de
automatisk
a testerna
Test Complete Test case Automated http://www.automatedqa.com/products/testcompl
Recording and Functional ete/
Playback and test test
Execution of
Automated
automated test
Regression
suit
test
Automated
Smoke test
SOAP UI A desktop Functional, http://www.soapui.org/
application for Load and
inspecting, Compliance
invoking and testing
developing Web

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 17(24)

Services over
HTTP. Open
Source
PushToTest Open source Scalability, http://www.pushtotest.com/
TESTMAKER utility and functionality
framework to and
build and use performanc
intelligent test e
agents to check
webenabled
applications as a
real world.

5 Resources
This section presents the recommended resources for the test effort, their main responsibilities, and
their knowledge or skill set.

5.1 Workers
This table shows the staffing assumptions for the project.
Human Resources
Worker Minimum Resources Specific Responsibilities/Comments
Recommended
(number of workers
allocated full-time)

Test Manager / Test 1 (100%) Provides management oversight

Project Manager
Responsibilities:
Provide technical direction
Acquire appropriate resources
Management reporting
Test Designer 3 (100%) Identifies, prioritizes, and implements
test cases
Responsibilities:
Generate test plan
Generate test model
Evaluate effectiveness of test effort

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 18(24)

Tester 3 (100% during test Executes the tests

period)
Responsibilities:
Execute tests
Log results
Recover from errors
Document change requests

Test System 1 (25%) Ensures test environment and assets

Administrator are managed and maintained.
Responsibilities:
Administer test management system
Install / manage worker access to test
systems
Database 1 (25%) Ensures test data (database)
Administration / environment and assets are
Database Manager managed and maintained.
Responsibilities:
Administer test data (database)
Test Designer Will be incorporated in Identifies and defines the operations,
(automated test cases) developer team attributes, and associations of the
test classes
Developer
Responsibilities:
Identifies and defines the test
class(es)
Identifies and defines the test
packages
Implementer Will be incorporated in Implements and unit tests the test
developer team classes and test packages
Developer
Responsibilities:
Creates the test classes and
packages implemented in the test
model.

5.2 Test environment

The following table sets forth the system resources for the testing project. The specific elements of the
test system are not fully known at this time. It is recommended that the system simulate the production
environment, scaling down the accesses and database sizes if / where appropriate.
System Resources
Resource Name / Type

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 19(24)

Database Server
—Network/Subnet TBD
—Server Name TBD
—Database Name TBD
Database Server
—Network/Subnet TBD
—Server Name TBD
—Database Name TBD
Client Test PC's
—Include special configuration TBD
—requirements
Test Repository
—Network/Subnet TBD
—Server Name TBD
Test Development PC's TBD

6 User Acceptance Test

6.1 Schedules for UAT
The following schedule outlines testing roles, timelines, and dates for User Acceptance Test, UAT. Each
group is responsible for adhering to the following schedule and expectations are such that each segment
detailed will be completed within the scheduled timeframe.
User Role Dates Timeframe

Administrators

Content Stewards

End User

6.2 Responsibilities
6.2.1 Administrators
Portal Owners, manage security, content, design, maintenance, etc. Also user and navigators of the site

6.2.2 Content Stewards

People how will administrate sites at the department level, also users and navigators of the site.

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 20(24)

6.2.3 Users
People, who will read, navigate and/or contribute content to the portal.

6.3 Test Cases

User Role Test Description Test Steps Expected Result Actual Result
(Intention) (System
Response)

Administrators Create New Sub-Site 1. Detailed first step Document expected Tester document
results here results here
2. Detailed second
step

3. …and so on.

Content Stewards Add user to a permission 1. Detailed first step Document expected Tester document
group results here results here
2. Detailed second
step

3. …and so on.

End User Upload a document to a

document library

7 Project Milestones
Testing of Sveaskog should incorporate test activities for each of the test efforts identified in the previous
sections. Separate project milestones should be identified to communicate project status and
accomplishments. Test activates on
 project level are described in detail in Appendix II – Test Process. Test Activities
 test phase level are described in Appendix IV – Test Phases

Milestone Task Effort Start Date End

Date
Plan Test
Design Test
Implement Test
Execute Test
Evaluate Test

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 21(24)

8 Deliverables
Life Cycle processes Deliverables
Test Planning and Control Test plan, Test Strategy
Test Specification Requirements Traceability documents
Test Implementation and Execution Test cases, Test scripts, test data and test logs.
Evaluation exit criteria and reporting Status Reports/Metrics and Defect summary
Report
Test closure activities Post-mortem document

8.1 Key Performance Indicators, KPI’s

Test manager is responsible for collecting the following metrics:
 Test case development progress
o Number of test cases developed per week, both in actual figures and an average in the
development weeks.
o Number of test cases cancelled after review.
o Average number of test steps per test case.
 Test case execution progress
o Number of test cases executed per week, both in actual figures and an average in the
execution weeks.
o Number of test cases per state, i.e. Passed, Failed, Blocked.
 Defect status
o Number of defects reported per week, both in actual figures and an average in the
execution weeks.
o Number of defects per state and severity.
o Number of defects found during test phase.

9 Assumptions and Risks

9.1 Assumptions and Risks
 The UAT environment will be available and desktops will be available to perform
testing.
 The Business team has reviewed and accepted functionality identified in the business
requirements and software requirements documents.
 Code walkthroughs/reviews will be completed by the development team.
 Unit testing will be completed by the development team prior to release to the test team.
 Testers will test what is documented in the requirements.
 All changes to requirements will be communicated to the test team.
 Resources identified in this plan are available to test the application and resolve defects
and address issues as they are raised by the test team.

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 22(24)

 That the delivery of the product to production contains all setup, etc., that is necessary
for optimum performance in the production site.
9.2 Risks
Identify and list the high-risk assumptions of the test plan. Specify contingency plans for each (e.g.,
delayed delivery of test items might require increased night shift scheduling to meet the delivery date).
Identify mitigation and contingency strategies for each risk. Also indicate a relative ranking for both the
likelihood of occurrence and the impact if the risk is realized. See the risk list in the in ref Project Plan for
Sveaskog which includes all risks for the project.
Description of Risk Mitigation Impact if the Risk Exposure
Strategy risk is realized (Likelihood*
Consequence)
There is a risk that Test and measure It will not be 6 (2*3)
the target devices regularly. possible to perform
are not good all planned tests.
enough for test.

10 References
Ref Document Title Rev.
1 G002659 Quality Plan
2 Appendix II Test Process
3 The solution chapter Test Strategy
3 Appendix III Test environment
4 Appendix IV Test Phases
5 Appendix V Test Types
6 Appendix VI Defect management Process

11 Appendix A: Project Tasks

Below are the test related tasks:
Plan Test
Identify Requirements for Test
Assess Risk
Develop Test Strategy
Identify Test Resources
Create Schedule
Generate Test Plan
Design Test
Workload Analysis

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 23(24)

Identify and Describe Test Cases

Identify and Structure Test Procedures
Review and Access Test Coverage
Implement Test
Record or Program Test Scripts
Identify Test-Specific functionality in the design and implementation model
Establish External Data sets
Execute Test
Execute Test Procedures
Evaluate Execution of Test
Recover from Halted Test
Verify the results
Investigate Unexpected Results
Log Defects
Evaluate Test
Evaluate Test-Case Coverage
Evaluate Code Coverage
Analyze Defects
Determine if Test Completion Criteria and Success Criteria have been achieved

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk
 Enter Security level in
Prepared: Mahmoud Passikhani Date: 2009-03-24 Properties/Custom 'Security' Page no.
Approved: Doc. No. G002660 Ver. 0.1 24(24)

Cyber Com Consulting A/S Telefon 70 42 42 70

Vesterbrogade 149, bygning 4 Telefax 70 42 42 72
1620 København V www.cybercomgroup.dk