מחפש צרות | מיכאל שטאל

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

בגיליון 35 של המגזין התפרסם מאמר מעניין של משי מוטולה על הפסיכולוגיה של הבדיקות. המיקוד במאמר היה על היחסים והדרכים לתקשורת קונסטרוקטיבית בין בודקים למפתחים. במידה רבה זה גם המיקוד של הסעיף העוסק בנושא זה בסילבוס הבסיס של ISTQB. (הערה:  הסעיף הזה "ירד במיקוד"... הוא היה קיים בוורסיה 3.1 של הסילבוס אבל קוצץ לטובת נושאים אחרים בוורסיה 4.0 ששוחררה בשנת 2023).

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

מה המטרה?

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

 (Testing Computer Software (Kaner, Nugyen, Falk מתואר הניסוי הבא (הציטוט בהשמטות): "צפו במסך מכ"ם וחפשו בליפּ מסוים. דווחו על הבליפּ בכל פעם שאתם רואים אותו [...] אם אתם מצפים לראות בליפּים רבים, או אם תקבלו פרס גדול על דיווח על בליפּים כשאתם רואים אותם, אתם תראו ותדווחו עליהם יותר - כולל בליפּים שלא היו שם כלל ("אזעקות שווא"). אם אתם מאמינים שלא יהיו הרבה בליפּים, או אם תענשו על אזעקות שווא, תפספסו בליפּים שאכן הופיעו על המסך ("פספוסים")". נדרשו לפסיכולוגים ניסיוניים כ-80 שנות ניסיון מר כדי להפסיק להאשים את נבדקי הניסוי בטעויות בניסויים מסוג זה ולהבין שלגישה ולהגדרת הניסוי [...] הייתה השפעה גדולה על הפרופורציות של אזעקות שווא והחמצות."

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

באחד הספרים הראשונים שנכתבו על המקצוע (The Art of Software Testing, Glenford Meyers, 1979), המחבר  מסביר שאם אתם חושבים שהמשימה שלכם היא למצוא בעיות, אתם תחפשו אותן יותר מאשר אם אתם חושבים שהמשימה שלכם היא לוודא שאין בעיות. הוא מציע את ההגדרה הבאה:  "בדיקות הוא תהליך של הרצת תוכנה מתוך מטרה למצוא בה טעויות".

כבודקים וכמנהלי בדיקות, אם נגדיר שזו המטרה, נהיה כנראה יותר אפקטיביים במציאת באגים.

ידע וציפיות משפיעים על פירוש התוצאות

כחלק מצוות הפיתוח, אנחנו יודעים די הרבה על ה"בפנוכו" של המוצר. רוב הסיכויים שיש לנו מושג על הארכיטקטורה, על איך יכולות מומשו, וגם הבנה למה יש למוצר מגבלות מסוימות. הידע הזה מונע מאיתנו לעיתים לזהות באגים. סיפור לדוגמה: לפני שנים רבות הייתי חבר בצוות שבדק דרייברים של כרטיסי Wi-Fi. יום אחד קיבלנו גרסה חדשה, ובדיקה מסוימת שבעבר עברה בהצלחה, נפלה. היה צורך לדבג את הנפילה על מנת לספק מידע למפתחים. חלק מתהליך הדיבוג היה הקלטה של התעבורה ברשת האלחוטית, שבעזרתה יכולים המפתחים לחפש מה גרם לתקלה. כיוון שבמעבדה פעלו עשרות כרטיסי Wi-Fi ותחנות גישה (access point), היה קשה מאוד לקבל הקלטה נקייה של התעבורה רק עבור המערכת הנבדקת. הפתרון היה כלוב פאראדיי בגודל3X3  מטר שהותקן במעבדה. כלוב זה חוסם כניסת גלים אלקטרומגנטיים, כך שאפשר היה לחבר מערכת שכללה רק כרטיס אחד ונקודת גישה אחת ולבצע הקלטה נקייה של התעבורה. אלא שנוצרה בעיה חדשה... כשהרצנו את הבדיקה בתוך הכלוב, היא עברה! המממ.... מה זה יכול להיות?  המסקנה שלנו הייתה שכיוון שבמעבדה יש מלא משדרים ושליחה של תשדורות רבות, נוצרות התנגשויות בין השידורים, הם מפריעים אחד לשני, ומכאן הכשל (זה אכן יכול לקרות בתשדורות רדיו).

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

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

את הנטייה הזאת, למצוא הסבר כמו-הגיוני לבעיות מסוימות מתוך (כביכול) הבנת המערכת, מסכם יפה דונלד נורמן בספרו The Design of Everyday Things:  "מצאנו הסבר, ואנחנו מבסוטים. [...] ברגע שיש לנו הסבר – נכון או לא – עבור אירועים תמוהים, אין לנו יותר תהיות ואין אי התאמה בין הציפיות והמציאות. כתוצאה מכך, אנו שאננים, לפחות לזמן מה".

ידע משפיע על מה נראה לנו סביר

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

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

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

מקרה כזה הוא פיתוח הריץ'-רץ', כפי שמתואר בספר "חפצים שימושיים"  (The Evolution of Useful Things) של הנרי פטרוסקי: "...וכמו ממציאים קצרי רוח רבים, המיטיבים להכיר את דרכיו של יציר רוחם הבשל, הצליח [הממציא] לגרום שיפעלו באופן מניח את הדעת במעבדה. אבל הלקוחות לא נהגו עדינות רבה כל כך בבן טיפוחיו של הממציא, והשתמשו בו כדרך שהורו להם מודעות הפרסומת [דבר שגרם להופעת בעיות שהמהנדס] לא הצליח לעמוד עליהם, או התעלם מהם בהתלהבותו.".

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

דיסוננס קוגניטיבי והטיית האישוש

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

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

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

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

איך מתמודדים?

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

-          להגדיר את מטרת הבדיקות "למצוא תקלות" ולא "לוודא שהמערכת עובדת".

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

 מול התופעות האחרות אפשר:

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

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

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