1. Planning & control – תכנון ובקרה כוללות:
   
   תכנון - כתיבת מסמך STP  – SW Test Plan הכולל קביעת מטרות הבדיקות והפעולות להשגתן, קביעת תכולת הבדיקות והסיכונים, זיהוי גבולות המערכת, גישת הבדיקות, מדיניות ואסטרטגיות, ניצול משאבים (כ"א, כלים), לו"ז וקריטריונים לכניסה ויציאה עבור רמות הבדיקה.
   בקרה – השוואת התקדמות במשימות השונות לעומת התכנון (בכל הפרויקט), דיווחי סטטוס וסטיות מהתוכנית המקורית ומה עושים כדי להשיג את מטרות הפרויקט, עדכון התכנון בהתאם לתוצאות הבקרה והגדרת שימוש במדדים  ודו"חות.
   ה IEEE (הארגון העולמי למקצועות הטכנולוגיים) הגדיר מה צריך לכלול מסמך ה STP - להורדה לחץ כאן.
   לקריאה נוספת, מאתר  softwaretestingfundamentals.com - לחץ כאן.
    

2. Analysis & design – ניתוח ותכנון הבדיקות כוללים:
   
   ניתוח – תכנון תסריטי הבדיקות ע"י כל מסמכי הדרישות ובחינה האם הדרישות הפונקציונאליות ניתנות לבדיקה.
   תכנון / אפיון – תרגום מסמכי ה test basis לחוקי הבדיקה (test condition / test rules) כדי לראות שהם עונים על החוקים הפונקציונאליים, תיעדוף בדיקות, פירוק של חוקי הבדיקה לתסריטי בדיקה (תכנון אילו תסריטי בדיקה יכתבו) ובאילו טכניקות יכתבו, וזיהוי נתוני הבדיקה test data (הנתונים שיש להכין מראש לפני שלב הרצת הבדיקות).
    

3. Implementation & execution – יישום והוצאה לאור - כתיבת תסריטי בדיקות והרצה:
   
   יישום  - כתיבת תסריטי הבדיקה test cases כולל צעדים steps.
   התסריטים כוללים מה הם התנאים מוקדמים של הבדיקה, אילו ערכים צריכים להכניס בבדיקה ומה התוצאה הצפויה שאנחנו צריכים לקבל.
   בשלב זה יש לתעדף את תסריטי הבדיקות, לדאוג לשמור על עקביות בין מסמכי הדרישות (test basis) לתנאים שיש לבדוק (test conditions) ולבדיקה עצמה.
   הכנת נתוני בדיקה (test data) הכרחיים להרצת תסריטי הבדיקות, תכנון סביבת הבדיקות, תשתיות וכלים להרצת הבדיקות (ואיך יבוצעו ידני או אוטומטי) ויצירת מנות הרצה test suites ( אוסף של תסריטי בדיקה מסודרים לפי סדר הרצה מסוים, מצב מערכת בסוף תסריט אחד משמש כתנאי קדם להרצת התסריט הבא).
   
   הוצאה לאור – הרצת הבדיקות: בשלב זה יש לאמת האם כל הדרישות כוסו ע"י תסריטי הבדיקה, האם אושרו כטובים? האם הסביבות מוכנות, האם המערכת או הגרסה החדשה מוכנה לבדיקות, האם כל האנשים שאני צריך זמינים לתקופת הבדיקות (המפתחים, האדמניסטור של המערכת וכו'), רישיונות משאבים זמינים וכו'.
   שנייה לפני - עושים בדיקות שפיות (sanity test) – מריצים test suite הכוללת סט של בדיקות ובודקים את הפונקציונאליות העיקרית שיש במערכת כדי לוודא שהרמה הבסיסית מוכנה ואפשר להתחיל להעמיק בבדיקות עצמן:
   •    להריץ מנות הרצה ותסריטי הבדיקה שנכתבו
   •    אפשר להריץ בדיקות אוטומטיות
   •    תיעוד התוצאות – נכשל / עבר / לא הושלם / לא רץ – בכל שורה ב test case
   •    השוואת התוצאות, בידודן ובדיקות חוזרות נקודתיות ורגרסיה.
    

4. Evaluation exit criteria and reporting – הערכת קריטריון יציאה ודו"ח סיכום – STR 
   
   לאחר שסיימנו לבצע את הבדיקות, נבנה דו"ח מסכם על ביצוע הבדיקות (test summary report) הכולל: ניתוח מידע וממדים, הבדלים בין התכנון המקורי לביצוע בפועל של הבדיקות, הערכת התקלות הפתוחות, סיכונים קיימים ומידת הביטחון במערכת.
    

5. Closure – פעילויות סיום פרויקט הבדיקות:
   - האם כל תוצרי הבדיקות (לפי מה שסוכם שיבדק) נמסרו?
   - האם נסגרו התקלות הפתוחות שתוקנו (או מועברות בהחלטה מוסכמת, לגרסה הבאה).
   - מאחסנים את כל סביבת הבדיקות, חוקיות, תסריטים, נתונים וכו', לשימוש עתידי.
   - מעבירים את סביבת הבדיקות (testware) לתחזוקה.
   - מבצעים ניתוח והסקת מסקנות מהליך הבדיקות בפרוייקט לשיפור עתידי.

​

​

​

​

ועם כל הכבוד לתיאור תהליך הבדיקות שמציג ה ISTQB, אני רוצה להציג את התיאוריה של ג'יימס באך:

​

RST - Rapid Software Testing

 

לאורך שנות עבודתו של ג'יימס באך בחברת אפל בשנות ה 80 וה 90, הוא פיתח מספר תיאוריות בנושא בדיקות. 

התיאוריות שלו גובשו לאורך השנים ובשנת 2001 פרסם את מודל: RST -  Rapid Software Testing.
ג'יימס באך הוא אחד המתנגדים לבדיקות התיאוריות המסורתיות, מבחינתו כל ההתעסקות בכתיבת בדיקות זה בזבוז זמן.

פוסט שכתבתי בפייסבוק אודות ההיכרות האישית הראשונה שלי איתו בקישור הזה.

​

במודל שלו, מדבר באך על הדרך להפוך להיות בודקים טובים יותר תחת לחץ ומציע 5 נושאים עיקריים:
1. להפסיק לעשות דברים שאינם עוזרים (כתיבת בדיקות למשל).
2. לקחת בחשבון ניהול סיכונים.
3. להשתמש בכלים ע"מ לזרז את תהליך הבדיקות.
4. לדעת להסביר את הבדיקות והערך שלהם למנהלים.
5. תמיד להרחיב את היכולות כדי לעשות את כל הדברים מהסעיפים הקודמים ביחד.

​

להמשך קריאה בנושא בבלוג של באך - לחץ כאן

​

ג'יימס באך מציע להשתמש ביוריסטיקות (כללי אצבע) כיצד לגשת לבדיקות בצורה תלויית הקשר:

Heuristic Test Strategy Model

​

​