מאת קובי יונסי
במאמר זה נסביר מה הוא ההבדל בין קריטריון כניסה ליציאה.
כיצד מגדירים קריטריונים אלו ואיפה אנו פוגשים אותם במהלך ההתהוות של פרויקט הבדיקות. בין היתר נחשף לדוגמאות שונות של קריטריוני כניסה ויציאה מפרויקטים אמיתיים.
קריטריוני כניסה ויציאה הם בעצם פרמטרים חשובים לצוות הבדיקות בכדי שנבין מתי פעילות הבדיקות אמורה להתחיל ומתי להסתיים. הקריטריונים הם חלק בלתי נפרד מתהליך תכנון ואומדן הבדיקות ומופיעים כחלק ממסמך תכנון הבדיקות הרשמי (STP).
ההבדלים בין הקריטריונים
קריטריון כניסה:
קריטריון כניסה מגדיר את תנאי הקדם להתחלה של פעילות בדיקות נתונה.
במילים אחרות מדובר על הגדרה של נקודת ההתחלה, כך גם נקרא הקריטריון כשאנו עובדים בשיטה האגי'לית.
הנחת המוצא היא שלא נתחיל בבדיקות לתוכנה שאינה יציבה או שלא הגיעה אלינו ברמה מספקת בכדי להתחיל להריץ בדיקות שהכנו מראש.
פעילות הבדיקות היא בד"כ תהליך עתיר משאבים שמצריך תיאום ותכנון ואין הגיון להתחיל בבדיקות כאשר המערכת לא עוברת למשל בדיקות שפיות ראשוניות, כלומר איננה מבצעת את הפונקציות הבסיסיות אותן היא נדרשת.
מטרת הקריטריונים היא להבטיח שהמערכת אכן מוכנה לבדיקות ובכך למנוע מצבים של אי יציבות ועבודה כפולה.
קריטריונים אפשריים שיכולים לשמש אותנו להחלטה אם להתחיל או לא:
- זמינות של סביבת הבדיקות
- זמינות של הכלים איתם נבצע בדיקות
(למשל אם הושגו הרישיונות הנדרשים)
- זמינות של נתוני הבדיקות
- זמינות של פריטי מידע שעמדו בקריטריון היציאה
- זמינות של דרישות אשר ניתנות לבדיקה
קריטריוני כניסה יכולים גם להיות מחוץ לעולמות התוכנה כמו למשל:
- היערכות של הצוות מבחינת זמינות כוח אדם
- תנאי כניסה המוגדרים על ידי רגולציה
- תנאי כניסה המושפעים מתוקף חוזה מול הלקוח
- תנאי כניסה המותנים בפירעון תשלום של הלקוח
כל אלו יכולים להוות סוגים שונים של קריטריוני כניסה שאם לא יתקיימו, פעילות הבדיקה תימשך כנראה זמן רב יותר מהצפוי, תעלה יותר כסף ותסכן את תהליך הבדיקות בהיבטים של עלויות, זמן וחריגות אחרות שאינן רצויות.
דוגמא ממשית לקריטריון כניסה:
| שלב | קריטריון |
| בדיקות שפיות | בוצעו כל הבדיקות שתוכננו |
| בדיקות שפיות | כל הבדיקות שבוצעו, עברו בהצלחה |
בדוגמא הנ"ל מבקש מתכנן הבדיקות להצהיר שמבחינתו כניסה לתהליך הבדיקות מותנית בכך שכל הבדיקות שתוכננו מבעוד מועד כבדיקות שפיות ירוצו ומבחינתו חשוב שכל הבדיקות שהורצו עברו בהצלחה.
ראוי למשל במקרה כזה, לשאול את המחבר – בכמה בדיקות מדובר שכן אם מדובר באתר תדמית למשל אפשר להסתפק במס' מועט של בדיקות שפיות כיוון שהמערכת אינה קריטית.
זאת בניגוד למערכת מעולמות המדיקל, הצבא או התעופה ששם ראוי שהקריטריונים יהיו מהודקים יותר ולכן נצפה לכמות גבוהה מאוד של בדיקות שפיות וכך נקבע רף גבוה יותר לתחילת העבודה.
קריטריון יציאה:
קריטריון זה מגדיר אילו תנאים יש להשיג בכדי להצהיר על השלמה של רמת בדיקה או סבב בדיקות.
אנו נפגוש את הקריטריון במסמך תכנון הבדיקות (STP) וגם במסמך סיכום הבדיקות (STR) שבו נוכל לגלות אם עמדנו או לא עמדנו בקריטריון המבוקש.
עמידה או אי עמידה בקריטריון היציאה תוכל לאפשר לנו להמליץ אם לעבור לשלב הבא או לא. המלצות ומסקנות אלו יועברו לדרג בעלי העניין שממתינים לקבל את התוצאות. (מנהל הפרויקט, הלקוח, אנשי הפיתוח וכו').
כללים לקביעת קריטריון יציאה:
- הבטחה שהעיקרון ישים וברור לכולם.
- יש להגדיר את הקריטריונים לפני תחילת הפרויקט.
- לכל הפריטים יש קריטריוני יציאה דומים.
- אין "הנחות" או הקלות על אי עמידה בקריטריונים לאחר שהוגדרו.
קריטריונים אפשריים שיכולים לשמש אותנו להחלטה מתי ניתן להפסיק:
- כל הבדיקות המתוכננות בוצעו.
- הושגה רמת הכיסוי המבוקשת (כיסוי של קוד, סיפורי משתמש וכו')
- מספר התקלות הלא פתורות נמצא בתחום ידוע מראש.
- רמות מאפייני האיכות מספקים (היבטים כמו: אמינות, ביצועים, שימושיות, אבטחה ונושאים אחרים)
- מספר התקלות שנשאר בתוכנה נמוך.
- רמת חומרת התקלות שנותרה מאחור היא נמוכה ולא מהווה סיכון.
חשוב לציין שגם בלי שקריטריון היציאה מושג, במקרים מסוימים הבדיקות מסתיימות לפני שהגיעו לסיום מאחר והסתיים התקציב, אזל הזמן שהוקצה לסבב הבדיקות או שקיים לחץ להוציא את המוצר לשוק מצידם של אנשי המוצר. הפסקת הבדיקות בתנאים שכאלו יכולה להילקח בחשבון בתנאי שהסיכון בשחרור המוצר ללא בדיקות נוספות מוצג לבעלי העניין וקיימת הסכמה מצידם להמשיך.
בסופו של יום תמיד יתקיים המתח בין אנשי המוצר שמבקשים להרוויח זמן כאשר מה שמניע אותם הוא : Time to the market
מול אנשי הבדיקות שמבקשים יותר זמן בכדי להבטיח יותר איכות.
דוגמא ממשית לקריטריון יציאה:
להלן הגדרת הקריטריונים לאישור העברת המערכת לייצור, ברמת אחוז התקלות
מסך הבדיקות שבוצעו:
להלן הגדרת הקריטריונים לאישור העברת המערכת לייצור, ברמת הבדיקות:
מחוץ להגדרה של קריטריוני יציאה עבור הפרויקט, ניתן להגדיר גם קריטריוני יציאה לכל פעילות שמתבצעת כחלק מתהליך הבדיקות, להלן סקירה של כמה דוגמאות:
קריטריוני יציאה אפשריים עבור משימת פיתוח שמטרתה לכתוב קוד עבור התכונה או סיפור משתמש שיש לפתח יכולים לכלול:
- יש לכתוב קוד שמכסה את כל דרישות הלקוח
- הקוד חייב לעמוד בסטנדרטים מקצועיים (הערות מצורפות למשל)
- כל יחידת קוד עברה בדיקות קופסה לבנה (הצהרה או החלטה למשל)
- כל קוד שנכתב נבדק על יד חבר צוות נוסף בסקירת עמיתים (Peer Review)
קריטריוני יציאה אפשריים עבור פגישות עבודה או סקירות:
- הפגישה הסתיימה לאחר שלא נותרו נושאים פתוחים מאחור.
- הפגישה מתועדת בפרוטוקול מסודר על ידי אחד מהמשתתפים (סוקרים).
- ההחלטות שהתקבלו בפגישה עובדו מחדש (Rework) והתקיים מעקב (Follow Up) שנועד לוודא שהשינויים מומשו.
קריטריוני יציאה אפשריים עבור סבב בדיקות או ספרינט:
- כל סיפורי המשתמש בבקלוג נכתבו והושלמו.
- לא קיימות תקלות קריטיות לאחר הרצת הבדיקות.
- בדיקות רגרסיה של פיתוחים מסבבים קודמים בוצעו ועברו בהצלחה.
- אוטומציה של רגרסיה מפיתוחים קודמים הורצה ללא תקלות מיוחדות.
קריטריוני יציאה אפשריים עבור סיפורי משתמש:
- כל הבדיקות נכתבו ותועדו במערכת ניהול הבדיקות.
- כל הבדיקות עברו סקירה על ידי חברי הצוות שמסרו משוב לגביהם.
- הבדיקות הורצו ותקלות שנפתחו מקושרים לכל סיפור משתמש בנפרד.
קריטריוני יציאה אפשריים עבור בניית תשתית אוטומציה:
- אובחנו ונבחרו מקרי בדיקה שיהפכו להיות אוטומטיים.
- קוד האוטומציה נכתב עבור כל בדיקה והושלם.
- סקריפטים שנוצרו מתוספים לחבילת הבדיקות המלאה עם תגים רלוונטיים.
- הבדיקות הורצו לפחות פעם אחת במהלך הפרויקט.
חשוב לציין שאין רשימה אידיאלית של קריטריוני יציאה שמתאימה לכל צוות, כלומר כל אחד שאחראי על הבדיקות יכול להחליט על קריטריוני יציאה בהתבסס על הצוות והקשר הבדיקות, ניתן כמובן להקל או להחמיר עימם בהתאם למהות המוצר ולפי הסכמות עם הלקוח ומנהל המוצר.
עובדה זאת עולה בקנה אחד עם אחד מעקרונות הבדיקה שמדבר על כך שבדיקות הן תמיד תלויות הקשר. כלומר קריטריוני יציאה של אתר תדמית לא יהיו זהים לאפליקציית ניווט או תוכנת ניהול מערכת מדיקל וכיוצא בזאת.
נקודה נוספת שמבליטה את חשיבותו של קריטריון היציאה היא שהוא משפיע גם על בקרת הבדיקות שכוללת פעולה של תיקון כתוצאה ממידע ומדדים שנאספים ומדווחים תוך כדי הפרויקט והם עלולות להשפיע על כלל פעילויות הבדיקה ואף על פעילויות הפיתוח.
מדדים שנוגעים בהתקדמות העבודה מול לוחות הזמנים כמו:
- אחוז הבדיקות שהורצו מול הבדיקות שנכתבו
- אחוז העבודה שבוצעה ביחס להכנת סביבת הבדיקות
- מקרי הבדיקה שעברו בהצלחה מול אלו שנכשלו
- עלות הבדיקות ביחס להשוואה של עלות מול תועלת התקלות שנמצאו
כל אלו הם פרמטרים ואינדיקציות שנועדו לאפשר לנו להבין איפה אנו עומדים ביחס לקריטריוני היציאה שנקבעו מראש וכך להבין אם אנחנו עומדים ביעדי הבדיקות או שלא.
לסיכום
קריטריוני כניסה ויציאה הם אמות מידה חשובות בניהול פרויקט איכותי.
ללא הבנה מה מבחינתנו ייחשב לתחילת ההנעה של הפרויקט ומה הם התנאים שיוכלו להוכיח לנו שאנו עומדים בהצלחה ויכולים להכריז על המשך לשלב הבא לא נוכל לצאת לדרך.
בדרך לשם נזכור שכללי הברזל יהיו:
- הגדרה מראש של הקריטריונים
- מעקב ובקרה צמודים לאורך הפרויקט אם אנו עומדים בקריטריונים שנקבעו מראש.
- אימוץ פעולות, שינויים והתאמות לאורך התהליך בכדי לעמוד בקריטריונים.
- חזרה אל אותם קריטריונים בשלב סיכום הפעילות ופעולות סיום הפרויקט כמו דוח סיכום הבדיקות (STR).
יש נושאים ומושגים נוספים שהייתם רוצים לקרוא עליהם? תשלחו מייל ואשמח לכתובkobi757@gmail.com
