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