Web STP Template

©2008 Doron Bar.
All Rights Reserved
Web STP Template
Version: 1.0 Production Date:
© 2008 Doron Bar All Rights Reserved – Document can be used freely only without
changing this footer!!!
©2008 Doron Bar. All Rights Reserved
Change Control Information:
Version Name Scope of changes Date

0.1
Approval Path:
Name Function Date Signature
Table of Content:
1. Scope........................................................................................................ ....5
1.1. General ..............................................................................................................5
1.1.1. Identification..............................................................................................5
1.1.2. System Overview.......................................................................................5
1.1.3. Document Overview..................................................................................5
1.1.4. Relationship to other plans .........................................................................5
1.2. Terminology.......................................................................................................6
1.2.1. The client terminology................................................................................6
1.2.2. Terminology................................................................................................6
1.3. Testing Methodology..........................................................................................6
1.3.1. Risk Analysis: .............................................................................................6
1.3.2. Test Planning ..............................................................................................6
1.3.3. Test Design .................................................................................................6
1.3.4. Test Execution ............................................................................................6
1.3.5. Requirements Reassessment ......................................................................7
2. Referenced Documents ........................................................................ .......7
3. Testing Strategy ................................................................... .......................7
3.1. The Tested System..............................................................................................7
3.1.1. System Components to be tested................................................................7
3.1.2. System components not to be tested..........................................................9
3.1.3. Current Status.............................................................................................9
3.1.4. Other points to mention-TBA.....................................................................9
Tests Categorizations..............................................................................................10
3.1.5. Test Levels................................................................................................10
3.1.6. Test Classes..............................................................................................10
3.1.7. Problems Severity Levels ........................................................................10
3.1.8. Test Criterion ...........................................................................................11
3.2. Testing Stages...................................................................................................12
3.2.1. Risk Analysis.............................................................................................12
3.2.2. Test Planning.............................................................................................12
3.2.3. Test Design................................................................................................12
3.2.4. Test Execution...........................................................................................12
3.2.5. Requirements Reassessment.....................................................................12
3.3. Coverage & Traceability .................................................................................12
3.4. Deliverables......................................................................................................13
3.4.1. STP Document..........................................................................................13
3.4.2. TRD Document........................................................................................13
3.4.3. STR Document.........................................................................................13
3.4.4. Other Documents......................................................................................13
3.5. Software Test Environment..............................................................................13
3.6. Responsibilities................................................................................................14
14
4. System Breakdown and Test Identification.............................................15
4.1. Display..............................................................................................................15
4.1.1. Functionality..............................................................................................15
4.1.1.3.1 Athoc toolbar........................................................................................15
4.1.1.3.2 Yahoo companion.................................................................................15
4.1.1.3.3 Real player............................................................................................15
4.1.1.3.4 Macromedia Flash................................................................................15
4.1.2. Performance..............................................................................................15
4.1.3. Compatibility.............................................................................................15
4.2 Server.................................................................................................................16
4.2.3 Functionality...............................................................................................16
4.2.4 Performance...............................................................................................16
4.2.5 Security.......................................................................................................16
4.2.5.1 Registration............................................................................................16
4.2.5.2 Passwords and logins.............................................................................16
4.2.5.3 User’s identification...............................................................................16
4.2.5.4 Hucker’s intrusion..................................................................................16
4.2.6 Usability.....................................................................................................17
4.3 Client.................................................................................................................17
4.3.3 Functionality...............................................................................................17
4.3.1.1.1 Athoc toolbar........................................................................................17
4.3.1.1.2 Yahoo companion.................................................................................17
4.3.1.1.3 Real player............................................................................................17
4.3.1.1.4 Macromedia Flash................................................................................17
4.3.4 Performance...............................................................................................17
4.3.5 Security.......................................................................................................17
4.3.2 Registration................................................................................................17
4.3.3 Passwords and logins.................................................................................17
4.3.4 User’s identification...................................................................................17
4.3.5 Hacker’s intrusion detecti...........................................................................17
4.3.6 Compatibility..............................................................................................17
5 Data Records and Analysis............................................... .........................19
6 Risks................................................................................... .........................19
7 Testing Schedule.............................................................. ...........................21
Appendix A - Coverage Report........................................................... .........22
Appendix B – Testing Environments............................................... ............23
1. Scope
1.1. General
1.1.1. Identification
<Product> is a new and revolutionary inter-page media product for web promotional
activity. Inovend is currently patent-pending.
1.1.2. System Overview

<Product> offers a new way for web publishers to transfer media to end-users. Rich
media transfers to the user’s computer screen without affecting the browsing
experience. While a web page downloads, a brief impression appears, and then
disappears when the target web page starts to appear on the end-user’s monitor. The
end-user and publisher can control various parameters, based on defined user
preferences and the web publisher’s chosen campaign.
Web publishers can apply <Product> to display different types of images and
animation on their user’s screens without taking up any precious desktop real estate.
Inter-page content does not affect the download rate, since the content resides on the
local machine.
1.1.3. Document Overview

This document describes the design interface between the client and the server of
<Product>
1.1.4.Relationship to other plans
1.2. Terminology
1.2.1.The client terminology
CSI -Client Server Interface
1.2.2.Terminology
SDD - Software Development Document (also called TLD)
STD - Software Test Description
STP - Software Test Plan
STR - Software Test Report
TC - Test Case
1.3. Testing Methodology

The Web testing methodology has the following stages:
1.3.1.Risk Analysis:
Identifies all the project risks before the test-planning phase. The risk analysis purpose
is to define the exact testing scope, the testing environments for each tested issue, the
automated tools to be evaluated and the priorities for the testing activities.
For more details you may use the “Web Risk Analysis Template”.
1.3.2.Test Planning
Specifying the testing strategy: which tests are planned (without specifying the exact
scenarios), what are the means for executing them, and what are the estimated human
resources and time schedule for performing the tests successfully. The Software Test
Plan, beside presenting the tests breakdown, tries to deal with all the issues
concerning the testing activities such as the testing environment, responsibilities and
testing risks.
1.3.3.Test Design
Specifying the exact test scenarios is done by Test Rules Definition (TRD) document.
The document specifies the executing procedures and scenarios (which will be quick
to create and easy to maintain) and deals with all the tests preparations. Separate TRD
documents will be produced for each of the planned testing cycles.
1.3.4.Test Execution
Each testing cycle is performed according to its TRD. During the test execution, the
found defects and the conducted measurements are documented using the TRD
documents. Each defect or remark is added to the bug tracking system for later
dealing and handling. Each testing cycle is concluded using a Software Tests Report
(STR) which lists the found defects, conducted measurements and displays trends.
1.3.5.Requirements Reassessment
The last submitted STR is discussed throughout a requirements reassessment review.
The original requirements, which set the basis for the relevant testing cycle are
reexamined and reassessed for the next testing cycle. Each review is documented.
2. Referenced Documents
Specify all the documents that this document refers to.
# Document name Version Publishing Status

Date (Draft/Approved)
1.
2.
3.
4.
3. Testing Strategy
3.1. The Tested System
3.1.1.System Components to be tested
3.1.1.1.Functionality issues
The main processes to be tested:
TBA-Databases are used:
TBA-External systems are involved:
Front-end functionality issues:
3.1.1.2.Performance issues
Main performance –to be tested

Issues to be checked using load test
Kind of automatic tool
What are the main performance issues to be tested (Page load time, downloads time
database’s response - queries, forms).
What are issues to be checked using load tests (transactions’ response time,
correctness of messaging and functionality during load peaks, database capacity etc).
Which automated tool is used?
3.1.1.3.Security issues
User profiles Logins/password, permissions
System configuration Securing the Web server
Internal intrusion Detecting hacker’s activity
What are the tested issues regarding the Web sites securities:
User profile – logins/passwords, permissions etc
System configuration – securing the Web server, firewall configuration, SSL protocol
installation
External intrusion – detecting hacker’s activity, simulating common hacking methods
in order to break into the site.
3.1.1.4.Usability issues
Page layout testing Readability, consistency, simplicity, page
layout defects etc.
Reasonable time for flash Back icon,forward icon
What are the usability issues to be tested:

What are the usability issues tested by conducting surveys – user general impression,
satisfaction and confidence (regarding handing over their credit cards)
What are the usability issues examined using page layout testing – readability,
consistency, simplicity, page layout defects etc.
What is the usability issues tested using users’ behavior analyses – learnability,
clearness of the site etc.
Is the site’s tagging going to be tested - by which search engines and keywords?
3.1.2.System components not to be tested

TBA
3.1.3.Current Status
This project is under development status.
3.1.4.Other points to mention-TBA
Tests Categorizations
3.1.5.Test Levels
What are the test levels: system, integration, subsystem and unit.
Unit – testing the functionality of one unit only (object, function, module)
regarding its possible inputs and expected outputs.
Subsystem – testing the functionality of one subsystem only (integration of
some units) regarding its possible inputs and expected outputs
Integration – testing the functionality of several subsystems integrated together
regarding the possible inputs and expected outputs.
System – testing the functionality of the whole system regarding its possible
inputs and expected outputs.
3.1.6.Test Classes
3.1.6.1.Functionality
3.1.6.2.Performance
3.1.6.3.Security
3.1.6.4.Usability
3.1.6.5.Compatability
3.1.7.Problems Severity Levels

Specify the problem severity levels (urgent, high, medium, minor) and what criterion
is used to determine the problem’s severity level.
3.1.7.1.Urgent – the problem severely damages the software, and

must be taken care of immediately.
3.1.7.2.Medium – the system doesn’t function as it was designed,

and the problem should be corrected.
3.1.7.3.Low – the system should be slightly improved, and the

improvement should be implemented.
3.1.8.Test Criterion
The criterion used for deciding whether a regression test cycle should be decided later
with a developer.
Specify the criterion used for deciding whether a regression test cycle should be
performed as result from the current testing cycle.
3.2. Testing Stages

The testing stages to be performed are:
3.2.1.Risk Analysis
Identify the exact testing scope, testing environments and priorities (before test
planning). Note: this stage ought to be done when those testing details haven’t
been specified or clarified enough within the proposal or the contract.
3.2.2.Test Planning
Specifying the overall testing strategy, the suggested testing breakdown, the
exact time schedule and human resources.
3.2.3.Test Design
Designing the scenarios using TRD documents for each of the planned testing
cycles (functionality, usability, performance and security).
3.2.4.Test Execution
Separate testing cycles, which will be performed using the pre-defined TRD
documents. Specify how the defects and measurements are going to be
managed. Each of the testing cycle should be concluded using a STR
document.
3.2.5.Requirements Reassessment
A requirements reassessment review will be done with the client in order to
reexamine the last cycle’s requirements by discussing the relevant STR.
3.3. Coverage & Traceability

Each individual test in this plan includes direct reference to the requirement/s it
covers. Appendix A of this document includes a coverage report that indicates which
tests cover each requirement.
During the test design stage, test cases will be defined in a way that covers all aspects
of the requirement/s referred to by their parent-test. The test execution will be
checked to verify that all scenarios had been executed and reported accordingly.
3.4. Deliverables
The following documents will be delivered to and approved by the customer:
3.4.1.STP Document
The current document - Software test plan that defines the framework of the
testing process and the overall testing strategy (as detailed at section 3.1.2).
The STP presents the test breakdown, specifies the testing environment, the
human resources, the automated tools and the time schedule for each test.
3.4.2. TRD Document

The Test Rules Definition (TRD) details the general requirements to be tested
during the each test-case execution. The TRD should be easy and fast to
maintain (using a checklist format). Separate TRD documents are ought to be
prepared for each of the testing cycles (functionality, performance, security
and usability).
3.4.3. STR Document

STR document - Software Test Report document describes the results of each
improper/unexpected result found in the system. Resolving some of the
problems might be vital to proceed the test process. This document will be
presented after each test cycle.
3.4.4. Other Documents

The requirement reassessment review: a meeting summary, where the observed
defects and the conducted measurements are discussed in order to reexamine
and reassess the original requirements. A requirement reassessment review must
be held after every testing cycle and must be documented.
3.5. Software Test Environment

This paragraph identifies and describes the plans for implementing and controlling the
resources necessary to perform the tests-TBA.
Where are the tests taking place?

What is the Web server’s configuration?
What is the Web server’s communication infrastructure?
What are the testing environments (computers, operating systems, browsers, etc)?
3.6. Responsibilities
Who is responsible for organizing the testing environment?

Who is responsible for technical support?
Who is responsible for installing the automated tools?
What are the developers’ responsibilities during the QA process?
4. System Breakdown and Test Identification

4.1. Display
4.1.1.Functionality
4.1.1.1.Pages changing
4.1.1.2.Estimated time
4.1.1.3.Integration
Ability to work with different applications:
4.1.1.3.1 Athoc toolbar
4.1.1.3.2 Yahoo companion
4.1.1.3.3 Real player
4.1.1.3.4 Macromedia Flash
4.1.2.Performance
4.1.3.Compatibility
4.1.3.1.Platforms
Supported platforms will include the following:
4.1.3.1.1 Windows 95
4.1.3.1.2 Windows 98 and Windows 98 SR2
4.1.3.1.3 Windows Me
4.1.3.1.4 Windows NT 4 SP1-x
4.1.3.1.5 Windows 2000
4.1.3.2.Browsers
Will work on following browsers:
4.1.3.1.1 Microsoft Internet Explorer
4.1.3.2 Localized versions of OS

Must work on various localized versions of OS (i.e. Hebrew etc.)
4.1.3.3Screen resolutions
Recommended screen resolutions of client PC:
4.1.3.4.1 640*480
4.1.3.4.2 800*600
4.1.3.4.3 1024*768
4.1.3.4Screen color depth

Recommended screen color depth:
4.1.3.5.1 65536 colors
4.1.3.5.2 16777216 colors
4.1.3.5Transfer rates
Check behavior on different transfer rates:
4.1.3.6.1 Dial-up modem
4.1.3.6.2 ISDN
4.1.3.6.3 ISP connection
4.2 Server
4.2.3 Functionality
4.2.3.1 Data base
4.2.3.2 Data flow
4.2.4 Performance
4.2.5 Security
4.2.5.1 Registration
4.2.5.2 Passwords and logins
4.2.5.3 User’s identification
4.2.5.4 Hucker’s intrusion
4.2.6 Usability
4.3 Client
4.3.3 Functionality
4.3.3.1Integration
Ability to work with different applications:
4.3.1.1.1 Athoc toolbar
4.3.1.1.2 Yahoo companion
4.3.1.1.3 Real player
4.3.1.1.4 Macromedia Flash
4.3.3.2Activation
4.3.1.1.5 Install
4.3.1.1.6 Uninstall
4.3.1.1.7 User service
4.3.1.2 Use a keyboard
4.3.1.3 Use a mouse
4.3.4 Performance
4.3.5 Security
4.3.2 Registration
4.3.3 Passwords and logins
4.3.4 User’s identification
4.3.5 Hacker’s intrusion detecti
4.3.6 Compatibility
4.3.6.1Platforms
Supported platforms will include the following:
4.3.5.1.1 Windows 95
4.3.5.1.2 Windows 98 and Windows 98 SR2
4.3.5.1.3 Windows Me
4.3.5.1.4 Windows NT 4 SP1-x
4.3.5.1.5 Windows 2000
4.3.6.2Browsers
Will work on following browsers:
4.3.5.1.6 Microsoft Internet Explorer
4.3.6.3Localized versions of OS
Must work on various localized versions of OS (i.e. Hebrew etc.)
4.3.6.4Screen resolutions
Recommended screen resolutions of client PC:
4.3.5.1.7 640*480
4.3.5.1.8 800*600
4.3.5.1.9 1024*768
4.3.6.5Screen color depth

Recommended screen color depth:
4.3.5.1.10 65536 colors
4.3.5.1.11 16777216 colors
4.3.6.6Transfer rates
Check behavior on different transfer rates:
4.3.5.1.12 Dial-up modem
4.3.5.1.13 ISDN
4.3.5.1.14 ISP connection
5 Data Records and Analysis

Specify the methods used for recording the data, and analyzing it during the testing
execution phase and regarding the STR report.
How are you going to evaluate the quality of the tested system?
Specify the metrics you plan to use in order to evaluate the software developing
quality and the system stability-TBA
6 Risks
Risk Analysis in Testing Software Projects provides initial means of quantifying and ranking
risks which relate to development schedule and deadlines overrun, resources,
technology, development paradigm, end user expectations and other factors.
The Risk Analysis provides the following added-value:
• Better understanding of major Risks and potential problems by all functions

involved in the Project.
• Better forecasting of potential problems and as a baseline for preventive-actions,
rather than corrective-actions.
• Provides initial corrective & preventive actions to minimise the risks
• Provides better control and management of all risks as the Project evolve, by
tracking the risks periodically.
• Provides solid base for QA team to prioritize these efforts, based on the degree of the
risk.
A Typical Risk Analysis/Assessment Table is defined below :
ID Risk Type Severity Probability Risk Risk Minimization Acts

Degree
Columns Explanation:
• ID - Risk Identifier.
• Risk Type - The type/class/description of the risk. The Risk Type will be followed
by an exposure and/or description, when needed.
• Severity - The estimated risk severity based on preliminary inspection measured in

the degree of the potential damages that might occur if and when the risk will be
realized. The risk is ranked in a scale of 1 to 4, where: (1) Minor Damage, (2)
Medium Damage, (3) Severe Damage, (4) Terminal Damage
• Probability - The probability of the risk to occur. The probability is ranked in a
scale of 1 to 5: (1) Improbable, (2) Very low probability, (3) Low probability, (4)
Medium probability, (5) Probable
• Risk Degree - Risk-Severity multiplied by Risk-probability .
• Risk Minimization Acts - A list of suggested corrective/preventive actions needed
to be taken to minimize the risk.
The following table summarises the risk issues and possible parameters for each
one :
ID Risk Type Severity Probab. Risk

Degree
Risk Minimization Action
(A) (B) (A*B)
1 Project Risks : (1-4) (1-5)
1.1 All Software Modules will be

ready on time
1.2 All Software Documents will be
ready on time
1.3 Backup & Recovery Procedures –
should be clearly defined &
implemented
1.4 Separated Testing Environment –
is Defined and Ready
2 Functional Risks :
2.1 Final Definition for CLIENT’S

CONFIGURATION To be tested
2.2 Final Definition for Load test
2.3 Final Definition for Security test
7 Testing Schedule
TBA
Appendix A - Coverage Report

Requirement Test Name
Appendix B – Testing Environments

Operating Browser Screen Transfer The tested issues
System Resolution Rate
Windows 98 Internet Explorer 1024x768 28.8
5 Kbps

3 Kbps

3 Kbps

3 Kbps

3 Kbps

3 Kbps

3 Kbps

3 Kbps

3 Kbps

Web STP Template

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web STP Template

Uploaded by

Copyright:

Available Formats

©2008 Doron Bar.

All Rights Reserved

Web STP Template

Version: 1.0 Production Date:

Change Control Information:

Version Name Scope of changes Date

Name Function Date Signature

1.1.2. System Overview

1.1.3. Document Overview

1.1.4.Relationship to other plans

1.3. Testing Methodology

# Document name Version Publishing Status

Main performance –to be tested

Reasonable time for flash Back icon,forward icon

What are the usability issues to be tested:

3.1.2.System components not to be tested

3.1.4.Other points to mention-TBA

3.1.7.Problems Severity Levels

3.1.7.1.Urgent – the problem severely damages the software, and

3.1.7.2.Medium – the system doesn’t function as it was designed,

3.1.7.3.Low – the system should be slightly improved, and the

3.2. Testing Stages

3.3. Coverage & Traceability

3.4.2. TRD Document

3.4.3. STR Document

3.4.4. Other Documents

3.5. Software Test Environment

Where are the tests taking place?

Who is responsible for organizing the testing environment?

4. System Breakdown and Test Identification

4.1.3.1.2 Windows 98 and Windows 98 SR2

4.1.3.1.4 Windows NT 4 SP1-x

4.1.3.1.5 Windows 2000

4.1.3.1.1 Microsoft Internet Explorer

4.1.3.2 Localized versions of OS

4.1.3.4Screen color depth

4.1.3.5.1 65536 colors

4.1.3.5.2 16777216 colors

4.1.3.6.1 Dial-up modem

4.1.3.6.3 ISP connection

4.2.3.2 Data flow

4.3.1.1.7 User service

4.3.1.2 Use a keyboard

4.3.1.3 Use a mouse

4.3.5.1.2 Windows 98 and Windows 98 SR2

4.3.5.1.4 Windows NT 4 SP1-x

4.3.5.1.5 Windows 2000

4.3.5.1.6 Microsoft Internet Explorer

4.3.6.5Screen color depth

4.3.5.1.10 65536 colors

4.3.5.1.11 16777216 colors

4.3.5.1.12 Dial-up modem

4.3.5.1.14 ISP connection

5 Data Records and Analysis

The Risk Analysis provides the following added-value:

• Better understanding of major Risks and potential problems by all functions

A Typical Risk Analysis/Assessment Table is defined below :

ID Risk Type Severity Probability Risk Risk Minimization Acts

• Severity - The estimated risk severity based on preliminary inspection measured in

ID Risk Type Severity Probab. Risk

1.1 All Software Modules will be

2.1 Final Definition for CLIENT’S

Appendix A - Coverage Report