פרק #30 סיכוני מוצר וסיכוני פרויקט בואו לשמוע את קובי יונסי מרצה מוביל בתחום הבדיקות מציג את ההבדלים בין סיכוני מוצר לסיכוני פרויקט על פי הסמכת ISTQB. בפרק הפעם נשוחח על סיכוני מוצר וסיכוני פרויקט אשר נמצאים בפרק מס 5 בסילבוס של ISTQB. סיכוני פרויקט ומוצר בבדיקות תוכנה מתייחסים לאיומים פוטנציאליים שעלולים לפגוע בהצלחת הפרויקט או באיכות המוצר הסופי. סיכוני פרויקט כוללים גורמים כמו עיכובים בלוחות זמנים, חריגות בתקציב, חוסר במשאבים או בכוח אדם, בעיות תקשורת בין צוותי הפיתוח והבדיקות, ושינויים בלתי צפויים בדרישות הלקוח. סיכוני מוצר מתמקדים באיומים על איכות התוכנה עצמה, כמו באגים חמורים, בעיות ביצועים, כשלים באבטחת מידע, חוסר תאימות למפרטים או לדרישות המשתמשים, ותקלות בשימושיות. זיהוי וניהול נכון של סיכונים אלו חיוני להבטחת הצלחת הפרויקט וסיפוק מוצר איכותי ואמין.בפודקאסט אשוחח בפירוט על כל אחד מהסיכונים ואציג אלטרנטיבות לטיפול בהם.
תאריך עליית הפרק לאוויר: 15/07/2024.
[מוזיקת פתיחה]
קובי: שלום לכולם, והיום אתם שוב איתי, קובי יונסי, מרצה מהאקדמיה ומהתעשייה למקצוע בדיקות התוכנה.
היום אנחנו הולכים לדבר על הנושא של סיכוני מוצר וסיכוני פרויקט. חלוקת הסיכונים לשני חלקים, או לשני אזורים, הכרחית, כיוון שהסיכונים נוגעים בנושאים שונים.
כשאנו יוצאים לדרך בפרויקט בדיקות, אנחנו מבינים שיש פה איזשהו קונסטלציה של משימות ויעדים שתלויות בהרבה מאוד משאבים, אם זה מבחינת כוח אדם, כסף, זמן, הרבה מאוד אנרגיה שמושקעת מבעלי העניין. בעלי העניין זה הלקוח, צוות הבדיקות, צוות הפיתוח, ושחקנים נוספים שנרתמים למהלך במהלך הדרך. זה יכול להיות אנשי הדאטה, אנשי הסיסטם, וכמובן, בעלי תפקידים נוספים מבית התוכנה ומחוצה לה.
סיכוני מוצר אלה סיכונים שכוללים את האפשרות שתוצר, זה יכול להיות מפרט, רכיב, מערכת, או אפילו בדיקה, יכשלו לענות על הצרכים הלגיטימיים של המשתמשים או בעלי העניין שלהם. כאשר סיכוני המוצר קשורים בעצם עם מאפייני איכות מאוד מסוימים של המוצר. למשל, התאמה פונקציונלית לדרישות הלקוח, יעילות ביצועים, שימושיות, user experience, אבטחה, תאימות, תחזוקתיות וניידות, אם אנחנו מדברים למשל, על מוצר מעולם המובייל.
סיכוני מוצר נקראים בעצם סיכוני איכות. יכולים לכלול הרבה מאוד דוגמאות, למשל, תוכנה שלא מבצעת את הפונקציונליות המצופה ממנה. כלומר, היא לא עומדת לפי התקנים של המפרט הטכני, שהוגשו מבעוד מועד על ידי מנתח המערכות.
יכול מאוד להיות שהארכיטקטורה של המערכת לא תתמוך בצורה נאותה בדרישות פונקציונליות או לא פונקציונליות, יכול להיות שמדובר על חישוב מסוים שלא נעשה בצורה נכונה, איזשהו קוד שכתוב לא נכון, למשל, איזושהי לולאת קוד שהיא אינסופית, כלומר, לא מסוגלת להתממש, וכתובה בצורה לא נכונה, יכולים להיות פה גם זמני תגובה שלא מוצאים… מתאימים למערכת מבחינת ביצועים. המערכת איטית מדי, או יכול להיות שמדובר על איזשהו חוויית משתמש שקיבל… קיבלנו מהלקוח כפידבק שהדברים לא עונים לציפיות שהוא מצפה מהמוצר.
אלו יכולים להיות, למשל, סיכוני מוצר שיכולים להשפיע על הנושא של העבודה עם המערכת, ואנחנו צריכים להעריך אותם, ולהתייחס אליהם לפני שאנחנו מחליטים אם אנחנו משחררים את המערכת לטובת הלקוח כ-release. זאת אומרת, נותנים את האישור ל-go בסוף התהליך.
במקביל לסיכוני מוצר, ב-ISTQB מדברים גם על סיכוני פרויקט. סיכוני פרויקט אלה הסיכונים שהם בעצם מובילים אותנו בדרך למוצר, בדרך לתהליך של בדיקות הפרויקט שבו אנו עוסקים. בסופו של יום אנו אחראים לשקף את מצב איכות המערכת, וכשאנחנו יוצאים לפרויקט, אנחנו יודעים איך אנחנו יוצאים, אך אנחנו לא יכולים לדעת איך הוא יסתיים. באופן טבעי, יש במציאות כל מיני אילוצים, משתנים, נגזרות שיכולים להשפיע על טיב הפרויקט, על הקצב שלו, ועל איכות התוצרים שאנחנו מצפים להציג.
איזה בעיות פרויקט אנחנו יכולים לזהות? אז עיכובים למשל, שעשויים להתרחש במסירה. השלמת מטלות או השגת קריטריון יציאה, או הגדרת נקודת סיום, שהם לא מדויקים או לא מציאותיים. יכול להיות שיש לנו אומדנים לא מדויקים, מבחינת ראש הצוות או מנהל ה-QA, שיצא לדרך עם הגדרת חסר, מבחינת כוח אדם, משאבים, כסף ודברים נוספים, או ייתכן שהוא עם הערכה שהיא הערכת יתר.
יכולות להיות גם נושא של שינויים מאוחרים, שפשוט הלקוח מבקש כל מיני פיצ'רים או עדכונים, סמוך לשלב סיום הפרויקט, מה שבעצם גורם לכמות משמעותית של עבודה נוספת, שמשפיעה על הפרויקט וגורמת לפרויקט להידחות.
יכולים להיות גם בעיות שקשורות בארגון עצמו, כלומר, בבית התוכנה. למשל, חוסר הדרכה של כוח אדם, או גיוס של אנשים שהם יחסית ג'וניורים, חסרי רקע. באופן טבעי, כשזה קורה, אנחנו ניכנס למצב של עיכוב במסירה.
במקביל, יכולות להיות גם בעיות שקשורות בנושא הטכני. למשל, הדרישות לא מוגדרות בצורה מספקת. האנליסט התרשל ולא הסביר במדויק למה התכוון, או שחלק מהדברים שהוא מדבר עליהם, הם בחזקת פערי אפיון, כלומר, לא ברור בדיוק, בנסיבות כאלה ואחרות, איך המערכת אמורה לתפקד. יכול מאוד להיות גם שהדרישות הן לא מציאותיות ולא ניתנות להשגה.
יכול להיות ברמת סביבת הבדיקות שאנחנו לא הכנו אותה בזמן, בין אם זה אנחנו אחראים על הנושא, או שחקנים אחרים בחברה עצמה, שלא ארגנו לנו את סביבת הבדיקות, את ה-Testing Environment, בזמן, כדי שנצא לבדיקות ולהרצה, כשאנו מוכנים עם התסריטי בדיקות שלנו.
יש עניין גם של המרת נתונים לעתים קרובות, או הסבת נתונים ממערכות ישנות, מה שנקרא בשם מערכות Legacy, ואם זה לא קורה בזמן, זה גם סוג של סיכון פרויקטלי, שיגרום כמובן בהכרח לדחייה בפרויקט.
נושאים נוספים יכולים להיות גם, ניהול לא נכון של תקלות במערכת היחסים, או בתקשורת בין המפתחים לבודקים, ובעיות של ספקים שמצטרפים אלינו כשחקנים חיצוניים, אך המוצרים שעליהם לספק, קשורים באופן ישיר להתקדמות הפרויקט. למשל, ספק שנותן לנו בדיקות עומסים, או בית תוכנה שמספק לנו תוכנה לניהול מעקב או לניהול תקלות, ואנחנו מקבלים את המוצר באיחור. המשמעות כמובן, שכל הפרויקט יתעכב, ואנחנו נגיע למסירה, גם כן באיחור, ומפה יש לנו סיכון פרויקטלי ממדרגה ראשונה.
סיכוני פרויקט עשויים להשפיע על פעילויות הפיתוח ועל פעילויות הבדיקה, וברוב המקרים אנחנו נראה, בהרבה מאוד מקרים, שמי שאמור לנהל את זה זה מנהל הפרויקט או מנהל ה-QA. מנהל ה-QA מתייחס לסיכונים בדרך כלל במסמך תכנון הבדיקות, כאשר הוא מכניס אותם לאזור שנקרא ניהול סיכונים, שמורכב מטבלה, ובתוך הטבלה שלוש פרמטרים.
הפרמטר הראשון יהיה פוטנציאל הסבירות להתממשות סיכון. פוטנציאל בדרך כלל באחוזים זה בין 0 ל-100 אחוז. את הפוטנציאל ניתן לקבוע לפי ניסיון מגרסאות קודמות, או ניסיון מהעבר בפרויקטים דומים, או פשוט לפי תחושה או אינטואיציה של אותו מנהל.
הנושא הנוסף הוא רמת הנזק, שהאירוע יכול לגרום לנו לצוות או לפרויקט עצמו. את זה אנחנו נמדוד ביחס של בין 1 ל-10 או 1 ל-5, ובסופו של יום שני הפרמטרים, הסתברות כפול רמת נזק, באנגלית פוטנציאל כפול damage, יובילו למשתנה השלישי, שהוא תוצאת החישוב, למשתנה זה אנחנו נקרא בשם severity, רמת חומרה. מאוד מזכיר את רמת החומרה שאנחנו מכירים מניהול של באג, רק שברמת החומרה הזאת אנחנו מתייחסים לרמת החומרה מהאיום, ומול כל הדברים האלו אנחנו נצטרך לייצג דמות מפתח או מספר אנשים, שעליהם ניתנת האחריות לטפל באירוע. זה יכול להיות כפעילות מנע, פעילות מונעת כדי שלא נכנס לאירוע, וזה יכול להיות מצב שבו כשהאירוע יפגע בנו, הם יהיו אלו שיצטרכו לפעול ולמגר את האירוע או לצמצם את רמת הנזק, ברגע שהיא כבר קרתה.
אנחנו בדרך כלל מתייחסים לניהול סיכונים ככלי ניהולי, שנוכל להשתמש בו בסוף תהליך, ולאחר שנסיים את הפרויקט, נחזור ונבדוק מה בעצם קרה. שם נוכל לזהות אם האירוע פגש אותנו במציאות או לא. במידה וכן, איך פעלו האנשים שהטלנו עליהם את האחריות.
דוגמה למשל לסיכונים שיכולים להיות, אז יכול להיות שיש לנו סיכון של נפילת רשת שחווינו בפרויקטים דומים. לצורך העניין, נוכל להחליט אם אנחנו רוצים לצמצם את הנזק במידה והוא יקרה, למשל, להוסיף למעבדת הבדיקות איש סיסטם IT, שיטפל בזמן אמת בנפילת הרשת. אפשרות אחרת זה להימנע מלהיכנס לאירוע, על ידי בחירת ספק רשת אחר, שמאליו לא יכניס אותנו לרמת הסיכון, שחווינו עם ספק אחר שאיתו השתמשנו בעבר.
סיכון נוסף יכול להיות סיכון של פרויקט צעיר, שגייסנו אליו אנשים ללא ניסיון. יצא לי לא מעט מקרים לעשות זאת בחברות שבהם התגייסו בודקי תוכנה לטובת פרויקט מסוים, והחבר'ה הגיעו ללא רקע או ניסיון בתחום הספציפי שאותו עליהם לבדוק. מה שאפשר לעשות במצב כזה, זה למשל, להשים מנטור שילווה את החבר'ה הצעירים במהלך הפרויקט, משהו שיכול בהחלט לצמצם את רמת הסיכון. אפשרות שנייה תהיה להביא מדריך, שייתן להם יישור קו מקצועי מספר ימים לפני תחילת הפרויקט, כך שהם יגיעו לפרויקט כשהם יודעים פחות או יותר איך להתנהל, איך המערכת אמורה לעבוד, ומתוך העניין גם איך לבדוק את המערכת.
בסופו של דבר, כשאנחנו יוצאים לדרך, אנחנו יודעים פחות או יותר איך זה הולך לקרות, או אנחנו יודעים לצפות למה אנחנו רוצים, עם מה אנחנו הולכים להתמודד, אבל אף פעם לא נוכל באמת לדעת, כי בחיים, כמו בחיים, יש לנו הפתעות, והרעיון המרכזי של ניהול הסיכונים, הוא לנסות להערך עם תוכניות מגירה, כדי שבזמן האירוע, במידה והוא פגש אותנו, לא נהיה מנוהלים על ידי האירוע, אלא בעצם ננהל את האירוע. וזה בעצם הרעיון הגדול של סיכונים ובדיקות.
אחרי שהבנו את המשמעות של סיכון וכמה חשוב להתנהל מולו, בעצם הסיכונים הובילו לבדיקות, או לטכניקת בדיקות, שנקראת בדיקות מבוססות סיכונים ואיכות מוצר.
בתהליך כזה, אנחנו משתמשים בסיכון ככלי לאפשר לנו למקד את המאמץ הנדרש במהלך הבדיקות, אנחנו משתמשים בסיכון כדי לנסות בעצם להבין איך אנחנו מזהים אזורים, שמצריכים מאיתנו יותר תשומת לב, אזורים שאולי נתחיל שם בבדיקות, ניתן להם את התעדוף הנכון, כשהמטרה שלנו היא בעצם לצמצם את הסיכונים ככל שאפשר בשלבים מוקדמים.
בגישה מבוססת סיכונים, התוצאות של ניתוח סיכוני מוצר, אחרי שכמובן ישבנו וחקרנו והבנו מה עלול לפגוע בנו, יאפשרו לנו להחליט על השימוש בטכניקות בדיקה, להחליט על רמות בדיקה וסוגי בדיקה מיוחדים שיש לבצע, למשל, אולי אנחנו צריכים להעמיק בבדיקות אבטחה, או אולי בבדיקות נגישות, עומסים, אולי ביצועים. זה יכול לעזור לנו לקבל החלטה נכונה על היקף הבדיקות שיש לבצע.
יכול להיות שלא נרצה לבדוק את כל הדברים, את כל המצבים, כי פשוט אין לנו זמן ואנחנו רוצים לחסוך אותו על אזורים שהם יותר מורכבים. ויכול מאוד להיות שאנחנו נעשה בגישה הזאת, נשתמש בגישה, כדי כמובן לתעדף את הדברים, בראייה או בכוונה, לאתר קודם כל את הפגמים הקריטיים ככל האפשר, בשלב מוקדם, כך שיהיה קל לתקן, וכמובן, עלות התיקון תהיה קטנה. מתחבר לעקרון הבדיקות שאומר, Early Testing, תבדוק את המוצר מוקדם ככל האפשר. וזה גם מוביל למאמר אחר שנכתב במגזין הבדיקות, שדיבר על shift-left, להעביר ככל שאפשר, את הבודקים, לשלבים ראשוניים של המוצר, כדי לחסוך בעלויות.
בדיקות מבוססות סיכונים, מתבססות גם על הידע שמצטבר אצל הצוות הניהולי, בבדיקות בקבוצה, זה יכול להיות ראש הצוות או מנהל ה-QA, ודרך תובנות שלמדנו מפרויקטים וממערכות אחרות שנבדקו, על ידי הצוות.
זה מאפשר להחליט טוב יותר באיזה סיכונים נטפל, ליישם כל מיני פעולות שמטרתם להקטין את הסיכון, וכמובן להצטייד בתוכניות שמטרתם לתת מענה אמיתי בזמן אמת, לאירועים שיכולים לפגוש אותנו תוך כדי תנועה.
מן הסתם יכול גם לקרות מצב שתוך כדי הבדיקות, נגלה סיכונים חדשים, וזה יכול לעזור לנו לקבל החלטות באיזה סיכונים נרצה, באיזה סיכונים נרצה לטפל קודם, איך נוכל להקטין אותם, ואיך נוכל, בגדול, וזה בעצם הראייה הכללית על הנושא של סיכונים, להפחית את חוסר הוודאות לגבי אירועים שעלולים לפגוש אותנו או שפוגשים אותנו בהווה, בזמן הפרויקט.
אני מאוד מקווה שלמדתם והבנתם את הרעיון, ואני מאחל לכם שניפגש בפרקים נוספים עם עוד טיפים, ידע, הכוונה, ולימוד מצטבר על מקצוע נפלא שנקרא מקצוע הבדיקות.
ניפגש בהמשך, תודה על ההקשבה, אני הייתי קובי, אתם שמעתם זה עתה עוד פרק של TestIL מבית ITCB, העמותה לקידום מקצוע הבדיקות בישראל.
תודה ולהתראות.
[מוזיקת סיום]
לעוד פרקים של הפודקאסט לחצו על שם הפודקאסט למטה
Comments