Software Test Report

מטרה של מסמך STR לדווח על כל תהליך של בדיקות לצורך מסקנות.

סיכום בדיקות

כאן זה המקום לדיווח סטטיסטיקות, לדוגמה:

בהרצת מקרי בדיקה ב-STD בגרסה #2644 נתגלו 21 באגים מתוכם 12 באגים נפתחו ותוקנו ועברו בדיקות חוזרות בהצלחה לאחר תיקון.

5 באגים לא נפתחו – אנשי צוות הפיתוח נתנו הסבר מה הסיבה שזה לא באגים.

4 באגים עדיין נמצאים במצב תיקון.

21 באגים תוקנו בהצלחה.

לדוגמה:

במסמך-STD בגרסת Beta 2644# ב-TEST CASE C12 קיבלנו תוצאה לא צפויה!

ID3# BUG דווח ב-Jira, וקיבל סטטוס OPEN בתאריך 10.12.19 בתאריך 12.01.20 BUG תוקן ונבדק לאחר מכן בצוות QA.

הערה: במסמך STR חשוב לכתוב: סיכום בדיקות, לוח זמנים שבהם תוקנו בעיות.., המלצות ולקחים.

המלצות ולקחים

ערכת מצב של התוכנה/מוצר לצורך החלטת אם תוכנה/מוצר מוכן להצגת ללקוח עבור – Acceptance testing

כל כבוד לכם!!!

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

אם תרצו ללמוד מבוא לתכנות ו-SQL כולל HTML, CSS, JS אז באתר יש גם קורסים נחמדים במבוא לשפת Java, JS, HTML/CSS ו-SQL.
כדי להיות בודק תוכנה טוב – לא חובה לדעת תכנות ובסיס נתונים אבל כדי להכיר 😉

שבעת עקרונות הבדיקה

1. בדיקות יכולות להצביע על נוכחותם של פגמים, אך אינן יכולות להוכיח את העדרם של פגמים.
2. בלתי אפשרי לבצע בדיקות ממצות.
3. עדיף להתחיל לעשות בדיקות מוקדם ככל האפשר.
4. מספר קטן של מודולים מכיל את רוב הבאגים – כלומר אם יש מודולים שבהם נמצאו באגים אז יש סיכוי גדול שבמודולים האלו יהיו רוב באגים אחרים.
5. אם חוזרים על בדיקות זהות שוב ושוב, בסופו של דבר אותה קבוצת מקרי בדיקה לא תגלה עוד פגמים חדשים.
6. בדיקות הן תלויות הקשר- בדיקות ברפואה שיש שם סכנת חיים שונות מבדיקות של מחשב.
7. אין טעם לגלות פגמים ולתקנם אם המערכת נבנית אינה שימושית ואינה מספקת את צרכי המשתמשים ואת הציפיות ממנה.

הפסיכולוגיה של בדיקות

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

בדיקות מאפשרות למדוד את איכות תוכנה – QA.

מדוע בדיקות נחוצות ועד מתי לבדוק ?

ללא QA המוצרים יהיו עם הרבה BUGS וכתוצאה מזה יהיו FAILURES. כלומר בעזרת QA אנשי בדיקות תוכנה בודקים ש-BRS-Business Requirement Specification
ו-System Requirement Specifications
שזה אכן מתקיימים כנדרש.

QA מעלה את ה-QUALITY של המוצר ומוריד RISK של FAILURES

כמה צריך לבדוק?

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

בנוסף במסמך STP מוגדרים מתי יש להפסיק תהליך בדיקות (מקרים קיצונים).

תפקידים ראשים בעולם QA ?

Test leader/manger

מוביל בדיקות – אחרי על אנשי בודקי תוכנה (testers) שמנהל את כל תהליך של הבדיקות. להלן תפקידים של מוביל בדיקות (Test leader)

• בניית אסטרטגיית הבדיקות בתיאום עם הנהלה.
• הערכת זמן ומאמץ כולל עלות הבדיקות.
• כתיבת מסמך STP, מעקב אחרי תוצאות הבדיקה של מסמך STD.
• כתיבת דוחות סיכום STR.

TESTERS – בודקי תוכנה

• אחרים על כתיבת מקרי בדירה
• כותבים מסמך STD
• מעריצים ומדווחים גל הבאגים
• עושים בדיקות רגרסיה ו-RE-TESTING …

ארגון הבדיקות

1.  מפתחים בעצמם בודקים את הקוד שלהם ללא אנשי QA עצמיים.
   יתרונות: מכירים את המוצר שלהם ובודקים תוך כדי פיתוח תוכנה.
   חסרונות: לא אובייקטיביים, לא שמים לב על הטעויות שלהם ומוגבלים בזמן של תהליך הבדיקות.
2. בודקים עצמיים בתוך ארגון הפיתוח.
   יתרונות: בודקים אינם מוטים לעומת מפתחים שמוטים להגן על הקוד שלהם – כלומר בודקים עצמיים יותר אובייקטיביים.
   חסרונות: בודקים עצמיים מבודדים ופחות מכירים את המערכת ממפתחים וגם הפיתוח יכול להיות יותר זמן מהמתוכנן מסיבות פורמליות של תהליך הבדיקות.
3. בודקים עצמיים מחוץ לארגון הפיתוח.
   יתרונות: בודקים אינם תלויים בארגון הפיתוח שזה מאפשר לבצע בדיקות יותר אובייקטיביות ועמוקות.
   חסרונות: בודקים עצמיים מבודדים מארגון הפיתוח ולכן יש פחות אינטראקציה עם המפתחים וזה יכול לגרום לחוסר הבנה.

STD – Software Test Description

במסמך STD יש אוסף מקרי בדיקה – TEST SUITE. כלומר במסמך הזה יש חילוק לפי נושאים, כאשר תחת כל נושא יש אוסף מקרי בדיקה ( Test Scenario  ) ובכל מקרה בדיקה יש צעדים עם תוצאה צפויה ותוצאה בפועל עם ציון הצלחה של כל צעד.

אני ממליץ על הכלי לכתיבת מקרי בדיקות TestRail.

בתמונה למטה יש חילוק מקרי בדיקה לפי נושאים, כך שתחת כל נושא יהיה אוסף של מקרי בדיקה.

מה יש במקרה בדיקה – TEST CASE ?

1. Pre-conditions זה נתונים לפני הרצת שלבים של מקרה בדיקה, את הנתונים ניתן לקבל תוך שימוש בטכניקות שונות של בדיקות תוכנה (כאן באתר ראה תפריט עם תיאור טכניקות שונות מעולם QA ).
2. תיאור של הצעד – מה יש לעשות לבודק תוכנה.
3. תוצאת הצעד – PASS,FAILED ורישום תוצאה בפועל תוך השוואה לתוצאה הצפויה. במידה ותוצאה צפויה לא מתאמת את התוצאה בפועל אז יש לדווח על ה-BUG תוך התחשבות ברמת סיכון של ה-BUG (קריטי , חשוב, רגיל…).לצורך דיווח באגים, עדיף להשתמש ב-JIRA.

דוגמה למקרה בדיקה:

עוד דוגמה למקרה בדיקה:

בדיקת כניסת משתמש – positive testing, כאשר בצעד #2 יש באג – bug:

דוגמה למסמך STD:

1) Introduction
 1.1 Document overview
This document is the software test description it contains the description of tests list in software test plan ref. STP#13. The tests will  be executed during
Validation testing:
– Integration testing
– System testing

2) Tests basic preparations
This section contains basic tasks and recommendations before executing tests, the other INPUT DATA and preparations will be added with the depending by test case.

2.1 Hardware basic preparation

Describe platform configuration operations, like specific hardware to be used, physical network configuration.

• Web server (minimal)
• 1,75 GB RAM
• PHP > 5

2.2 Software basic preparation data

Describe software set-up and configuration operations, like simulators or software test tool to be used or the data.

2.2.1 JewNetwork user data:
– Email: [email protected];
– Password: sfdf4Kd2dnen1de9J
URL: Beta.JewNetwork.com

3) Test scenarios

3.1) Signup – Test Scenario
3.1.1) Negative test case – SPAM CHECK during registration.
3.1.2) Positive test case – SPAM CHECK during registration.
3.1.3) Positive test case – email confirmation.

3.2) Sign-in -Test Scenario
3.2.1) Positive test case – Login
3.2.1) Positive test case – Password recovery
3.2.3) Negative test case – Password recovery

3.3) Guest a non login visitors -Test Scenario
3.3.1) Positive test case – Read posts

…..

3.4) SEO -Test Scenario
3.5.1) Check meta tags
3.5.2) Keyword match for the articles.

Test case

ב-test case יש צעדים אם תיאור מה יש לעשות לצורך בדיקה עם עמודות של מספר צעד, תיאור הפעולה, ותוצאה בפועל, תוצאה צפויה וסטטוס של הצעד – עבר לא עבר..
נוח לאחד מספר test cases לפי תפקוד כגון איחוד כל test cases הקשורים לכניסה לאתר אינטרנט, האיחוד הזה נקרא תרחיש (TEST SCENARIO).

דוגמה של מקרה בדיקה – test case:

Test Scenario

תרחיש מבוסס על המסמכים: BRS, SRS, STD והוא כולל אחת או מספר מקרי בדיקה.

לדוגמה:

למעשה בדוגמה הזאת יש לנו ב-TEST SUITE אחת, שני תרחישים וששה מקרי בדיקה.

Checklist – צ'ק ליסט

הבדל בין צ'ק ליסט – Checklist ל-test case שב-Checklist אין תיאור מה יש לעשות בצעדים אלא רק מה לבדוק ללא פירוט איך לבדוק, כלומר Checklist מיעוד יותר לבודקי תוכנה שמכירים את המערכת וכאשר אין זמן לכתיבת תיאור של צעד אחרי צעד כמו שעושים ב-test case.

כאשר סטטוס יכול להיות PASS או FAIL.

Test design זה: תהליך של הפיכת תוכן המסמך SRS למקרי הבדיקה (test cases).

טוב, נניח שמצאתם BUG ועכשיו זה הזמן לדווח עליו במסמך- Bug report או עדיף להשתמש לצורך זה ב-BUG TRACKING SYSTEM לדוגמה JIRA.

Jira מאפשרת לנו לדווח על הבאגים, ליצור משימות ו-user stories. בנוסף יש אפשרות להעריץ SPRINTS תוך שימוש בגישת AGILE SCRUM.

Bug life cycle

אנשי QA מעברים BUG למפתחים ל-(BACKLOG) לצורך החלטה של הסטטוס עבור באג הזה.

• BUG יקבל סטטוס Rejected: באג לא ניתן לשחזור.
• BUG יקבל סטטוס Duplicate: באג כבר קיים.
• BUG יקבל סטטוס Deferred, Postponed: באג אכן קיים אבל אין צורך לתקן אותו עכשיו.
• BUG יקבל סטטוס OPEN: באג אכן קיים וצריך לתקן אותו.
• נניח במהלך בדיקות חוזרות לבאג עם סטטוס (תוקן-FIXED), הבאג עדיין לא תוקן!
  במקרה הזה באג מקבל סטטוס– REOPEN.
• כאשר באג תוקן – FIXED
• BUG יקבל סטטוס DONE: באג תוקן ויש צורך בבדיקה של אנשי QA

דוגמה ליצירת פרויקט ב-Jira

באו ניצור Scrum פרויקט.

יש לעבור בקישור https://www.atlassian.com/software/jira

לאחר הרשמה קצרה יפתח חלון הבא:

יש לבחור שם האתר, למעשה זה יהיה קישור לפרויקט JIRA שלכם בענן.
לדוגמה אם נבחר qablog אז קישור לכלי Jira שלנו יהיה:
qablogi.atlassian.com

לאחר מכן יש לדלג על כל מיני הצעות של Atlassian עד שיהיה חלון הבא:

ואז יש לבחור את Scrum

נבחר שם לפרויקט ומזהה לפרויקט.

לדוגמה:

שם: Test Name ומזהה: TN2

יש ליצור ספרינט חדש(נקרא לספרינט: TN2 Sprint 1).
לצורך זה – יש להיכנס ל-Backlog וללחוץ על הכפתור Create New Sprint

הוספת באג חדש ל-Jira

לדוגמה ניתן להוסיף באג חדש ל-BACKLOG.

Test Lead/Team Lead, בוחר מ-BACKLOG באגים פתוחים (שיש להם סטטוס OPEN) ומעביר אותם ל-Active Sprint. לעמודה "To Do".

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

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

קודם כל נשאלת שאלה הבא: מאיפה באים BUGS : )

מאיפה באים באגים?

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

עלות התיקון של באגים

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

Software Problem Report 

דיווח באגים – חשוב מאוד לרשום ב-SPR את התיאור של צעדים שגורמים ל-BUG וגם SEVERITY (כמה ה-BUG משפיע על המערכת) ו-PRIORITY עדיפות לתיקון BUG.

I like bug tracking system Jira : )

 Bug lifecycle

• כאשר נפתח BUG אז הוא מקבל סטטוס OPEN
• כאשר בעבר באג תוקן ושוב חוזר אז באג מקבל סטטוס DUPLICATE
• אם מפתח או ראש צוות פיתוח אמר שזה לא באג אז סטטוס – REJECTED
• כאשר באג תוקן – FIXED
  הערה:
  • לאחר תיקון באגים, יש לעשות בדיקה חוזרת RETEST ולוודא שהבאג אשר תוקן.
  • בנוסף יש לעשות בדיקות רגרסיה.
• נניח במהלך בדיקות חוזרות לבאג עם סטטוס (תוקן), הבאג עדיין לא תוקן!
  במקרה הזה באג מקבל סטטוס– REOPEN.
• לאחר תיקון הבאג אם אין יותר באג בבדיקות חזרות אז הבאג מקבל סטטוס – CLOSED

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