בחן את עצמך | ירון צוברי

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

אני, למען האמת, לא זוכר במדוייק את התקלה הראשונה שדיווחתי, אבל אני כן זוכר שהיא הייתה על מסך של VAX400, אם אני לא טועה… יותר מ-30 שנה… לך תזכור... זו הייתה טעות בחישוב שהובילה למסך אפור… בדיוק אחרי שהחלפנו את המסכים מירוק לאפור.

אני זוכר מספר דיווחי תקלות (שהפילו אותי לרצפה) ושיצא לי להיתקל בהן בראשית דרכי כמו: "הרולס-רויס שלי לא עובד!" – הכוונה הייתה לקורא השיקים שמריץ את השיקים ומבצע קריאה לפס המגנטי (או האופטי) שעל גבי המסמך; "המדחום שלי תקוע...!" – תוכנה להפקת דוח סטטיסטי השתמשה בתצוגה של התקדמות התקנה (מכירים? בכל פעם שאתם מתקינים תוכנה ישנו פס הבנוי ריבועים וככל שההתקנה מתקדמת, נוספים יותר ריבועים), רק במקום שתצוגת ההתקדמות תהיה אופקית, היא הייתה גם אופקית וגם אנכית (אכן נראה כמו מדחום דיגיטלי...). האם המפתחים אצלכם היו מקבלים היום דיווחי תקלות כאלו?

בודקים אחראים לאשר שהתוכנה שנבדקת אכן עובדת, אבל לא הכל עובד כצפוי. יותר נכון לומר, לרוב התוכנה לא עובדת כצפוי והבודקים - שלעיתים נתפסים כאחראים לאיכות התוכנה - נדרשים לדווח על הפגמים (defects, bugs) שמצאו בתוכנה באמצעות דוח פגמים (defect report). לכן, מאחר ואחת המטרות של בדיקות היא למצוא פגמים, יש לתעד פגמים שנמצאו במהלך הבדיקות. הדרך בה יתועדו הפגמים עשויה להשתנות בהתאם להקשר לרכיב או למערכת הנבדקת, לרמת הבדיקה ולמחזור חיי התוכנה. תיעוד ומעקב אחרי פגמים עשוי להיות מאוד לא פורמלי. בעיקר כיוון שניתן לדווח על פגמים בשלבים שונים של מהלך חיי הפיתוח, למשל, במהלך כתיבת הקוד, ניתוח סטטי, סקירות, במהלך בדיקות דינמיות או שימוש במוצר תוכנה. ניתן לדווח על פגמים בקוד או במערכות עובדות, או בכל סוג של מסמך, כולל דרישות, סיפורי משתמש וקריטריון קבלה, מסמכי פיתוח, מסמכי בדיקה, מדריכי משתמש או מדריכי התקנה.

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

(לשם הבהרה חשוב לציין שאני בוחר להשתמש במושג פגם, כמו שמופיע בסילבוס בעברית, למילה שבשפת היומיום אנחנו קוראים "באג" מאחר וה"באג" אותו אנו מוצאים בזמן הבדיקות הוא למעשה ה"כשל"). (למידע נוסף, מומלץ לקרוא את פרק 5 תת-פרק 5.6.1 של תוכנית ההכשרה הבסיסית של ארגון ISTQB).

ועכשיו לשאלה (כתובה בלשון זכר, אך מתייחסת לכל המינים):

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

איזה מהבאים מהווה סיכום (summary) טוב לדוח פגמים (defect report) עבור כשל זה, כזה שתופס הן את מהות הכשל והן את השפעתו על בעלי העניין (stakeholders)?

א) יומני שרת אינטרנט מציגים שגיאה 0x44AB27 בעת הפעלת בדיקה 07.005, שאינה הודעת שגיאה צפויה במערכת הקבצים /tmp

ב) מפתחים הציגו פגם גדול בזמינות שיעצבן את הלקוחות שלנו

ג) הביצועים איטיים והאמינות מתקלקלת תחת עומס

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

בחר אפשרות אחת

הפתרון לשאלה

נתחיל עם יעד הלימוד (Learning Objective) ורמת הידע (Knowledge Level) הדרושים לנושא הזה. לידיעה כללית: את יעדי הלימוד ניתן לרוב למצוא בעמוד הפתיחה של כל פרק בתוכנית הלימוד (הסילבוס). לכל יעד לימוד מוגדרת רמת הידע הדרושה לו (K-level – Knowledge Level). המודל המייצג לרמות הידע שארגון ISTQB משתמש בו הוא מודל הטקסונומיה של בלום (Bloom's taxonomy).

יעד הלימוד הרלוונטי לשאלה שלנו כאן הוא: FL-5.6.1 - "כתוב דו"ח פגמים שמכסה פגם שנמצא במהלך הבדיקות"; והשאלה שלנו היא ברמה של K3. רמה זו אומרת שעל הנבחן להצביע על התשובה הנכונה מקום ויכולת של יישום ו/או שימוש של הנושא המסוים (או הנלמד במידה וניגש לבחינה לאחר הכשרה).

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

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

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

·         לספק רעיונות לשיפור תהליכי פיתוח ובדיקות.

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

·         מזהה

·         כותרת/סיכום (Summary) ותיאור תמציתי קצר של הפגם המדווח

·         תאריך הדיווח, הארגון שמדווח ומחבר הדוח

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

·         שלב מחזור חיי הפיתוח שבו התגלה הפגם

·         וכו'

(למידע נוסף, מומלץ לקרוא את פרק 5 תת-פרק 5.6.1 של תוכנית ההכשרה הבסיסית של ארגון).

הבה נבחן את השאלה והתשובות:

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

נסתכל עתה על התשובות השונות וננתח האם הן נכונות או לא, ומדוע לא:

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

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

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

ד) התשובה נכונה. סיכום זה נותן תחושה טובה של הבנת הכשל ומידת השפעתו.

אם תרצו שאציג שאלת דוגמה בנושא מסוים או אם יש לכם שאלות אנא פנו אלי באימייל: [email protected]