Wednesday, January 15, 2014

STP (Software Test Planning) – Part 1

The Software Test Planning (STP) is one of the most important documents when designing a software testing process, usually each project contains a single STP that based on information allocated from different resources (Reviews, PM, SRS and more).

STP should (Probably ‘must’ is the correct word…) contain all the relevant information regarding Test procedures for specific software, every STP must provide detailed information regarding the test process (Owners, Timelines, Requirements, budgets, procedures and many more…).

STP can be different per company (you probably get 100 different templates from 100 different companies…). Although, each STP must be based on few mandatory criteria’s that would be examined on the next few paragraphs.

STP – When should we start it..?
STP documentation is a big part on every software testing process, but the question is when should we start to write it..? 

The answer is very simple,
STP become relevant only after few criteria’s accomplished, the following flow will demonstrate this point: 

1.    Client should send a request for a software development based on specific requirements.

2.    After the client requests approved by the company owners (every company should make money…).

3.    Product management team (PM) prepare the software design Documentation (SRS) based on user requirements.

4.    Technical teams (Development, DB...) prepare a detailed Design documentation (DDD) based on SRS requirements.

5.     QA teams have the relevant documentations to start the test plan (STP), this step is dedicate to determine the “What” to test in the Quality procedure.

6.    Based on STP, QA teams prepare the actual test plan (How we are going to test the software).

7.    STR should be available after the testing procedure accomplished.

If you’re not familiar with STD/STR docs, I already started new posts that going to be available in the next few weeks.

STP – Allocating the data
As explained the STP is crucial for your testing process and will be used as bridge for other documentations that based on it. Therefore, the research must be highly effective and relevant resources must be investigated and used. 

The following resources should be used: 
Software Requirements Specification (SRS) – we can declare that SRS is probably the most important resource you should use, in other words we can say that SRS is “The” foundation stone for the entire life cycle (From design and until release).

The SRS Written by the company employs (PM could be great example) and based on the software requirements (usually come directly from the client).

The SRS must be detailed as possible because both development and QA teams will use it (Developers for development and QA for testing documentation (STP/STD...)).

Development– every development process contain unique documentation that handles the develop process, we can use it to understand exactly how the developers develop the software and probably discover high risk areas that could affect the entire testing approach.

Sales/Operations Team – they know the clients and all the week points, they may supply great information regarding main points that may affect the client experience.

Company knowledge base – it’s not something new, but the company KB may supply different point of view or different approach for testing. You can search information on Bug tracking system and learn about issues that may affect the current process or ask experienced manager that already worked on similar project and may add useful information.

The following tools may be used to allocate the data from your resources:
Personal reviews – schedule meetings with every engineer/other employs that relevant, in the reviews you must come with predefined Questions and document all the answers. In my personal experience I cannot start my STP before reviewing all team owners that relevant for my project.


Product manager – provide the “key stones” for the entire project, pay attention to his words…

Database/ Software Engineer – different departments that involved in the development process, here you should find useful info regarding developing issues and weak points that may occur.

Product Manager – understand the priority, timelines, Teams involved and more.

Sales/ Support Personal – learn about your clients and what are they expecting from the end product, investigate older release issues, software recalls and every other detail that may affect the current process.

Team Meetings – from previous example we can see that every project contain multiple teams involved, each team has different project and different agendas, your reasonability is to make sure that all teams synchronized with each other so the info you get is the most relevant and accurate. Furthermore, in team meeting you always find new ideas that may affect the product design and your STP afterwards. 

        Personal Investigation - make your own investigation, to accomplish this task you can use your previous experience and KB, just for example:

  • Investigate your bug tracking system, search for relevant bugs that may reproduce on current version.
  • Search on older documentation for relevant test cases that may be used on current tests.
  • Think about previous projects conclusions (STR’s) and try to understand the failures.

1 comment:

My Presentations