STP – Software Test Plan

STP – Software Test Plan זה מסמך שיש בו תכנון בדיקות, המסמך STP מיועד לבודקי תוכנה שיש שם תיאור של כל אסטרטגיות לתהליך בדיקות, לוח זמנים, דרישות לבדיקות, קריטריונים של מעבר…

מה יש במסמך STP ?

  1. טבלת שינוי גרסה של מסמך STP (אם מסמך STP מעדכן אז יש להוסיף את הפרטים של שינוים בטבלה הזאת. )
  2. מבוא – מספר מילים על הפרויקט.
  3. תיאור מטרת מסמך STP – פירוט לשם מה מיועד מסמך הזה (כלאומר לשם מה יש צורך במסמך הזה ומה מתאר מסמך STP ).
  4. מסמכים תומכים: כגון מסמך SRS שלפיו  בונים תרחישים – Test scenarios
  5. אץ נושאי בדיקות – תיאור בדיקות לפי רמה ותת רמה. לדוגמה: בהתחלה בודקים מסך הרשמה כולל כל הקישורים למסך זה, לאחר מכן בודקים מסך כניסה…
  6. הגדרות קריטריוני כניסה להתחלת בדיקות וקריטריוני יציאה לסיום הבדיקות.
  7. הגדרת אסטרטגיות של הבדיקות: איזו סוגי בדיקות יהיו בתהליך של בדיקות (כגון איזו בדיקות לא/פונקציונליות יהיו)
  8. מתודולוגיות של בדיקות: מה תנאים שהבאג יהיה מוגדר כ- LOW, Medium, High.
    הגדרת סטטוס של מקרי בדיקה.
  9. תיאור סביבה של מערכת שאותה הולכים לבדוק.
  10. הגדרת לוח זמנים – הגדרת לוח זמן לכתיבת מסמך STD, כתיבת מקרי בדיקה, זמן משוער לתיקון באגים ושחרור גרסת Alpha, Beta, Release.

 

מסמך STP נוצר בדרך כלל על-ידי מנהל בדיקות – Test Lead. תהליך כתיבת מסמך STP מתחיל בפזה שבה הדרישות של הלקוח מתורגמים לדרישות עסקיות (Business Requirement Specification) כלומר בפזה של יצירת מסמך SRS – Software Requirements Specification ועד לפזה של יצירת מסמך Software Design Document- SDD.

דוגמה של מסמך STP:

Software Test Plan

Version: 1.0
Created: 02/05/2017
Last Updated: 07/05/2017


Test Plan Template:

(Name of the Product)

Prepared by:

(Names of Preparers)


Document History


1.INTRODUCTION

1.1.Objectives
 This test plan describes the testing approach,  the objectives, scope, schedule, risks, approach, Enter&Exit criteria, Test Tree and Testing methodology.and overall framework that will drive the testing.

1.2.Project Overview
 A brief summary of the product being tested.
2. TEST STRATEGY

2.1. Test Approach
The tests mainly targets the GUI testing and validating data Requirements Specifications provided by Client.
The project is using an agile approach, with weekly iterations. At the end of each week the requirements identified for that iteration will be delivered to the team and will be tested.

2.2. Test Automation
Automated unit tests are part of the development process, but no automated functional tests are planned at this time.

2.3. In Scope  
  
2.3.1. Exploratory
PURPOSE: the purpose of this test is to make sure critical defects are removed before the next levels of testing can start.

SCOPE:  Signup, Send message

TESTERS: Testing team.

METHOD: this exploratory testing is carried out in the application without any test scripts and documentation.

2.3.2. User Acceptance Test

PURPOSE: this test focuses on validating the business logic.

TESTERS: Client side testers. 

METHOD: UAT test cases based on the inputs from End user and Business Analyst’s.

TIMING: After all other levels of testing (Exploratory and Functional) are done.

2.3.3. Functional Test

PURPOSE: The functional testing is carried out by feeding the input and validates the output from the application.

Scope: 


 
TESTERS: Testing Team.

METHOD: The test will be performed according to Functional scripts, which are stored in test rail.

TIMING: after Exploratory test is completed.

2.3.4. Tree Testing:
2.4. Out of scope

PURPOSE: Clarity on what we are not going to cover.

Scope: Testing of Business SOPs, disaster recovery
3.EXECUTION STRATEGY

3.1. Entry and Exit Criteria
-----
3.2 Validation and Defect Management
Defects found during the Testing will be categorized according to the bug-reporting tool “Jira” and the categories are:



3.3. Defect tracking & Reporting
Flowchart depicts Defect Tracking Process



3.4. Status of the Bug/Fault

 4.TEST MANAGEMENT PROCESS

  4.1 TOOLS:


5.Assumptions / Risks

5.1. Assumptions for Test Execution
All the conditions that need to hold true for us to be able to proceed successfully.

EXAMPLE:
For User Acceptance testing, the Developer team has completed unit, system and integration testing and met all the Requirement’s based on Requirement Traceability Matrix. 
User Acceptance testing will be conducted by End-users.

5.2. Risks


5.3. Suspension Criteria:

If the number or type of defects reaches a point where the follow on testing has no value!

So testing will be stopped if:
>=5 high priority bugs
>=20 med/low priority bugs
Testing environment not works as as planned

5.4. Resumption Requirements:
Remains <=2 high priority bugs
Remains <=10 med/low priority bugs
Testing environment fixed and works as as planned
6.Milestones / Deliverables



6.2. Deliverables




 7. RESOURCES/ROLES & RESPONSIBILITIES
 7.1. Roles and Responsibilities

QA testers:
* Develop test cases and combine them in test suites – STD
* Report BUGS
* Regression testing

Test manager:
* Manage the Testing and provide technical support to the Testing team.
* Make Review of Software Test Plan and test cases.

Test Lead:
* Prepare the Software Test Plan
* Analyze requirements during the requirements analysis phase.
* Evaluating exit criteria
* Preparing Test Summary Report
8. TEST ENVIRONMENT

8.1. HARDWARE REQUIREMENTS

Computers
Modems

8.2.ENVIRONMENT REQUIREMENTS

9.APPROVALS