Wednesday, January 15, 2014

STP (Software Test Planning) – Part 3

Section 4: Testing methodologies
Every testing process should base on testing methodology, this section should explain the one we are going to use on current testing process.

Main Bullets:
  • Selected Methodology – describe the testing methodology (Waterfall, Agile-Model…).
  • Benefits – Describe the benefits we are going to achieve when using it.
  • Flow – Display a short flow for the methodology implementation. 

Low detailed Examples:
V model:
Requirements - > STP - > STD->Unit testing - > Integration testing….

Requirements -> Design-> Implementation->Verification…..

My example contains the headers, you should add additional information per section. 

Section 5: Detailed information regarding your test strategy

These sections should provide detailed information regarding the test strategy we are going to use in the testing process, this strategy should be based on the selected methodology, Available resources (Human, Hardware and more), limitations and requirements.

In a very simple words, this section should describe how the testing process will confirm the actual results against the software requirements (SRS).

For my opinion and based on my actual experience, this section should contain the followings bullets: 

Part 1: Documentations
Every Quality Assurance process contains few mandatory docs (Requirements, STP, STD and STR), this section describe the relevant details for each doc type.


Each doc must Contain :
Detailed information based on customer or business requirements
I hope you understand it after reading current doc…
Highly detailed testing scenarios based on STP, this doc includes the test case and the expected results based on Requirements.
Written after the STD compilation (In some cases you can start written it while executing the STD), this doc must include the testing results, opened bugs, Risks, suggestions and more

Part 2: Separate the software components and determine the integrations between them
The first thing you should do is to ‘Separate’ the software components, 
it’s easier to control your testing process when you design it to multiple
components and not to one big elephant called ‘Software’,
using this strategy you can see the list of integration tests 
you need to test for different components.

Let’s give example for a bank account system:
  • Components: User interface, Login procedure, login engine, Database
  • Integrations: DB and Engine, UI and Engine, DB and UI…

Part 3: Determine the testing cycles
This part should provide the number of testing cycles involved on the testing process, each cycle should be described with the testing types and levels you are going to use, Example:

Cycle 1: Exploratory testing + validating the fulfil of the Entry criteria’s

Cycle 2: Functionality testing + Bug Verifications

Cycle 3: Regressions (Tester 1) + Non functionality tests (Tester 2)

Cycle 4: Sanity

Cycle 5: You got the point….

Part 4: Testing types involved in the testing procedure
This section will be used for describing the testing types we are going to use on the current testing procedure.

Unit Testing – performed by the development team before QA can start Integration tests.

Computability testing – software will be tested on Environment A and B, Operating Systems B and C…

System Tests – the tests will be made after all components and integration tests completed.

International Testing – the product will be tested on different OS language packs because it’s going to be installed worldwide.

Stress Tests – tests will be made on servers that possess massive resources, in addition, the tester will use tools A and B.

In Addition, This section is the place to describe also the testing methods that we cannot accomplished due to lack of resources.

Non functionality testing like Load, Performance and stress that you need specific Tools and Hardware to executing them.

Section 6: Completion criteria’s (Exit Criteria)
This section should specify the exact criteria for success,
if one of the criteria’s not accomplished 
the Risk become larger, Example:
  • All bugs with severity greater than ‘Normal’ verified and closed.
  • All test cases on STD with priority greater than one must be executed.
  • Client requirements covered.

Section 7: High level testing details 
You all know that STP is the Key Stone for a great STD.Therefore this section will hold the main areas you need to test and will be expend on STD documentation.
Main Purpose: 

  • All bullets will be used as guidelines when writing the STD
  • Owner can review the bullets and determine if the coverage is good enough.

In some companies this section called TRD (Test Requirement Document), and will be written as completely different doc.

We have new car for testing, I’ll provide few bullets for testing:

·       Functional Testing :
1.      Test the car switch (Electricity on half switch).
2.      Test the car switch (Engine ignition on full switch).
3.      Test the car switch when Power off.

·       Usability Testing:
1.      Test that the drive shift is smooth and easy to manipulate.
2.      Test the dashboard buttons location and size.
3.      Check if the rear camera is easy to use based on the wheel buttons.

1 comment:

  1. Hello,
    The Article on Software Test Planning is nice give detail information about it.Thanks for Sharing the information about Software Testing Plan Software Testing Services


My Presentations