Prepared: Mahmoud Passikhani Date: 2009-03-24Enter Security level in 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........................................................................................22.1 Purpose...............................................................................................22.2 Background..........................................................................................22.3 Scope...................................................................................................32.3.1 Features To Be Tested..............................................................................................32.4 Introduction..........................................................................................32.5 Functional Requirements.....................................................................32.6 Non-Functional Requirements.............................................................32.7 Project Identification.............................................................................4

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

4 Test Strategy......................................................................................64.1 Test phases.........................................................................................64.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........................................................................................................134.2 Testing Types......................................................................................64.3 Tools..................................................................................................13

5 Resources........................................................................................145.1 Workers.............................................................................................145.2 Test environment...............................................................................16

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

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

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

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

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

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

1 Version historyDate 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 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

Prepared: Mahmoud Passikhani Date: 2009-03-24Enter Security level in 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 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

Prepared: Mahmoud Passikhani Date: 2009-03-24Enter Security level in 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 (and version / date)

Created or Available

Received or Reviewed

Author or Resource

Notes

Requirements Specification

Yes No Yes No

Functional Specification

Yes No Yes No

Use Case Reports

Yes No Yes No

Project Plan Yes No Yes No

Design Specifications

Yes No Yes No

Prototype Yes No Yes No

Users Manuals Yes No Yes No

Business Model / Flow

Yes No Yes No

Data Model / Flow

Yes No Yes No

Business Yes No Yes No

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

Functions and Rules

Project / Business Risk Assessment

Yes No Yes No

3 Requirements for TestThe 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

o Sveaskog

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

Integration mod eksterne systemer

4 Test StrategyThe 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 TypesTesting 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 testing

A requirement testing is a method for detection of logical errors in project documentation at an early stage, before the actual development starts.

The main purposes of the testing are:

Verification of requirements compliance with SharePoint restrictions and finding logical problems in product requirement at an early stage allows to:

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

1. Standard: detection of mismatches in expectations and interpretations of the product requirements as well as  cyclic  Improvement of the requirements quality (correctness, completeness and adequacy, unambiguity, consistency)

2. Specific for SharePoint:  requirements analysis and review taking into account the peculiarities of the architecture, configuration and structure of SharePoint (for ex. the usage of standard SharePoint Search, validation, special symbols, etc.). As a result QA suggests some enhancements to increase the flexibility and configurability of the system.

Get recommendations for improving flexibility and convenience of the system.

Improve the quality of the future product.

Lower the development and testing costs and   reduce product time of delivery by minimizing expensive rework in case of requirements-related defects.

Functional and GUI testing

Functional and GUI testing of SharePoint based applications consists of the following 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, workflow), navigation trees, and different branding schemes.

Testing allows to:

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 in

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

3. Administrative Guide testing. It is installation process testing in accordance with the Guide the system is deployed with. A QA engineer checks if there is enough information to configure the system properly and  whether the system 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.

functional testing and reporting without waiting till a new version of a solution to be delivered.

Usability testing

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 objectives:

Determine if the project allows users to easily and efficiently accomplish their tasks

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

Performing this test is reasonable and necessary in case of testing deep

 As a result, QA provides recommendation for improving the usability characteristics of the product to increase the usability level and ensure that the project meets end users expectations.

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

customized applications based on SharePoint.

Integration testing

QA performs testing of integration between SharePoint and outer systems:

Verification of integration with customer external systems, MS Office integrated systems (custom plug-in, add-in and etc.) and etc.

Verification of the systems which are integrated to SharePoint as separate modules or web-parts (for example, Brava! Enterprise, payment systems).

The test results show if integration is able to provide smooth interaction of integrated systems taking into account various systems’ constraints and peculiarities.

Migration testing

There can be different goals of migration testing which depends on the migration type:

1. Verifying that the projects migration is successful

2. Checking the process of Projects migration testing from custom DMS to SharePoint products 

3. Testing of the developed Custom Migration Tools to ensure that it can support the migration process

Testing allows to:

Identify defects found during migration process. As a result, it reduces the number of errors and mistakes during real migration.

Increase the quality of the Custom Migration Tool (as a result of testing migration errors handling, GUI issues, etc.)

Security testing

During security testing of the QA:

1. Checks different configurations of Standard SharePoint groups and their rights

2. Tests functionality under custom groups  and permissions

The customer gets information about the quality of a system in real life conditions when users with different rights interact with the system:

Whether Security Policy is carried out (all users can go

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

3. Check internal (intranet) and external (external site) access points to SharePoint based application.

through their business process and limited users are restricted from doing some actions, etc.)

If a system can be accessed from the outside (authentication, correct pages redirection, etc. testing) and external users can operate with functionality.

Code review Testing of code against technical specifications/requirements.

QA validates that code is written in accordance with technical requirements (source code has uniform structure, necessary comments, etc.).

Automated testing

 Automated testing includes the development of automated scripts mostly based on predefined functional test cases.

Automated scripts are used for the following objectives:

Frequent or time-consuming functional test case generation

Hard-to-reproduce scenario generation

Data generation

Iterative mechanisms check

Regressions detection.

Reduces manual testing efforts for re-testing stable functionality (regression testing)

Allows more frequent build delivery and minimal QA of these builds

Reduces efforts on multi-platform and multi-browsers testing

Minimizes routine testing operations and replace them with automated test.

Performance testing

Performance tests determine end-to-end timing (benchmarking) of various time-critical business processes and transactions under low load but with a production-size database.Load tests are end-to-end performance tests

As a result, the Customer gets information how well the software performs under normal, unusual, and abnormal circumstances, establishing the maximum load, traffic, data, and other parameters

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

under the anticipated production load, which determine response time for various time-critical transactions and business processes.

the system can handle.

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

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

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

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.

4.2.2 Service-level testing

Prerequisites:

Service-component-level testing has been completed

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

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

Requirements to be tested:

Alle kravene vedrørende brugervenlighed vil blive berørt.

Test Types to be used:

Test environment:

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

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

Scalability testing

Load Testing

Stress Testing

Volume Testing

Security and Access Control Testing

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

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 Excel

In house framework based on Microsoft Excel for monitoring and control of test process and activities.

Test monitoring

Microsoft

Mantis Web-based bug tracking system. Supports internal Defect Management Process

Bug tracking

http://www.mantisbt.org/

MbUnit integrated with Microsoft Visual Studio

Unit-testing framework for all .NET languages. Test

Component Tests

http://www.mbunit.com/

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

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 Stress Tool

Mätning av systemprestanda, t.ex. processor tid och minnesåtgång, samt svarstider tillsammans med de automatiska testerna

http://www.microsoft.com

Test Complete Test case Recording and Playback and test Execution of automated test suit

Automated Functional test

Automated Regression test

Automated Smoke test

http://www.automatedqa.com/products/testcomplete/

SOAP UI A desktop application for inspecting, invoking and developing Web Services over HTTP. Open Source

Functional, Load and Compliance testing

http://www.soapui.org/

PushToTest TESTMAKER

Open source utility and framework to build and use intelligent test

Scalability, functionality and performance

http://www.pushtotest.com/

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

agents to check webenabled applications as a real world.

5 ResourcesThis 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 Recommended

(number of workers allocated full-time)

Specific Responsibilities/Comments

Test Manager / Test Project Manager

1 (100%) Provides management oversight

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

Tester 3 (100% during test period)

Executes the tests

Responsibilities:

Execute tests

Log results

Recover from errors

Document change requests

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

Test System Administrator

1 (25%) Ensures test environment and assets are managed and maintained.

Responsibilities:

Administer test management system

Install / manage worker access to test systems

Database Administration / Database Manager

1 (25%) Ensures test data (database) environment and assets are managed and maintained.

Responsibilities:

Administer test data (database)

Test Designer (automated test cases)

Developer

Will be incorporated in developer team

Identifies and defines the operations, attributes, and associations of the test classes

Responsibilities:

Identifies and defines the test class(es)

Identifies and defines the test packages

Implementer

Developer

Will be incorporated in developer team

Implements and unit tests the test classes and test packages

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

Database Server

—Network/Subnet TBD

—Server Name TBD

—Database Name TBD

Database Server

—Network/Subnet TBD

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

—Server Name TBD

—Database Name TBD

Client Test PC's

—Include special configuration—requirements

TBD

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.

6.2.3 Users

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

6.3 Test CasesUser Role Test Description

(Intention)Test Steps Expected Result Actual Result

(System Response)

Administrators Create New Sub-Site 1. Detailed first step Document expected Tester document

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

2. Detailed second step

3. …and so on.

results here results here

…

Content Stewards Add user to a permission group

1. Detailed first step

2. Detailed second step

3. …and so on.

Document expected results here

Tester document results here

…

End User Upload a document to a document library

…

7 Project MilestonesTesting 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

8 DeliverablesLife 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.

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

Evaluation exit criteria and reporting Status Reports/Metrics and Defect summary Report

Test closure activities Post-mortem document

8.1 Key Performance Indicators, KPI’sTest manager is responsible for collecting the following metrics:

Test case development progresso 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 progresso 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 statuso 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.

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

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

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 MitigationStrategy

Impact if therisk is realized

Risk Exposure(Likelihood*Consequence)

There is a risk that the target devices are not good enough for test.

Test and measure regularly.

It will not be possible to perform all planned tests.

6 (2*3)

10 ReferencesRef 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 TasksBelow 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

Identify and Describe Test Cases

Identify and Structure Test Procedures

Review and Access Test Coverage

Implement Test

Record or Program Test Scripts

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

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 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk

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

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

Cyber Com Consulting A/S Telefon 70 42 42 70Vesterbrogade 149, bygning 4 Telefax 70 42 42 721620 København V www.cybercomgroup.dk