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

בדיקות שלא קשורות לפונקציונליות של רכיב או המערכת אלה מטרה שלהן לבדוק את שימושיות, יעילות, ניידות..

Performance testing

בדיקות הביצועים על מנת לברר עד כמה מהירות פעולה של המערכת מתאמת את הדרישות  של הלקוח.

Load testing

בדיקת התנהגות מערכת תוך עומסים מוגדרים (עומסים נורמליים אשר מתוארים בדרישות) על מנת לברר שמערכת מתפקדת כנדרש בדרישות מבחינת הזמן.

לדוגמה: בדיקת זמן תגובה של הרשת חברתית, כאשר יהיו מעל 1K משתמשים בו זמנית.

Stress testing

בדיקת מערכת במצבים "מעל מצבים נורמליים" כלומר מעל נקודות הקיצון שבהם מערכת מתפקדת בצורה תקינה– בודקים כמה מערכת יציבה.

לדוגמה:

אם עושים לולאה אין סופית וכל זיכרון של המחשב הולך על זה – אז אם זה יגרום לזה שהמחשב לא יתפקד או מחשב יעבוד בכל זאת – כלומר לא יהיו נפילות.

עוד דוגמה:

בדיקת התמודדות שרת עם יכולות לעמוד בעומסים קיצונים.

Volume testing

מטרת בדיקת נפחים לבדוק שמערכת מתפקדת כפי הנדרש בנפחים מוגדרים (כמות המידע גדולים).

לדוגמה: בדיקת שאתר מתפקד כמו שצריך עם כמות משתמשים גדולה מאוד(לא חובה בו זמנית…. כי עבור בדיקות של זמן אמת  קיים  Load testing).

RTM – מטריצת הקשר בין מקרי בדיקה (test cases) לדרישות.

מטריצת הקשר RTM מאפשרת לנו לתכנן איזו מקרי בדיקה יש לממש ולהיות בטוחים שיש כיסוי מלא לכל דרישות.

נניח במסמך BRS יש שתי דרישות:

BRS1  Flight Booking Module :

User book flight tickets with different options



BRS2  Payment Module:

User should able to make payment by PayPal, Credit Card like VISA, MasterCard

במסמך FRS יש תיאור של הדרישות של מסמך BRS

BRS1  Flight Booking Module :

FRS1 : One Way Ticket booking

     Buy ticket only forward

FRS2 Round Way Ticket

     Buy ticket forward and back

FRS3 Multicity Ticket booking

        Buy ticket forward and back with different locations

BRS2  Payment Module:

   FRS4: By PayPal

    Only verified PayPal accounts can do it. 

FRS5 By Credit Card

  Visa, MasterCard, IsraCard

FRS6 By Cash

It should allows user to make payment by cash at airport 

Requirement Traceability Matrix – RTM

במקרה שלעיל יש כיסוי מלא של מקרי בדיקות (למרות שהם ללא פירוט _#TC) עבור הדרישות.

מקרי בדיקה VS תסריטי בדיקות ומטריצת דרישות RTM:

ניתן לראות לפי מטריצת הדרישות RTM שיש כיסוי מלא במקרי בדיקות (כל מיני וריאציות לשני תסריטים) וכיסוי בשני תסריטי בדיקות את הדרישה פונקציונלית ממסמך SRS -"כרטיס רק לכיוון אחת" .

אם זאת אין כיסוי מלא בתסריטי בדיקות ומקרי בדיקות של דרישה פונקציונלית עבור טיסה הלוך וחזור ובכך אין כיסוי מלא לדרישה עסקית "כרטיסי טיסות".

הערה להבי מסמך STP: בזמן כתיבת מקרי בדיקות לתסריטים שלנו, בדרך כלל מנהל בדיקות מעריך כמה זמן יקח להריץ מקרי בדיקה ועל סמך זה בונים לוח זמנים להרצת מקרי בדיקות במסמך Software Test Plan.

ניתן לקרוא יותר פרטים על מסמך בדיקות STP בקישור:
qablog.co.il/stp-software-test-plan

בדיקות תפקודיות כגון האם רכיב הזה עובד או לא עובד כפי נדרשת פונקציונליות שלו, כאשר בודקים את המערכת בתוך הקוד – מבפנים.

לעומת זאת גישת קופסה שחורה אומרת שיש לבצע בדיקות תפקודיות  ללא הבנה איך הכל עובד בתוך הקוד או חומרה.

 Data flow testing

A: int x,y,a,b;
B: scanf("%d %d",&x,&y);
C: a=x;
D: b=y;
E: while(a!=b) {
F: if(a>b)
G: a-=b;
H: else b-=a;
I: } printf("%d",a);

הערכה עד כמה טוב בדקנו לפי סה”כ באגים שדווחו כנגד לבאגים אשר פתרו.

Test efficiency=x/y
a=באגים אשר פתרו
b=סה"כ באגים שדווחו 
Testing Efficiency=[a/b]*100

.

State transition testing – Functional Testing

בדיקות מסוג קופסת שחורה שבה יש תלות מצב אחת בשני.

דוגמה:

דיאגרמת מצבים עוזרת לבנות סטי של מקרי בדיקה (test suites) כאשר יש מספר אופציות בדרך למטרה. זאת אומרת שיש תלות תנאי הבא בתנאי שקודם לו  בתהליך של פעולה, לדוגמה הוצאת כסף ב-ATM.

הערה: לעומת טבלת מצבים ששם יש מספר תנאים (כל תנאי יכול להיות נכון או לא נכון והם לא תלויים אחד בשני) ,בדיאגרמת מצבים יש תלות בתנאי הבא או שקודם לו.

.