סופה של תקופה

English Version

היום הוא היום האחרון שלי בRSA. 

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

2   אני משתמש במונח "קהילת הבודקים האירופאית" מנקודת המבט שלי, זו לא בדיוק קהילה אחת, והיא לא הקהילה האירופאית היחידה - מבחינתי, אני מתייחס לאוסף האנשים שפגשתי דרך ETC בשם הזה. ^↩