LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

עמית

עמית

ראשון, 28 אוגוסט 2016 19:59

לכו לכנס

 את התמונה ציירה christina ohanian במהלך ETC.

(את התמונה ציירה Christina Ohanian במהלך ETC. הצילום המטושטש - באשמתי. גרסה מוצלחת יותר אפשר למצוא כאן)

 

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

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

  • הזדמנות לשמוע על מגוון נושאים מעניינים - כן, נכון. יש מלא נושאים מעניינים באינטרנט, עם וידאו באיכות נפלאה והיכולת לצפות בזה מתי שרק מתחשק לכם ולסנן את הנושאים שמעניינים אתכם בלבד. אבל מתי בפעם האחרונה ראיתם משהו במחשב בלי הסחות דעת באמצע? בלי הפיתוי לשים את השיחה ברקע ולעשות עוד שלושה דברים במקביל? זה קורה פחות עם אנשים אמיתיים.
    יתרון נוסף שיש להרצאות בכנס הוא שלפעמים אתם נכנסים להרצאה רק כי אתם שם, או כי כולם נכנסים, או כי אתם רוצים לשמוע את הדובר (או הדוברת), ומגלים הרצאה מפתיעה. זה מה שקרה לי  בהרצאת הפתיחה של היום השני בCAST
  • הזדמנות לשאול שאלות - שמעתם הרצאה ממומחה שמתעסקת בתחום שאתם מתקשים בו? לא הבנתם משהו בהרצאה בתחום חדש לכם? יש משהו שנראה לכם חשוב לומר? אם אתם נמצאים בכנס אתם יכולים לקום ולשאול. אם ההרצאה מוקלטת, ההערה שלכם תיכנס לשם לטובת הצופים. אתם גם יכולים לתפוס את המרצה לשיחה קצרה אחר כך ולדבר על הנושאים שמציקים לכם באופן אישי. 
  • יש הרבה אנשים מעניינים שלא מרצים בכנס אבל מגיעים אליו. לפעמים תמצאו את עצמכם מדברים במשך שעה או שעתיים עם אנשים שרק פגשתם. או שתפגשו מישהו שבמקרה מכיר את הדבר הזה שאתם מסתבכים איתו עכשיו (ועכשיו, כשיצרתם קשר, אפשר לשלוח לו דוא"ל עם שאלה קצרה או שתיים, או אפילו לשכור אותו כיועץ אם הוא עושה כאלה דברים). 
  • ואגב אנשים שפוגשים - אם הגעתם עד לפוסט הזה, אתם כנראה קוראים כמה בלוגים, או עוקבים אחרי טוויטר (או שקובי עשה עבודה ממש טובה בלגרום לכם להיכנס לקישור הזה), וכנראה שיש אנשים שאתם נהנים לקרוא יותר מאשר את היתר. נחשו מה? הם (או לפחות חלקם) מגיעים לכנסים. לחבר אישיות למי שעד כה הכרתם ככותבים (וכתמונת פרופיל) מוסיף לחווית הקריאה ומעשיר את התקשורת בין שניכם (שעד כה בדרך כלל הסתכמה ב"אני קורא את מה שנכתב").
  • בכנס יש גם סדנאות - היתרון של סדנאות הוא בכך שאפשר גם לתרגל את הרעיונות החדשים ולראות איך הם עובדים בשבילכם. הסדנאות בדרך כלל לא יוקלטו, וגם אם כן - השתתפות בסדנה זה הרבה יותר מועיל מאשר צפייה בה. לא באמת לומדים הרבה מצפייה בלבד. 
  • לומדים מה קורה במקומות עבודה אחרים - יש לנו (או לפחות לי) מעין תחושה שאנחנו יודעים הכל, ומה שאנחנו רואים מסביבנו זה מה שכולם עושים. אבל המציאות די רחוקה מזה - חלק מהאנשים עושים דברים דומים, חלק נמצאים הרחק מעבר למקום אליו חשבנו שאנחנו רוצים להגיע, ואחרים נמצאים במקום בו היינו לפני חמש שנים. חלק פשוט חיים בעולם בו מה שאנחנו עושים פשוט לא רלוונטי. זו הזדמנות ללמוד מה קורה אצלם, ומה הם עשו כדי להגיע לאותו מקום (ואם מדובר בכנס מקומי, זו גם דרך לדעת אם מדובר במקום בו תרצו לעבוד או לגייס אנשים שמגיעים ממנו). חוץ מזה, אולי סתם תשמעו במקרה על איזה כלי שמשתמשים בו ומוצא חן בעיניכם.
  • זו זריקת מרץ נהדרת - לפעמים העבודה היומיומית יכולה להיות שוחקת, ואם אתם היחידים במקום העבודה שמפגינים עניין בתחום מסויים (האחרים אולי מתעניינים בשקט בלי שאתם שמים לב) זה יכול להיות מעייף. בכנס תמצאו אנשים שאכפת להם מנושא הכנס. להיות בחברת אנשים אחרים שאכפת להם מוסיף המון אנרגיה.
  • זה גם לא מזיק לצניעות - אם אתם אלו שמתעניינים בתחום באופן הכי קולני בסביבתכם, קל מאוד להתבלבל ולחשוב ש"אני הכי טוב בזה". אולי גם תצליחו לגרום לאחרים לחשוב כך. בכנס יש לכם הזדמנות לראות אנשים טובים לא פחות (חלקם יהיו טובים יותר), וללמוד מהם, או לפחות להפנים שיעור זריז בצניעות.
  • זו הזדמנות לקדם את עצמך - לא כולם מרצים בכנס. למעשה, הרוב אינם מרצים. ועדיין, כנסים מספקים מקום להציג את עצמכם בפני המשתתפים האחרים - בחלק מהכנסים מספקים במה להרצאות ספונטניות מהקהל: אלו יכולות להיות שיחות בזק (lightning talks), או שוק פתוח (שמתקרא בלע"ז open space), או אותה פעילות שאין לי מושג איך לתרגם בשם lean coffee. המון הזדמנויות לדבר. אפשר גם סתם לשאול שאלות מוצלחות בהרצאות, או לגשת למישהו בארוחת צהריים ולהציג את עצמכם.
  • זה כיף - עדיף לא לשכוח גם את זה. בדרך כלל יהיו אחרי הכנס מפגשים עצמאיים (או מאורגנים) של משתתפי הכנס, או טיול משותף ביום שלאחר מכן, ואפילו במהלך הכנס - אנשים מסביבכם נהנים, וזה מדבק. 
  • יש מה לספר אחר כך בבית - הייתם בכנס? מצויין. אם זה היה כנס טוב, אז שמעתם לפחות רעיון אחד חדש שאפשר לספר עליו בעבודה. זה יכול לשפר את הדרך בה עובדים אצלכם, או לכל הפחות לבנות קצת את המוניטין בעבודה, שגם זה חשוב.

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


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

ועכשיו, עם טיפ-טיפה יותר פירוט.

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

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

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

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

עד כאן לגבי הנקודה הראשונה. על למה מיישמי אוטומציה יתקשו מאוד לייצר משהו נורמלי. אבל, גם אם נתעלם מזה לרגע, ישנה בעיה חמורה יותר – ההפרדה מובילה למצב בו מי שכותב את התשתית לא צריך לבצע בדיקות בעצמו, לא משתמש בה ולא באמת יודע מה עושים איתה.
ומעשה שהיה כך היה – לפני בערך שנה נכנסנו למשימה בה יחס העבודה היה 3:1 בין הבודקים למפתחים (שלוש משימות בדיקה מול כל משימת פיתוח. משימה, לצורך העניין, היא משהו שאמור לקחת כיום עבודה לאדם אחד), בשל חופשות ושאר בלת"מים יחס האנשים היה 1:5 (בודק אחד, חמישה מפתחים) היה לנו ברור איפה נמצא צוואר הבקבוק הפעם. כדי להתגבר על זה, החלטנו להעביר למפתחים שתי משימות גדולות יחסית – הוספת היכולת של מערכת האוטומציה שלנו לייצר קבצי אקסל בצורה מסויימת, וייצור של קבצי XML. אפילו קיבלנו את מה שביקשנו – אלא מה? בשני המקרים, כדי שאוכל להשתמש במה שקיבלתי, הייתי צריך לבלות בין חצי יום ליומיים בעטיפה של הכלים שקיבלתי והתאמה שלהם לשימוש. זה עדיף על פני חמשת הימים שהיה לוקח לי לכתוב את הכל מאפס, אבל זה משהו שלא היה קורה אילו מישהו מהבודקים האחרים היה מייצר את הקוד הזה. זה קרה למרות שישבתי עם המפתחים והגדרנו יחד מה אני צריך ואיך אני רוצה שזה יתנהג. גם קיבלתי את מה שביקשתי.
מה לא קיבלתי? את מה שלא ידעתי לבקש מראש, או את מה שחשבתי שברור מאליו. שכחתי לבקש שאם ב90% מהמקרים רוב הפרמטרים קבועים אני לא רוצה להגדיר אותם מחדש עם כל אובייקט. ברור לי לגמרי שאם אני רוצה להכניס קבצים למערכת הבדיקות שלי לא מספיק לי לקבל .jar ואני רוצה את קבצי המקור כדי לשנות במידת הצורך. כל מיני דברים קטנים כאלה. חלק מהם אני מאמין שאפשר לפתור אם עובדים ככה לאורך זמן, חלק אחר יישאר, לדעתי, כל עוד יש פער בין כותב הכלי למשתמש.
עוד נקודה חשובה - במצב בו מישהו אחר כותב לי את התשתית, בקשות לשיפורי תשתית רלוונטיות רק במקרי קיצון, ולא תמיד אפשריות. למשל – העברנו את העבודה שלנו מול מסד הנתונים להיות מבוססת על מיפוי של כל הטבלאות לאובייקטים (Hibernate, אם להיות ספציפיים) – זה מצריך אותנו למפות כל טבלה, וחוסך לנו שכפול עצום של כתיבת אותו SQL כמעט. אם אני צריך לבדוק פעם שדה א' ובבדיקה אחרת שדה ב' לפי אותו where – אני מבקש את האובייקט ומתחקר אותו. לו כתבתי "תשתיות אוטומציה", המעבר הזה היה לא הגיוני. למה שאייצר תשעים אבני בניין, כשאני יכול לספק אחת שמקבלת מחרוזת SQL והוראות חיבור למסד הנתונים? פרוייקט הבדיקה שהיה מסתמך על התשתית שלי היה משכפל שאילתות וחורק בשיניו בכל פעם בה טבלה משתנה וצריך לעדכן את השאילתות עליה.

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

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