Global Side Menu Width
Placeholder

STP – Software Test Plan

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

מה יש במסמך STP?

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

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

1. 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



2.INTRODUCTION

Project Overview A brief summary of the product being tested.
3.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.
4. Support documents

BRS, SRS and SDD documents.
* SDD document will be attached latter!
5. Tree Testing


6. Entry and Exit Criteria

6.1 Entry Criteria
 - Android mobile devices: J7 and A8;
 - Android 7 and over;
 - Product version V 4.3.6
 

6.2 Exit Criteria
 - 0 critical bugs;
 - 0 Regression bugs;
 - MAXIMUM 3 Medium bugs;
 - MAXIMUM 7 LOW bugs;
7. TEST STRATEGY

7.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. 
7.2. Test Automation 
Automated unit tests are part of the development process, but no automated functional tests are planned at this time.
 
7.3. In Scope     
 
7.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 and mobile version.
TESTERS: Testing team. 
METHOD: This exploratory testing is carried out in the application without any test scripts and documentation. 

7.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. 

7.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.

7.4. Out of scope 
PURPOSE: Clarity on what we are not going to cover. 
Not in Scope: Testing of Business SOPs, disaster recovery
8.Testing methodology 

8.1 Validation and Defect Management
Defects found during the Testing will be categorized according to the bug-reporting tool “Jira” and the categories are:



8.2. Defect tracking & Reporting
Flowchart depicts Defect Tracking Process



8.3. Status of the Bug/Fault
 - New: Just created bug;
 - Open: Opened bug and still not solved;
 - Rejected: Dev Lead rejected it (it's not bug);
 - Fixed: SOLVED bug;
 - Closed: After bug is fixed, need close this bug;
 - Re-Open: Bug was been fixed and closed but appear again with time;

8.4 TEST MANAGEMENT PROCESS

8.4.1 TOOLS



8.5. Assumptions / Risks 

8.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. 

8.5.2. Risks  8.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 planned. 
8.5.4. Resumption Requirements: Remains <=2 high priority bugs Remains <=10 med/low priority bugs Testing environment fixed and works as planned.

9. TEST ENVIRONMENT 
9.1. HARDWARE REQUIREMENTS 
- Computer with 8 GB RAM, Windows 10 and Chrome;
- Android(7 or over) mobile phone J7 and A8;
 - iPhone... 

10.Milestones



 11. ROLES & 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 for the STD document.

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