כתות מטען הן תופעה שצצה במלנזיה בעקבות מלחמת העולם השנייה. התושבים הילידים ראו את האדם המערבי מגיע, בונה שדות תעופה, משרדים, מגדלי פיקוח ומסלולי נחיתה ובעקבות זאת מצליח לגרום לאלים (או לרוחות האבות) לשלוח לו אוכל, נשק ומשאבים נוספים. כשהחיילים עזבו, הילידים ניסו לחקות את מה שראו כדי לגרום לחלק מכל השפע הזה להגיע גם אליהם. היה חסר להם רק חלק קטן אחד - האנשים בצד השני של הטיסה שבנו את המטוס ומילאו אותו בכל הציוד הנדרש. מאז שהביטוי הזה נטבע הוא משמש כדי לתאר מקרים בהם מישהו מחקה את הצורה אבל מחמיץ לחלוטין את המהות של מעשה מסויים.
ואיך כל זה קשור לבדיקות תוכנה? ובכן, מדי פעם אפשר למצוא באינטרנט (ובמקומות אחרים) הרצאות עם הנושא החשוב "איך למצוא עבודה". באופן די טבעי, חלק נכבד מההרצאות האלה יעסוק במי שאין לו ניסיון. יש כל מיני דברים שאנשים חסרי ניסיון יכולים לעשות, אבל מתישהו מישהו יפלוט אמירה בסגנון של "בחר לך איזה אתר אינטרנט ולך לבדוק אותו, כתוב תוכנית בדיקות ומצא באגים". ככה, לפחות על פי הרציונל, יהיה לנו מעין "תיק עבודות" שנוכל להראות.
עצה טובה, לא? הרי זה בדיוק מה שמתכנתים עושים. הם לוקחים בעיית צעצוע שלא חשובה לאף אחד וכותבים קוד בסיסי שמטפל בה. ככה הם מראים כמה הם יודעים למי שאולי ירצה לראיין אותם.
כמו במקרה של כתות מטען, חסר פה רק חלק קטן אחד - בדיקות תוכנה מקצועיות. כל בודק תוכנה מנוסה ידע לספר שאת רוב הערך משיגים עוד לפני שכתבנו או הרצנו בדיקה אחת. שזה לא חשוב כמה יפה כתובה תוכנית הבדיקות או כמה מפורט הבאג שפתחנו. מה שחשוב זה השיחות שיש לנו מסביב כשאנחנו מתכוננים. זו השאלה שנשאלה בדיוק ברגע הנכון כדי לשנות לחלוטין את איך שמפתחים פיצ'ר וחסכה לכולם מלא שעות של תסכול, זו הפרספקטיבה השונה שמביאים לסקירת הדרישות או העיצוב, אלה שיחות המסדרון בהן חושבים יחד עם המפתחים על דרך טובה לפתור איזו בעיה. זה כשאנחנו מתפקדים כמתרגמים או כשאנחנו מסתכלים על "מה יכול להשתבש" במקום על "איך לגרום לזה לעבוד". הם ידעו לספר שכשעובדים כבודקי תוכנה ועושים את העבודה היטב אנחנו לומדים המון על המערכת הנבדקת ועל איך היא בנוייה. על הארכיטקטורה שלה ועל המוזרויות של הספריות הספציפיות בהן היא משתמשת, על האילוצים הטכניים ועל הדברים שנשברים באופן תדיר יותר. אנחנו גם לומדים קצת על הצד העסקי - על אילו תלונות מגיעות מהלקוחות שלנו, על מה חשוב לנו מספיק כדי לעצור גרסה או אילו תכונות עוזרות לנו למכור את המוצר על פני המתחרים. מה דחוף וממה לא אכפת לנו בכלל ולא נתקן גם אם הוא שבור. אנחנו מנצלים את כל הידע הזה בתכנון הבדיקות ובשיחות שלנו עם אנשים.
החלקים האלה נעדרים לחלוטין מ"תיק העבודות" שנוכל לבנות אם נעקוב אחרי העצה המטופשת הזו. אם אנחנו משקיעים זמן בדברים האלה, או אפילו מצטרפים לפלטפורמת בדיקות המון ומקבלים דמי כיס על בניית תיק העבודות. בהחלט יכול להיות שנוכל לשפר ולהדגים כמה כישורים טכניים, ואפילו כאלה שנמצאים במודעות הדרושים, אבל צריך לזכור שזה לא נוגע בכישורים הספציפיים של בדיקות תוכנה. במצבים האלה אנחנו לא נגיע לדיונים על סדרי עדיפויות או על מה אפשר לא לבדוק, לא נצטרך להתווכח על תכנון תאריכים ולא נדע אם המשוב שלנו הועיל למישהו. פשוט חבטנו קצת על המקלדת בלי שיש לנו מושג ירוק מה חשוב לחברה. הסתכלנו על קצה הקרחון שחשוף באתר האינטרנט בלי שיש לנו גישה לכל הקרחון העצום שמתחת לפני השטח של האתר החמוד שבחרתם לעצמכם כקורבן.
או, אם לסכם את כל הפוסט במשפט קצר ורק קצת מוקצן - בודקי תוכנה טובים לא מבזבזים את הזמן שלהם על בדיקות.
No comments:
Post a Comment