Wednesday, January 15, 2014

STP (Software Test Planning) – Part 2

Your STP structure may be different per company, in some companies the STP may include different sections that not relevant to other companies,but must in the local QA process.

This section will provide my suggestion for the “Key Stones” that every STP must have, feel free to comment my suggestions I’m always eager to learn new ways to improve myself.

Section 1: Project Review
This section will cover the main bullets relevant for the current project, someone who read this section should be able to understand the main concept of this project and the way it’s going to be tested.


Introduction (Project) - Describe the project in few words (You can also describe the main features and benefits we gain when using STP docs).

Software Review - you should add detailed information regarding the tested software, I suggest few fields that cover this task:

  •  Description – Describe the software and the main functionalities.
  • Benefits – what’s the benefits for user when using this software.
  • Requirements – Describe the requirements that used as development guidelines.
  • Targets – What are the main targets for this software?

Document Structure – Here you should add a list of all sections (Timelines, owners, Testing Types, External tools, environment and more...).

Data Resources – add table of resources this STP based on, this table is very important when other owner/tester wants to check your data (SRS, DDD and more…).

Terminology – explain the term’ used on this document, not all readers can understand the meaning of SRS, DDD and TBD….


To be defined
Software Test Result
Software Test Description

Owners – add list of owners, other users who read this doc should know all employees involved in the testing procedure (Product manager, Developers, testers...).


Omer .S.
DB Manager
Dan .e.
QA Manager

Timelines - you should add the timelines for this project, the following table demonstrate it perfectly:

Estimated Times
Entry Criteria
QA team should prepare list of tests executed by development team, in addition QA team will define set of criteria that must be accomplished before the software can be delivered from Dev. to QA.
Start Date :1/1/2013
End Date : 1/2/2013
Detailed design for How we are going to test the software
Start Date :1/2/2013
End Date : 1/10/2013
Exploratory Testing
After Software delivered the QA team will execute Exploratory testing
Start Date :1/10/2013
End Date : 1/12/2013
Functional Testing
Execution for Functionality testing
Load Testing
Load Testing using External Testing Tools
Bug Verification
Closing all opened bugs
Short sanity before Alpha
Testing results
End Date : 2/1/2013

Section 2: Testing Environments 

This section describes the testing environments used to test the software, this section should be very detailed so everyone who wants to read this section can understand the testing architecture and the limitations we have on tests due to missing Hardware/Software for tests.


Testing Type
Detailed Information
Unit Testing
Developer Testing environment
All unit tests will be performed to check units integration before validating components integration (QA Side)
Integration Testing
Testing execution on QA environment
All tests performed on QA testing environment before starting System and Computability testing
Servers : Win 2012 ,Celera,  NTAP
compatibility Testing
QA testing environment
Different DB : Oracle, SQL ...
Different Web Browsers: Firefox, Explorer…
Alpha Testing
Company production
Installation made after all Exit criteria accomplished on last build

Testing Limitations:
Describe the limitations based on available resources, for example:
  • Load Testing cannot be performed due to lake on Cup’s and Storage limitations.
  • Compatibility testing on Exchange 2013 cannot be executed due to missing license.

Section 3: Testing Tools
This section should cover two important issues:
  • Relevant tools that we are going to use in the testing process.
  • Tools we need for testing and not available on current timelines.

This section is very important because testing tools are decisive part in almost every testing process, in addition this is the place to describe the limitations we have if some testing tools will not be available.

In addition, the project owner should understand how the testing tools can help the QA teams to reduce the risks and expand the testing coverage.

No comments:

Post a Comment

My Presentations