מותו של הבודק הידני Abolishing manual testers

 https://s-media-cache-ak0.pinimg.com/736x/94/6c/c7/946cc7383075dc6f3e645a5e27b0d794.jpg

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

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

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

At the last testing meetup I raised a subject that bugs me for some time now - it's time to stop using this nonsensical term "manual tester". It's a dinosaur that should have long been extinct. No, I'm not trying to say that all testers should learn programming (I think programming is a very useful skill to have for a tester and would recommend any tester to have it in their toolbox, but this is not the subject here), nor do I want to discuss the question "will testing be assimilated into the developers' role?". My issue is with this specific term. 

Of course, I'm not the first to write something on the subject and probably not the last, but there's something I want to add: "Manual tester" is a term that should be eradicated from everyone's vocabulary, and software testers should be the first to do so. 

The only piece of information one gets from this term is "I don't write code". There are a lot of skills that testers use all the time - Analysing systems and creating models, assessing risks, using SQL, testing security, performance, UX & accessibility. Testers also use tools that require skill & learning, and it doesn't matter if it's a test tool tailored for a specific hardware or if it's the browser's developer tools. In addition, there are a lot of areas in which a software tester can specialize: A UX testing expert isn't far fetched, right? Neither is localization testing specialist, and we've all met some security and performance testing experts. But what would it mean to be a "manual testing expert"? does this even say anything? 

"Manual tester", the way it is used in today's market, is a term used to describe what a tester does not do. It is both derogatory (would you call a chef who specializes in the Italian cuisine "the chef that does not make sushi"? ) and confining. It is confining since the job description states quite clearly what one is not expected to do. If a person wakes up one morning and decides to learn some coding and apply it in work since it's the reasonable thing to do in a given situation, the reaction of the environment would range between "I thought you are a manual tester" to "are you trying to switch\advance your career path to automation?" If, however, we would have used a more constructive term (such as exploratory tester, functional tester or even simply tester), writing code would not be something marked as out-of-scope but rather what it actually is - one way we can choose to get things done. 

And, if in the process we'll manage to turn the spotlight to the fact that there are some technical skills in testing that are not related to coding skills, it can be nice too. Who knows, maybe we'll manage to remove the almost-as-bad term "technical tester" as well. 

מפגש בודקים - סיכום 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. 

איך לעבור את ראיון העבודה שלי 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. 

How FAR are you willing to go?

http://combiboilersleeds.com/images/far/far-9.jpg

זה קורה לכולם. 

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

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

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

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

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

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

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 failing¹. 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: 

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.