Wednesday, March 22, 2017

מפגש בודקים - סיכום

testing meetup

התחלה טובה למפגש

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

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

-----------------------------------------------------------------------------------

Last Thursday there was a testing meetup in Tel Aviv, the first one in a series of meetups that are dedicated to testing - not automation only (though it does not exclude automation), not a specific technology, simply testing. After quite a while without a JeST (Jerusalem software testing), it was nice to see a new meetup coming to life. I want to thank Nitzan and Igor for organizing this series, Avivit who invited us to ClickTale office and was a great hostess and Anna who presented the first talk in the meetup. 
The evening started with a very interesting topic - risk based testing. Anna gave a thorough overview of the subject, touching on why it is important to incorporate risk into our testing, and we had some great discussions about who decides to ship, how to treat risk and how to report on risks identified during testing. All in all - it was a very good intro to the subject. One point to keep in mind for the future, though, is that the talk was very theoretical and was deeply rooted in a reality that was foreign to most attendees  - a reality in which there is a place for quite heavy documentation and the release cycle is quite long. This made the talk more valuable to the more experienced people in the room who were already familiar with the concept of risk and could extrapolate from what was said to their day-to-day work.And indeed, some of the attendees seemed to doze off a bit. Despite that we had some interesting discussions during the talk and I found the entire experience interesting. 
After the talk, during the break, people did the right thing and split up to small groups for some chatting, which is exactly what I did: I spotted someone who was sitting alone in a corner and went to introduce myself and start a conversation. suddenly, the break was over and we had to cut our conversation short. 
Once the turmoil from the break broke off, Nitzan presented a question to the audience: What is required in order to transform from a good tester to a great one? Personally, I would be satisfied to simply be a good tester, but I can see the value of aiming high. At this moment, of course, it was already clear (from the mini-discussions we had) who were more likely to join the conversation and who would probably be silent for the entire meeting. To mitigate this, at least a little, I used something I encountered during lean coffee sessions (and some scrum retrospective) and distributed some post-it notes to each participant and asked each person to write down at least two ideas (why two? Because asking for one would have probably ended in each person writing down one note, with the shy ones skipping it altogether, and because trying to think of two distinct ideas is where other ideas come from). I then used the moderator position I appropriated to get people up and stick their post-its to the whiteboard, just to see how many ideas we had (If you can read Hebrew, you can find the subjects here thanks to Kobi who collected them), and then to facilitate the discussion around some topics and make sure that the silent ones at least got to choose a topic.

By the end of the meetup, the convention spirit took care of us, and we found out that down at the building entrance there was some music and free beer (something related to the fact that it was the night before St. Patrick's day, I think) and so some of us stayed and talked a bit more for a couple of hours. Funny as it may be, it doesn't matter how good was an event, it's the unofficial parts which are the most memorable and enjoyable.

This meetup was a chance to get a wide variety of people together (how wide? if we limit ourselves to experience years only, we had people with over 20 years of experience together with some who are looking for their first testing job), and although it's only my estimate, I think that everyone who were at this meetup will want to be in the next one as well.
Personally, I can't wait to the next meetup to happen - I really liked the combination of a talk and an open discussion, and the vast array of different experiences contributed a lot to the interesting discussions - during the talk and after it. 

Saturday, March 11, 2017

איך לעבור את ראיון העבודה שלי

How to pass my technical interview

Source: https://res.cloudinary.com/teepublic/image/private/s--nsFTfEGE--/t_Preview/b_rgb:0073ad,f_jpg,q_90/v1446153336/production/designs/25093_1.jpg

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

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

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


* כמובן - אם אתם מחפשים עבודה ורוצים לשמוע פרטים, שלחו לי הודעה. 


--------------------------------------------------------------------------------
For quite a while now, we are looking for someone who will join our team, which means we get a whole bunch of CVs, and some of the people I get to interview (alongside my manager). What can I say? It's really frustrating to interview a candidate that fails. We want to find a new team-member, the candidate wants a job offer (hopefully, they want a job offer in our team), but as far as we can determine - there isn't a match in the skill-set the candidate has and that which we need. Of course, an interview is a stressful situation, which can lead to wrong impression. 
The way things are set now, it seems that next week I will do very little other than interviewing candidates. So, as a service to the community (and also in hope that the interviews I have scheduled will go better), I thought to write about how to pass my technical interview.

First of all, before you even get to the interview, do your best to determine that the position matches your skills and desires. It almost doesn't matter how well prepared you will be - if there's a mismatch here you either won't pass the interview, or you'll get a job offer you don't want. If you want to improve your mobile testing skills, a place that builds software for aviation engineers is probably not the right place for you, and if you don't have any performance testing background, no (decent) place will hire you to lead the performance testing efforts of the entire company. Before you get to any interview, sit with yourself and be honest - what do you want to do? what skills do you have? what skills you need to acquire? It's ok to apply for a position if you don't have all of the required skills: It is always assumed that a new employee will have to learn some stuff before actually being productive. However, there are some skills that the workplace will not have the time, ability or will to teach you - and guess what? Those are the very skills you'll be interviewed for. For us, for example, there are three basic things we look for in a candidate: Communication skills, Programming (at least at the level of a university graduate) and the package that is sometimes referred to as "Tester's mindset" (Including stuff like System-view, Question-asking and context awareness). If you'll ask us before the interview - that's probably what we'll tell you. 

You got to an interview with me? congratulations. This means that I think that you have a good chance to pass the interview. Also remember that I want you to pass. So, here are some things you should keep in mind. 

  • I asked something you are not familiar with? There isn't much that you can say and will impress me more than "I don't know". If I asked you about how memory is managed in Java and you have never learned it - I am probably trying to map what you know, not to trick you and disqualify you based on an easy to learn subject. I might also be trying to direct the interview to a certain direction, in which case saying "I don't know" will save us both time and I can tell you what I need you to know to continue.  If you'll throw around some half-related terms to try and make me think you know what you are talking about I'll notice and will lose my appreciation for you.
  • Even if you do know how to respond - ask a question or two to make sure. Knowing to ask good questions is important for testers (and any other knowledge workers). I've asked you to test a pencil? If you'll start throwing test cases without asking if it's a make-up pencil, it will be disappointing. In a world where the possible test options are infinite, I want to learn about the way you prioritize your tests. I also pose challenges that are meant to make you ask questions so that I'll see how good are they. 
  • Also, don't bother practicing testing pencils, I don't ask this sort of things. I interview people for software testing positions, not for industrial designer ones. If I'll ask you to test something, it will resemble more something that you can expect to find in your day to day work. 
  • At the beginning, I will ask you to describe your last workplace, or a project or course from your studies - I'm trying to understand how well do you understand technological projects, and how well can you communicate them and separate between what's important and what isn't. I will ask for a high level overview, I might ask to deep dive on a random part of the system. I expect you to know to explain what is the system used for (and by whom), how data is passing through it and what are the main components in it. When I ask about the fine details of your system it is not because I try to uncover trade secrets, but because I want to assess how deep is your understanding of the system you were working on previously. 
    If you want to prepare for this question - make sure you can draw a high-level diagram of the system, and can dive in a level or two on every part chosen at random. Also make sure to notice which level of detail am I asking for. I expect you to be comfortable in  both high-level overview and low-level fine details scope, so don't run to the overview when asked for details, and don't hide behind details when asked for an overview. 
  • Defend your opinions. sometimes, during the interview I will ask you "why?" I might have noticed something I think is a mistake, or I might want to make sure you know why you are doing something. I might even check how do you respond when an authority figure (me, in this case) is putting pressure on you. 
  • Your CV sets expectations. If you write "ISTQB certified" and you don't know what boundary values are, I will hold it against you. If you did not write such thing, I will just assume that you have not heard of the term and explain it quickly. 
  • There's no such thing such as "failing a question". First of all - if you're here and I'm investing my time in you, I won't let a single question to be a single point of failure. Second - a question is giving me information. You might have a knowledge gap that I have to consider, and I will ask some follow-up questions to better understand that gap and see if I can live with it or easily fix it. 
  • Tell me what are you looking for - if you do not do so, and I will get the impression that you are looking for something different than what I have to offer, I will not pass you to the next phase. If you don't tell me and I will pass you through - I will be wasting your time on something you don't want. 
  • Now, some stuff about coding questions: 
    • I ask you to solve a programming problem without giving you a computer. This means that I don't care about the code compiling and couldn't care less about syntax issues. Had I cared, I would have provided you with an IDE. I won't care if you miss out a semi-colon, or have a typo in your function name. In fact, if you're not sure if there's a function that does what you want, just pretend to invoke a function with a clear name and say that you're not sure that there is a function by that name. 
    • If it's critical for you - you can write down your answer on a piece of paper. In any other case, it's better to answer on the whiteboard, so that I could see what you are writing and how does your thought process goes. I learn from the code you erase as much as from the code you don't. When you are writing on paper I can learn mostly by looking at your expressions, and usually this doesn't work in your favor. 
    • Don't be silent. Tell me what you are about to do. Tell me about the problem that is preventing you from progressing. If you need to think quietly for a couple of minutes, tell me that you are taking a pause to think - I might even get out of the room for five minutes to provide you with some comfort. 
    • Work with examples, and make sure that your algorithm works for the examples you chose. 
    • I can see the code you're writing. Either as you write it or shortly after. Use meaningful names. On top of demonstrating good coding habits, it helps me understand faster where are you going and what are you trying to do. If you write a function named "flipNextBit" I can tell what it should do even if I don't see the implementation (or if it has a bug).
    • You cannot google during the interview, but you can ask me. 
    • Before the interview, google some coding interview questions and practice answering them on a whiteboard. Most will be much harder than what I usually ask. There are two types of difficulties in the coding question - not being able to find an algorithm that will solve the problem, and finding an algorithm but failing to transfer it to "code". Practicing will help you with both types. Just getting accustomed to this type of question will increase the chance of you finding an algorithm quickly, and practicing on a whiteboard will free you from depending too much on an IDE. 
    • Most probably, you'll have some mistake in your code on the first attempt. maybe an edge case you didn't deal with, or something you overlooked. Don't freak out once I lead you to such a failpoint. I don't care if your code is working, I want to see how do you deal with your own mistakes. Do you freeze? Do you try to minimize the importance of the mistake (I had once heard a candidate refer to an off-by-one-bug that was applicable to every input as an "edge case" - don't do that)? do you shrug your shoulders and fix it?
    • Yes, it's a testing job. Yes, we use selenium sometimes. Don't bother memorizing the selenium API - I don't ask questions if the correct answer for them is "Google it". 
    • If all of your programming education is some "automation course" you took, do yourself a favor and learn how to code properly. You don't have to get a fancy diploma to prove that you can code, but you should have a solid understanding of data structures, polymorphism and recursion. Not all of those will come up during an interview, but all are fair game. 
  • Finally - ask for feedback. It's still something I need to learn how to do, but I asked you to invest your time in coming to an interview with me - I will be happy to help you gain some benefit from it by pointing out what flaws I saw, so even if you don't pass my interview, at least you can get a pointer or two and improve. 

* Also - if you happen to be looking for a new job (and are located in Israel) and want to hear some details, drop me a note. 


Friday, March 10, 2017

How FAR are you willing to go?

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

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

כשבוחנים יעילות של מכשור לזיהוי ביומטרי יש שני מדדים שמתייחסים אליהם - רמת אי התאמה מוטעית ורמת קבלה מוטעית. כלומר - מה הסיכוי של אדם לא להיות מזוהה כעצמו בטעות, ומה הסיכוי של אדם להיות מזוהה כאדם אחר בטעות. הטעויות האלה נקראות: 
FRR (False Rejection Rate)
FAR (False Acceptance Rate)
כמו שניתן לנחש, אפשר לכייל את רמת הרגישות של הסורק הביומטרי כדי לשנות את הסיכויים של כל סוג טעות (ככלל, ככל שהסורק רגיש יותר, כך הסיכוי לאי התאמה מוטעית עולה, והסיכוי לקבלה מוטעית יורד). מתוך שני המדדים האלה, נגזר מדד שלישי - CER - Crossover Error Rate, שמציין מה היא מידת הטעות כאשר שני המדדים לעיל שווים. ככל שמדד CER נמוך יותר, כך הפשרה שנעשה תהיה קטנה יותר והשיטה נחשבת טובה יותר (כמובן, במקרה של צרכים ספציפיים כמו למשל בבסיס צבאי - תהיה חשיבות גבוהה יותר לאחד המדדים, אבל CER הוא כלל אצבע יעיל למדי ברוב המקרים האחרים).

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

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




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


--------------------------------------------------------------------------------------------------------------

It happens to everyone. 
At least, I have not yet heard of a place where this phenomenon does not exist - People are building a nifty test harness to run some automated checks, and let's even assume they're doing a really good job: They write clean code, check at the proper levels, use decent programming instead of just piling something that works, and generally are using the right tool for the task. Everything is as good as it gets. Yet, something is still amiss. There's this small, annoying problem: Some of the checks, usually at the system level, are "flaky", which is to say they fail sometimes with no apparent reason. Even when the flakiness rate is pretty low, after a while there's a whole hoard of slightly flaky checks and almost every run is failing1. So we re-run the checks. if they pass the 2nd time (or the 3rd, or five passes out of seven) - we call the run a success. There are, naturally, many other ways of doing it - we add waits and check for page load, we retry simple actions within our framework, ignore part of the screen during image comparison since there's an alternating ad in that part.
By the end of this process we have a suite of checks that is almost always failing on real bugs. Cool. However, to achieve that we increased the automation fault-tolerance, and introduced a greater risk of missing (sometimes not so) subtle problems. Keep in mind - this is not unique to automated checks. When was the last time you've heard (or used) the phrase "it happens sometimes, but it's gone after a restart"?

When referring to biometric systems, there are two common KPIs that are being used to measure a system effectiveness:
FRR (False Rejection Rate): The rate in which a system will not correctly identify a person.
FAR (False Acceptance Rate): The rate in which a system falsely "recognizes" a person, despite that person being someone else.
As you can guess, a biometric scanner can be calibrated to different sensitivity levels, impacting both of those KPIs. As a rule of thumb, making a scanner more sensitive will increase FRR and decrease FAR, allowing to choose the suitable settings for the situation (On your private phone, having to scan your finger twice each time is rather annoying, but in the case of a high-security military base, you'd rather scan your palm for 10 full seconds than allow unauthorized personnel in).
When comparing two biometric systems, one of the quick comparison points is CER (Crossover Error rate) - which is the point where FRR is equal to FAR. A system with lower CER is considered better for most use cases.

I think that using such a measurement for checks, and especially for automated checks, can be useful. If the null hypothesis is "The software is clear of bugs that the automated check is expected to find", then FRR will be the flakiness rate of a test (number of failed runs with no actual bug, divided by the total number of runs), and the FAR will be the number of passed runs where there is a bug, divided by the total number of runs. True, it's not a simple thing to measure (How do you count runs on bug that you didn't catch? Probably you'll need to leverage the source control to do that analysis). But even without having exact numbers - using the language of CER reminds us that sometimes we need to invest also in improving the total accuracy of our checks, instead of simply shifting the balance between FRR and FAR.

And one final thing - one of the benefits of taking so long to write a blog post, is that I have the chance to stumble upon some interesting reading materials. In this post, Bas Dijkstra gives a very interesting perspective on checks reliability.



1 Google, Despite their best efforts, are seeing 1.5% flakiness ratio. Most companies I heard of can only envy such numbers. Yet - such a number means that at least one of the flaky checks will fail in every run.





also: 

Saturday, March 4, 2017

Lessons learned in Software testing, book review

(Book review, no Hebrew - if the book review is too long for you, you won't read the actual book anyway)

So, after hearing here and there some recommendations about Lessons Learned in Software Testing by Cem Kaner, James Bach & Bret Pettichord, I decided to choose it as my next book to read.
At the foreword, Tim Lister (who's name I haven't heard before) compares the book to a bottle of good port, and asks the reader to consume the book in small doses, with care and thought and with friends. Pesonally, I'm not a very sophisticated drinker, but the advice was very similar to how I like to read a poetry book - which is pretty reasonable for a book that hold short, mostly independent, pieces of content. I even borrowed a habit I have with poetry books, and inserted a small piece of paper between the leafs to mark a section I liked.
My general reaction to the book, to put is very simply, is "meh".
Don't get me wrong, though - there's some nice stuff in this book, and even a page or to that will make for a nice smile or even a giggle (my personal favorite on this area is the lesson titled "Programmes are like tornadoes" which carries an important message with a title that creates a nice mental image). However, this book is probably a victim of its own success - this book was initially published in 2002, which is about ten years before my testing carrer began - for me, context driven testing has always been around, and the messages in this book are coming from just about anywhere around me. This means that I was nodding quite a bit while reading the book - either a "yes, sure" nod or a "I heard this already and don't agree with it".
Reading a professional book is quite a task for me - I don't read as fast in English as I do in Hebrew, and I do have other kinds of books competing for my reading-time. So when I read a professional book, I want more than a simple confirmation of what I know - I want to learn a new way of looking at things, or learn the base I need for a new skill I don't have. At the very least, I want to see an idea explained well. This book is not any of those for me - it is a collection of anecdotes that are nice to remember, but as a whole - there's nothing memorable (or memory-worth) in the experience of reading the book.
This book might be a better suite to people working a bit longer than me in the industry, or those who have experience solely in what some are calling "the factory school testing". It might be a good read for software testing students, but I have probably missed the train for this one.
Also, important to say - it seems that James Thomas have a different experience with this book.

Sunday, February 19, 2017

Anything you can do, can I do better?

Another ETC post. There are others:
Tutorial days
Conference days
My retrospective

Up until recently, I was assuming something very simple: There's nothing an average developer can do that I can't (and vice versa) - Yes, there are some differences in the experience we have,  but overall we have the same basic training, speak the same language and discuss software design with each other. So, with the exception of those superstars you see here and there that are clearly better programmers than their peers, I considered myself equal.

Then I went to ETC, where I heard Liz Keogh speaking on Cynefin, and creating safe-to-fail experiments. One of the basic assumptions she has there is that testers are good at finding problems, and developers are good at coming up with ideas to solving problems (even ideas that don't work). What does it mean "testers are not good at coming up with solutions"? Surely I can do that, I solve problems all the time at work. Don't I?
There were two things that happened and pretty much convinced me there is a point in this. The first, is the talk I had with Liz after the tutorial day where I was bombarded with a series of questions that led to that "oh..." moment, and the second is Liz talking about how people have tend to respond to new ideas with the phrase "That won't work because...", which I realized that I do a lot.
So, are testers less efficient in find solutions? Are testers so constricted by spotting possible fail points that they can't act?
The more I think about it, I tend to say yes. As a general rule of thumb, I can see how this can be true. Of course, this is not a yes\no question, but rather a scale - and the exact position on which a person stands had some other factors that affect it (such as the experience in doing similar things, knowledge of the field in which an action takes place, etc.), but in general, it makes a lot of sense - Testers are tasked, on a day to day basis, to find potential problems, to poke at the perfect model someone has built and find weak spots in it. Developers, on the other hand, start almost every really new task by "creating a proof-of-concept", something that will sort-of work and teach them how to approach the problem in full scale. I take it for granted that I test better than most developers with equivalent experience because I have invested a lot of time in becoming better at it, and that they are probably better at coding since this is what they practice. But practicing a skill does not only mean getting better at it, it means tuning your mind and habits to it, and if some other skill is opposed to that, it will be that much harder to acquire.
Also, one other thing that is important to keep in mind - This mindset is not the permanent. People can, and do function successfully in both roles, though probably not simultaneously (I think I recall someone saying it takes them about a week to do this mental shift).

I took three things out of Liz's talk -
  1. There is an important place for asking the difficult questions when setting out to try and solve something. It part of what makes an experiment "safe to fail" (which was the title of the talk). Putting this kind of lens gives me another tool that will help presenting questions at the context they are relevant to (e.g. - not going into "where should we put this bit" during a high level description)
  2. I, too, have my limitations. Now that I'm aware of one of them, I can act to make sure it's used properly (for instance, when I spoke with one of the developers in the team about the architecture of a new piece of software we're planning, I wrote down my questions instead of interrupting. By the end of his explanation, half of the questions were answered, and I could provide feedback that was more relevant. And how is litening relevant to Liz's talk? Knowing that what I'm about to hear is an imperfect solution that "generally works", the small problems were no longer blockers, and so writing them down is more useful than stopping the whole train of thought). 
  3. I need to practice my "let's do it" mindset - It's true that I'm a tester, but I still need to solve some problems, and there's more to me than just work. As long as I keep tabs on my "professional pessimism", being able to flow with an idea is useful.


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

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

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

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

שלושה דברים שנשארו איתי בעקבות ההרצאה של ליז:

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


Tuesday, February 14, 2017

ETC 2017 - the Good, and that which can be improved

(No Hebrew for this, it's quite long as it is, and the main audience for this post are the Organizers of ETC, none of whom speaks Hebrew to the best of my knowledge)

At first, I thought of naming this post "ETC - the good, the bad and the ugly", only there was nothing ugly there, and the things that weren't as good, are still far better than "bad". ETC was an extremely good experience.

This is my list of things that I liked and liked less in the conference, since the organizers did go quite far to collect feedback and understand what worked and what didn't, I want to try and help by pointing out the things I remember and provide some detailed explanation that will hopefully be more useful than a cryptic title on a sticky note, and help in getting the "why" as well as the "what".
So, without further ado - the list.

Things I missed, or think they can be improved
(I'm starting with this since I believe people tend to remember the last thing they read, and the conference as a whole was very good)

  • Conference slack channel - In my first night before the conference started, I wanted to find people to catch a dinner, but didn't have a way to know who will be attending ETC, and who is already here. I managed to find a tweet that was connected to a name I could reach through the testers.io slack channel (I don't have a tweeter account). Having a public place to shout "hi, does anyone want to meet?" is very useful, and not everyone on the conference will overcome the discomfort barrier of contacting a specific person they don't yet know. Publishing a general message on a designated board is a bit easier.
    In addition, while last year there wasn't enough discussion on the slack channel, there was enough to inspire me and prepare a subject for the open space (this year, I prepared something the day before, since I knew how it worked, but didn't have any sort of heads up this year).
    Plus, it was a very good place for administration messages.
    While in the conference, I don't really need a digital sphere for discussion, since I'm having a lot of interesting discussions face-to-face. Having a closed, define area where I can contact conference members.
    "But there was a twitter hashtag", one might say - Well, it's completely different. Twitter is a public identity one either have or they don't, and slack is a private account that is created for a single purpose.Only other channel members can see this account, and the purpose of it is narrower. My testers.io slack channel, which is fairly wide purposed, is not used to upload cat pictures or show up a new car\shirt\haircut. It revolves around testing. Using twitter as a communication channel excludes me from the discussion.
  • Video recording the talks - The talks at the conference were mostly great. At times, it was hard to choose which talk do I prefer.  Having the ability to watch the talk later is a good way to catch up.Yes, I've heard (some of) the reasons for not having the talks, or some of them, recorded, and they are important,  but I think in this case some sort of compromise can be done to enable video recording, at least of some of the talks. My reasoning for recording the talks are: 
    • Since "the rule of two feet" was recommended, I found myself at one point leaving a talk which I liked, and joining a talk I liked a lot. I'm happy with my choice, but I now feel two gaps - I am curious about how did the talk I left continued, and wonder what great ideas I missed in the talk I joined. Knowing that there is no video increased the price tag of leaving a talk and reduce the return on joining one in the middle.
    • Talks recordings are the best conference promotion there is. So far, I've attended two conferences - ETC (twice) and CAST. The reason I was determined to go to CAST is that in 2015 I was watching CAST live and saw this. I've seen some CAST talks in the past which made me think "it could be nice to be there", but when I saw this talk it shifted to "I must be there". On the other hand, when I watched STARwest live (or was it STAReast?) I knew that I don't want to go there. Testbash talks I've seen have made me want to do two things: Join the dojo once I have time, just to watch the talks, and hopefully in the future attend it. 
    •  Feedback to the speakers - I don't have a lot of experience in public speaking. The little I have from a local meetup taught me I rather have a video to see my mistakes and learn from them. Yep, it's not always fun watching myself on stage, but it is useful. 
    • Sharing - Some of the talks are "ok, nice", but some of them are "I must show it to..." I've shared Linda Rising's keynote from last year with at least 7 people, and referred people to the talks of Emma Keaveny, Abby Bangser and Franziska Sauerwein (which I did not even attend at the time), as well as to Anne-Marie Charrett's keynote of that year. 
    • Re-visiting talks and ideas - Some talks left such a great impression on me I just had to watch them again. It's either to be able to refine my revelations from the talk, revisit some ideas in order to be able to pass them on back at home or just re-living the experience. There are at least four talks I want to watch again from this conference.
  • Matching talks to their description \ title - When I first looked at the schedule this year, I was thinking "Really? those don't look very interesting, I have at most one option per time slot that is interesting, and sometimes not even that". During the conference while hearing about some of the talks (from the speakers beforehand or from participants afterwards) this image was completely untrue - Most of the talks were more than simply good. I just didn't see that while reading. Not sure how to do that - Nordic testing days ask for some expected takeaways from the speaker. It might help.
    Another issue I experienced was relating to the meta-tagging (testing \ craftsmanship \ automation \ other). I walked into a talk I expected to be about automation (I even dragged someone with me), and the talk was about something completely different. It was a decent experience report, but a complete mismatch for me. 
  • Full talks description printout - I'm a bit torn about this. I don't really like the idea of using more paper than is necessary, and most of the time, the description is not read, but there were times where reading the description of the next talk could have been useful. Yes, it's online, but opening a browser on my phone and trying to read stuff from there takes a long time. and just didn't occur to me at the time. Maybe a board somewhere with the descriptions printed once on a big page, or maybe I should just learn to use my phone.  
  • Speed meet - It was great to see the experiments that were done to create a more communicative conference. I think this experiment has failed - the short time didn't really enable meeting the people or even determining whether or not I want to talk with them further. Out of the people I met, there was one whose face I could remember (and we actually talked a bit at later events, which I don't know whether I should attribute it to the speed meet, or to the fact that we hanged out a bit with a 3rd common person). Even if I attribute the single success to the speed meet, one out of six or seven isn't a good way to spend my time in such a conference where every other activity (that is not a talk), including a coffee break, is making me meet more people and have more meaningful discussions with them.  
  • Questions - There was a deliberate decision not to allow time for questions, with decent reasoning behind it. I was missing this part. Last year, coming up to the speaker with questions meant we were late for the next talks almost constantly. This year, most talks had time for one or less questions. Comparing this with CAST, where the discussion is structured (with K cards), I really felt the questions time was a good way to spend my time. 
  • Only one slot of workshops - Yes, having "we didn't have enough" is a good sign. Yet, I find the workshops a refreshing point in a day. Having one each day last year was great, and having the same number of workshops in a single slot meant that there wasn't any at the 2nd day, and that choosing between them was more difficult. 
  • Conference day starts late - Ok, it's not very late, it's a very reasonable time. Another thing I liked in CAST and I think can be adopted was having a lean coffee session at 7:00 (or something of the sort). Yes, it's a bit difficult to get up this early after an interesting night, so not many people will come, but I really liked it there. I thought about trying to have people gather around, only finding a way to publicize this was a bit difficult (blimey, did I just say slack again?). In retrospect, I probably should have just posted a sticky note or shouted at main hall. It's a great way to start a conference day. 

Now, some the good parts
  • The venue - What I really liked about the place was that all of the rooms were around the main hall. No corridors to hide people from each other, no need to run a long distance to get to a talk and immediatly after getting out of a room, I was in the middle of the activity, where all of the other participants were having a cup of coffee. 
  • All talks were great - Ok, I'm exaggerating a bit. There's a chance that there was a talk that wasn't as good, but the care that was put to choosing the speakers and subjects was clearly visible. During the 2nd conference day, I had a sequence of magnificient talks that started from the opening keynote and ended with the closing keynote. The only event that broke this series of great talks was the open space, because it was not a talk (it was great). I was, and still am, very impressed by the quality of the talks I've seen.
  • Aligning actions with declarations - The conference organizers are very clear in stating their intentions and areas of care - They want a conference where experts and practitioners meet and share information (and not salespeople pitching their product). The care a great deal about having a conference about testing that is welcoming for non-testers, and developers in particular. They care about their speakers and see them as partners, and they are here to change how conferences are by setting example.
    Each and every one of these claims is addressed with brave and well thought about actions. Inviting developers to speak at the conference is making room for developers in the audience, a strict filtering of the talks made sure that nothing that looks like a sales-pitch ever got near the conference, and the organizers involvement in the community enables them to target practitioners and ask them to come and speak. By speaking with each and every person who submitted a talk they made it easier for new speakers to submit a talk, paying for the flight and hotel for speakers, and doing so in advance is removing a great barrier from speakers who cannot afford to pay that money just to get to the conference. Creating scholarships to help speakers at other conferences is helping to diversify other conferences, and carry the ideas that come from this conference to other conferences. 
  • Choosing good causes - Aligning the actions behind the declarations is good only since the causes this conference stands for are good. They focus on values I can strongly relate to, and that are important to push forward. 
  • Everything was masterfully organized - This was true last year, this was true this year as well - as a participant I could not see any crisis that required the organizers attention - so even if there were, they were dealt with without creating a fuss in a very professional way. 
  • hoodies! Instead of a conference T-shirt, we got a hoodie. Much more useful, and suitable in many places where the T-shirt would be inappropriate. Next time - let's print the Logo on the front as well so that it will be seen even when carrying a backpack. 
  • Focus on conferring - this relates to standing behind your statements: The effort done to foster discussion and enabling people to meet and talk was very visible.
  • Showing care - All of the fuss that went into matching words to actions sums up to one thing  - The organizers care, and it shows. This sort of care makes me happy to pay the entrance fee for the conference, since by doing that I can support their causes just a tiny bit.
  • Speed meet - Yes, this was a good thing too. Even though I didn't like the event itself, I really admire the fact that experiments are being done. Some experiments fail, but the way to push forward and learn is by trying something that has uncertain results. 
  • Aligned timetable - All events that start together, end together. As a participant I like this a lot, since I don't have to weigh a long event against two shorter time-slots. Having to choose with a ratio of one-to-one is difficult enough. 
  • Conference party - Twice makes a tradition. It's a great way to meet and talk with people without having a cool event that is starting in five minutes, and it's an awesome way to help people who are more shy to actually meet others and have fun in the evening. Spending an evening together is by far better than finding dinner alone and going to sleep early. Having the party for the whole conference means that everyone is welcome, and no one gets pushed aside.
  • Breaks between talks - Initially, I thought there wasn't enough time between the talks, but then I looked again at the schedule - there was a very good break time after each talk, and it's only because I was having fun that the break time flew by. So great time, and great breaks. 
  • Collecting feedback - The retrospective by the end of each day, the cute app to mark satisfaction from the talks - The organizers are constantly trying to improve, and every participant can add something to that. I simply find this cool. 

Sunday, February 12, 2017

ETC 2017, day one,two & three

(Short summary - ETC was super awesome, down below are my experiences from the conference days)
Previous: ETC2017 tutorials day

Another day of ETC has ended, and shortly after it, the end of the second followed, and despite my best intentions, I could not get a blog post in between the two.
The first day was, to say the least - packed. Starting with a great opening keynote (slides) from which I took two takeaways - unit tests can catch as much as 77% of "production failures" (source), and dead code can sometimes be worse than you might have thought.
Following the keynote, I attended a real inspiring talk by Rosie Sherry, about marketing the testing community and activities (by the way, if you are not familiar with ministry of testing, please correct that).
After the speed meeting (which was a bit too shallow and quick to my liking), I had some interesting talk with Bettina Stühle about a difficult client she was working with and what are her goals and approaches, followed by a short chat with Adina & Nicolai on JUnit5.
Then I ran to the exploratory testing workshop - which proved to be a great fun, and while doing that managed to show me some good pointers I need to pay attention to while testing. Shortly after that (we did have some time to grab a cup of tea), came Joel Hynoski's talk that was titled "Engineering for quality: using brain power rather than willpower", which was "quite good, but..." - In retrospect, the talk was presented well, and I like both Joel's style of presentation and the topic he chose, but that's not what I have expected from the schedule. Neither the title of the talk, nor the track it was on (automation) nor the description that can be found in the website had any resemblance to what was actually presented - I came to this talk expecting to see how tools were used in a smart way that I can learn from, and got a story that was "so, we did this and it worked nicely". There was no dwelling on "how to look for an idea that will work for you", not a glimpse on "how the automation is built", there was "we did some gamification around code submits", which was a cute anecdote, but I did not see how it connected to a coherent & clear message.
Anyway, as Zelazny once wrote - shift happens. By the end of the talk we shifted to a lean coffee session that was pretty much as expected - a great fun and an opportunity to meet some new people, and talk with people I already met.
At the end of the conference day, Nicola Sedgwick spoke about communication, and space, and prioritising, and setting expectations, and cheating on sports apps, and estimating with multi-faceted dice and people in chainmail working together. Or, if one wants to put all of that under a single title - getting inspired by whatever is around you and learning from it. A really hard talk to follow, but the message is getting around almost unconsciously.
That was the end of the conference formal schedule for day 1. Naturally, this only mean that the other activities just begin. On the way to the conference party, I had a really nice dinner with Kira & Bettina, and then we proceeded to the party itself, where we joined a whole bunch of people and had a great time.

Day 2 began pretty much similar to day 1 - I woke up to late to actually complete a blog post (that I stayed up to late to write after returning late to the hotel since I was having such a great time with people), and if the first day has been very good, the second was nothing short of awesome.
It started with a powerful keynote from Gitte Klitgaard where she got everyone to dance, which every bit of fun as it seems. Next was Adi's demo talk about different kinds of automated tests where he delivered a clear view of how to write good tests and what target each of them is useful for achieving. Plus, he showed some of the cleanest pieces of code I've seen (so, I have some refactoring to do in my code to start practicing writing like that). Following this - a great talk by Matt Lavoie on usability testing which was point on (for those keeping track, that's 4 great talks in a row). This one was followed by a talk by Liz Keogh, which, besides being an extremely talented speaker, is the first person I've seen speaking on the Cynefin model in a useful way. and despite a strong initial objection to her message (that there's an inherent difference in the way testers and developers think of things),I find myself pretty convinced (more on that will probably be in a separate future blog post). it's not often when I can hear my jaw dropping in a talk, but this was definitely one such case.  After that I went to hear a security talk given by Juha Kivekäs which was very well presented. However, since software security is a field I'm interested in and have some basic background, I found out that I'm not the proper audience for it. I activated the rule of two feet and went to hear Alex Schladebeck's talk on how to build proper UI automation. Listening to the talk was very hard on me - just about every other sentence I felt an urge to stand up and clap out load, since she was carrying a message that needs to be heard more often, and she has delivered this message far better than I could have done. Speaking later about this with Neil, he put it up to a very concise sentence - people are telling testers they need to code, but not enough are telling testers they need to code well.
After such a successful row of talks that were not simply good but rather brilliant, it was time for open space. Inspired by Joha's talk I offered people a quick introduction to using a web proxy. In the previous evening I downloaded OWASP Security Shepherd and we played with it a bit. Just to make thinks easier on the audience, I used Fiddler, and not one of the more powerful attack proxies such as ZAP or BURPsuite, since it has a much easier UI (and less options to confuse new users). We got along with some exercises and got to play with some XSS as well in a sort of a mob participation (There was only one driver, though). After this session, I went to participate in a proper mob programming exercise where we tried to learn a bit of Kotlin. Well, we had some environment issues, both on the Kotlin side, and in using a German keyboard on a computer that forces you to use shortcuts if there are any. Well, we didn't manage to have some code running by the end of the 30 minutes, but we did practice mobbing, and did learn quite a bit on how does mobbing work, and a little bit about Kotlin. Plus, I enjoyed myself.  The next topic on my schedule for the open space was another one I proposed - tools as eye openers. Sadly, no participants came, but with all of the other great subjects that were happening at the same time, I was just as happy to become a butterfly and hop over some discussions - I joined Sharanya's discussion on the difference between functional and integration tests, where I felt I had something to contribute (especially after Adi's talk earlier), and when this discussion came to conclusion I listened silently (or at least, I recall that my intention was to be silent) to a discussion on mobbing, what it's used for and how to present it at home. It was interesting.

It's only appropriate that such an intense day will be closed with a powerful keynote by Fiona Charles who spoke on the future of testing (TL;DR - the future is our to make).

And we all know what happens when the conference talks end, right? I looked for someone to have a dinner with, and talked with Bettina who said she was meeting one or two others and invited me to join. and so we went, 20 people strong, to have something nice to eat in a quiet place. After that we went to have a drink and talk some more, up until the point where I knew I must go to sleep.

Day 3 (for those who keep track, yes, it was a two days long conference, and the tutorials were day 0) was to be a more relaxed day of touring the city for a while. My heuristic for making the day fun was simple - Join Bettina who seemed to know what to look for. We strolled through some parts of the city and visited the architecture and design museums (which are two, close and small museums) and had some time to talk and enjoy.
After getting back to the hotel and resting for a while, it was time for dinner. So I messaged Neil, who was still in town, and he was just on his way to find something to eat as well, so we met, and he contacted one of the other twitterati and so we found ourselves walking for ~20 minutes to meet some others. as happens quite a lot for me in such events, I got to listen to some quite interesting stories (at one point Joep explained some of the peculiarities of Belgium's political system) and at some point we were all (or at least, those of us who remained at the time) listening to Maaret and Llewellyn speaking with Damian who's part of the team organizing QA or the highway, about conference organizing and explaining some of the choices they made and the priorities they have. Occasionally one of the others had some idea or experience to contribute, but for me it was mainly listening to what happens "behind the scenes", which was fascinating. For me, hearing the principles that are in the base of this conference and learning how the actions and choices of the organizers match those principles enforced a very important feeling - I was happy to pay for a conference that takes such great care of their speakers and that emphasises so strongly on making everyone feel welcome and providing opportunities to actually meet people and not only listen to some talks.

And so, the conference is at end, I extended it as much as I could (meeting Joep, Gitte,Bettina and Damian for breakfast at the hotel, and then sharing a cab to the airport with Joep), but all good things must end. I had a great time, and absorbed quite a lot (some of which, may form after processing to something I can share clearly enough back at home).
See you all again next year in Amsterdam!