#51 זכור את אשר עשה לך הבודק

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

והמהנדס החכם אומר: "כל הבודק במוּמוֹ בודק"

[ותודה ל ג.ע. על הפידבק שהתחיל את הפוסט]

---

מתחת לקו: אני משוכנע שאי-אלו מן הקוראים העוסקים בתחום הבדיקות ודאי נעלבו מההשוואה של ה"בודק" לעמלק. על כך יש לי לומר שלושה דברים:

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

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

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