#6 פיתוח .vs בדיקות

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

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

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

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

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

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

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

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

והמהנדס החכם אומר: ומי יבדוק את הבודקים?