האנציקלופדיה לבדיקות | קובי יונסי

הגדרה של סיכון

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

בעולם הבדיקות ניתן לחלק את הסיכונים שעלולים להשפיע על צוות הבדיקות, ל-2 סוגים:

1.       סיכוני מוצר

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

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

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

דוגמאות לסיכוני מוצר:

·          ארכיטקטורה שגויה של מערכת.

·          משוב חווית משתמש (UX) שאינו מתאים לציפיות מהמוצר.

·          קוד של לולאת בקרה שאינו כתוב כראוי.

·          זמני תגובה איטיים המעידים על קוד מסורבל (קוד ספגטי).

·          קוד שמוביל לזליגות זיכרון.

·          תוכנה שאינה מממשת את הפונקציונליות המצופה ממנה.

2.       סיכוני פרויקט

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

לדוגמא,

·          עיכובים  בהשלמת מטלות או השגת קריטריון יציאה לפני מסירת המוצר לשלב הבא.

·          חיכוכים בין מחלקות או חברי צוות שגורמים לעיכובים במסירה.

·          דרישות עמומות שמעכבות את הפיתוח ואת הבדיקות.

·          חוסרים בנוהל טיפול תקלות  שעלולים ליצור צווארי בקבוק בניהול המעקב והטיפול בתקלות.

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

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

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

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

כיצד מתמודדים עם סיכונים?

בתחילה נבין שהסיכון מאפשר לנו לתעדף המאמץ הנדרש בבדיקות.

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

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

טבלת ניהול סיכונים

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

לכל סיכון ניתן רמת סבירות (פוטנציאל) להתממשות על סמך היסטוריה שלנו מפרוייקטים קודמים או נתונים אחרים שמובאים לשולחן. קריטריון זה הוא בין: 0-100 אחוז.

קריטריון שני יכלול את רמת הנזק (Damage) שהסיכון עלול לייצר באם יתרחש.

קריטריון זה יכול לנוע בסקאלה של 1-5 או 1-10 או 1-100.

רמת החומרה של הסיכון: (Severity)  תהיה מכפלת הסבירות * נזק

וזאת בעצם הנוסחה שתאפשר לנו להבין מה רמת הסיכון מכל אירוע שעלול להתרחש:

Severity = Likelihood * Impact

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

את תוכנית המגירה נממש כאשר נזהה בפעולות מוניטור שהאיום מתממש.

דוגמא לטבלת ניהול סיכונים:

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

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

כיצד התמודדנו עם הסיכון?

·          האם הערכנו אותו באופן מדויק?

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

·          מה הסבירות שהסיכון יופיע בפרויקטים אחרים?

·          האם נפעל באותה צורה בעתיד?

·          האם נשאיר את האחריות לגורם המטפל בפרויקט הבא?

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

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

בדיקות מבוססות סיכונים (Risk Based Testing)

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

בדיקות מבוססות סיכונים מיועדות ל:

·          ניתוח והערכה יומית של איומים שיכולים לסכן לנו את הפרויקט.

·          החלטה באילו סיכונים נרצה לטפל ואילו סיכונים נוכל לדחות.

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

·          הכנת תוכניות מגירה לטיפול בסיכונים באם הם מתממשים.

 ניהול סיכונים מבוסס על תרבות של תכנון.

כפי ששמעתי מד"ר צבי ברק (מומחה לניהול ומדעי ההתנהגות) שאמר:

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

 לסיכום

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

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

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