Professional Documents
Culture Documents
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
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
7 Deliverables.......................................................................................18
7.1 Key Performance Indicators, KPI’s.....................................................18
8 Risks...................................................................................................19
9 References.........................................................................................19
1 Version history
Date Version Author Comments
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.
2.2 Background
[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.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.]
[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.
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]
Functions and
Rules
Project / Yes No Yes No
Business Risk
Assessment
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.
Requirements 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.
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:
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.
a) Service-component-level testing
b) Service-level testing
c) System test
Brugervenlighedtest
Integration testing
Overtagelseprøve
b) Security testing
Driftsprøve
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.
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.
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:
Papir- og klikbar prototype vil køre lokalt.
Kørende prototype vil køre i Cybercoms Brugervenlighedtest.
Other:
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
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
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
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
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)
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
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.3 Users
People, who will read, navigate and/or contribute content to the portal.
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.
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
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
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