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

1. כלים

• אם צריך כלי לניהול אוטומציה; דרישות; באגים; וכו' – פעילות שכל קבוצת פיתוח עושה – כמעט בטוח שלא כדאי לפתח את הכלי בעצמכם. 99% שאתם לא עד כדי כך מיוחדים שאתם חייבים כלי ייחודי. בנוסף, מובטח לכם שבטווח הארוך זה יעלה הרבה יותר מאשר לאמץ כלי קיים שמממש את רוב הצרכים שלכם. אחרי שהחלטתם על כלי: אל תנסו לאלץ את הכלי שבחרתם לעשות דברים שהוא לא תוכנן לעשות. תשנו קצת את התהליכים שלכם כדי שיתאימו לכלי [*].

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

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

2. הצד האפל של אוטומציה

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

• יצירת הפרדה קבוצתית בין מי שכותבים אוטומציה למי שבודקים מייצרת היררכיה לא בריאה בקבוצת בדיקות: כל מי שבקבוצה של הבודקים שואף לעבור לקבוצת האוטומציה, שהיא יותר מעניינת (לא נשחקים ברגרסיות) ויותר דומה לפיתוח קוד (שבהגדרה, ברוב הארגונים, נחשב לקסטה גבוהה יותר מבדיקות). הדבר גורם לבעיות מורליות, עזיבה, וירידה באיכות הבדיקות. הפתרון צריך להיות סוג של ערבוב. למשל: חלוקה הוגנת של עבודת היום-יום (רגרסיות), בניית plug-ins לאוטומציה על ידי כל החברים בקבוצה, מערכת KDT (Keyword driven testing) מלאה המאפשרת כתיבת תסריטים לא טריוויאליים.

3. ניהול (סתם ניהול; ניהול איכות ובדיקות)

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

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

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

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

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

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

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

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

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

אל תנחשו. 

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

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

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

4. כישורי הנדסה

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

צריך להתאמן על מנת להיות כותב טוב, ויש ערך מוסף למהנדסים שכותבים טוב  [*].

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

בקיצור: תשקיעו בלתקתק מהר.

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

• דוחות פגמים (bug reports) הם תעודת הזהות שלכם מול הארגון. זה תוצר העבודה המוחשי ביותר. אף אחד לא ממש מרגיש שהצלחתם להריץ מאה מקרי בדיקה ביום אחד, אם כולם עברו. אבל כל דוח פגמים שלכם נקרא על ידי מספר אנשים: מנהלי הפיתוח, מהנדסים, ולפעמים גם מנהלי הפרויקט. כמינימום הם קוראים את הכותרת של הבאג. מה זה אומר? שכדאי להשקיע בנושא. זה אומר לוודא שהכותרות והפרטים שכתבתם קריאים וברורים (ראה סעיף א' לעייל), ההצעה לחומרה (severity) אכן נכונה ומראה הבנה במוצר. לעשות חיפוש קצר על מנת להימנע מפתיחת דוח נוסף על באג שכבר דווח; לפרט את צעדי השחזור ככה שאפילו אתם תבינו מה התכוונתם כשתקראו אותם בעוד שבועיים; ושהתוצאה הצפויה לעומת התוצאה הנצפית יסבירו היטב למה זה באג.

ככה בונים מוניטין.

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

• אתגר הבדיקות – ברמה של 10,000 רגל, די דומה בארגונים רבים. לכן גם שיטות וטכניקות בדיקה מוכרות הן רלוונטיות להרבה קבוצות פיתוח. זה אומר שחשוב ללמוד בדיקות - ולא רק לסמוך על האינטואיציה, הגיון בריא ו-On the Job training. הרצאות, סרטונים ובלוגים זה יפה, אבל למידה מסודרת ועמוקה של התיאוריה של בדיקות משיגים רק מספרים, כי המדיה הזאת מאפשרת לפתח נושא לרוחב ולעומק. כשזה לא נעשה, יתכן מאוד שתגיעו לפתרונות הנכונים בעצמכם, אבל לאט יותר ואחרי יותר התחלות כושלות. ואין דבר יותר מבאס מאשר להיות גאה ברעיון נהדר שעלה בדעתכם איך לשפר את הבדיקות, רעיון שנראה לכם כפריצת דרך מבחינה מקצועית, ואז לגלות שזו טכניקה שכבר מופיעה בספרות 30 שנה. אם אתם רציניים לגבי התמקצעות בבדיקות – תקראו ספרים! [*].
  
  5. חוקי מרפי

ולסיום, התוספת האישית שלי לסדרת החוקים האלמותית של מר מרפי:  

באגים שלא ניתנים לשחזור ישתחזרו בקלות אצל הלקוחות

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