Sunday, May 7, 2017

My problem with the screenPlay Pattern


Like anyone who is even remotely interested in Selenium, I too heard about the new emerging "Screenplay Pattern" (you can read about it here, or watch this talk) and took some time to consider it. My first reaction was "I think it's a bit silly, writing all of this for no gain at all", then "It looks like more overhead and duplication than I currently have with page-objects". And then I forgot about it.
In Selenium Conf UK (2016) Antony Marcano gave a talk about it which I watched just since it was well presented, and I wanted to see if I could figure out why is there so much fuss around this pattern. It turns out that the screenplay pattern is simply branded incorrectly, and presented as a (complex) solution to a problem that should be solved in a simpler manner. Apart from that, though, it is a really useful tool to have in my utility belt, after fixing the fundamental flaw it has, of course.
To put things simply - The screenplay pattern is not a good substitution for decent page-objects and, in fact, should co-exist with them.
If you read my previous posts about "page-objects are not enough" (pt.1, pt.2) then you might have noticed that I advocate for a layered infrastructure for your automation. Personally, I see three layers that are really needed (Alex Schladebeck is splitting it to 5 distinct layers, which might be a good idea, depending on your context). The three layers I need are: Tests, Business actions (or "flows") and atomic actions.
The atomic actions are stuff like "click on the 'next' button" or "select all users from the database" (In Alex's model, there's a lower level layer which will do "click on something" or "run this SQL query" - a layer very important if you have multiple technologies to drive your actions).
However, atomic actions are not really helpful for your day to day test, so the second layer is created - the business actions. Here you'll find stuff such as "add a new user", "change password" and so on. Business actions are the place to put the context knowledge in - today logging in requires a username and password. Tomorrow it might require an one-time-password sent by SMS. the business action is the place to invoke the specific atomic actions that compose the actual action (Again, in Alex's model, this is split into two layers - internal and external. I think it's nice that she made this distinction, I don't think it's crucial in my context).
Finally, there's the tests themselves - They should be calling the flows layer, and even though some atomic actions might be used for assertions, as a rule of thumb - test methods should not be calling atomic actions themselves. When it get's to UI actions, this rule is more strict - your test should not contain any selenium code or any page-objects (the same is true for any sort of technology you might be using to drive your UI).

As I hope it's easy to notice - the screenplay pattern fits very nicely to that middle layer. Clear business actions that hide the actual steps taken to perform them. I can think of no reason not to include page objects within the screenplay actions, thus separating "how do I interact with an element" from "which elements should I be interacting with?"
This brings me to another point that was touched upon in Anthony's talk - Bloated page objects should not exist.
By separating the responsibility (the "which" from the "how") , most of this is solved - a page object should contain only the elements in it and a way to interact with each element. Perhaps we might go as far as aggregating filling up an entire form, but anything more complex than "login" should be dealt with in the flows layer. By doing this and keeping the page-objects representing small pieces of the UI , no large classes are created, and the flows layer (where the screenplay pattern is really helpful) remains clean and without unnecessary duplication when two actions go through the same pages.


כמו כל אחד שמתעניין קצת בעולם של סלניום, גם לי יצא לשמוע על הדבר הזה שנקרא screenplay pattern (אפשר לקרוא על זה כאן או לצפות בהרצאה הזו) ועצרתי לחשוב על זה. תכל'ס? התגובה הראשונה שלי נעה בין משיכה בכתפיים לתהייה בשביל מה צריך את כל התסבוכת הזו - נראה שבמימוש סטנדרטי של התבנית הזו אני אסיים עם שכפול קוד משמעותי יותר מאשר יש לי כרגע עם page-objects. נו, מילא. קראתי, סיווגתי, המשכתי הלאה. 
בשנה שעברה, בכנס סלניום, Antony Marcano העביר הרצאה על התבנית הזו (נו, אותה הרצאה שקישרתי אליה שם למעלה), וצפיתי בה, בעיקר כי הוא העביר אותה היטב, אבל גם כי רציתי לראות - אולי אצליח להבין מה ההתלהבות הגדולה מסביב לזה. 
ואכן הבנתי משהו - כל סיפור התסריטים הזה (בפוסט הזה, לפחות, אשתמש ב"תסריט" במקום screenplay, כי זה נוח יותר להישאר בעברית) פשוט משווק לא נכון ולכן מציג פתרון מסובך לבעיה שעדיף לפתור באופן פשוט יותר. אבל חוץ מזה? נראה שהתסריטים הם משהו שכדאי להכניס לארגז הכלים שלי - אחרי שמתקנים את הפגם היסודי שבהם. 
בפשטות - התסריטים אינם חלופה טובה לpage objects בנויים כהלכה, וקל וחומר שאינם "הדור הבא" שלהם. למעשה, התסריטים צריכים לדור איתם בכפיפה אחת. 
אם יצא לכם לקרוא את שתי הרשומות שלי על page objects are not enough (חלק א', חלק ב'), בטח שמתם לב שאני ממליץ על אוטומציה שבנוייה בשכבות. בפרט, אני נוטה לחשוב על שלוש שכבות נפרדות (Alex Schaldebeck מציעה חלוקה לחמש שכבות שונות, מה שעשוי להתאים לפרוייקטים מסויימים). שלוש השכבות שלי הן שכבת הבדיקות, שכבת הפעולות העסקיות ושכבת הפעולות האטומיות. 
הפעולות האטומיות הן פשוטות - לחיצה על כפתור "הבא", שליפת מספר המשתמשים ממסד הנתונים. דברים כאלה (אצל אלכס יש שכבה בסיסית יותר בה יופיעו "לחיצה על אלמנט" או "הרצת שאילתה מול מסד הנתונים" - שזו שכבה חשובה מאוד אם יש לכם כמה דרכים לבצע את אותן פעולות אטומיות בסביבות שונות). 
עם זאת, פעולות אטומיות לא ייקחו אותנו רחוק מאוד - ולכן נולדה השכבה השנייה - שכבת הפעולות העסקיות. לפונקציות כאן כבר יש משמעות בעיני המשתמש. זה לא "לחץ כאן" "מלא את השדה הזה" אלא "הוסף משתמש חדש" או "החלף סיסמה". הפעולות העסקיות הן החלק בו נשים את הידע המוצרי - איך עושים דברים. הרי היום כניסה למערכת דורשת שם משתמש וסיסמה, אבל אולי מחר הכניסה תתבצע בעזרת סיסמה חד פעמית שתישלח במסרון. הפעולות העסקיות הן המקום ממנו נקראות הפעולות האטומיות, והן המקום בו מוגדר מה הפעולות האטומיות שצריך לבצע כדי להשיג תוצאה ספציפית (שוב, במודל של אלכס זה מפורט יותר ומחולק לשתי שכבות - חיצונית ופנימית. זו אבחנה שכדאי לעשות, אבל אני חושב שהיא פחות קריטית ברמה העקרונית). 
לסיום ישנה שכבת הבדיקות - כאן נכתבות הבדיקות בעזרת הפעולות העסקיות. למרות שניתן מדי פעם לקרוא לפעולות אטומיות לצורכי אימות (assertion), כלל האצבע הוא שהבדיקות קוראות רק לפעולות עסקיות.  כאשר מדברים על אוטומציה של UI, הכלל הזה צריך להיאכף בקפידה  - בבדיקות לא אמור להיות קוד של סלניום, או של page objects (והדבר נכון לכל טכנולוגיה בה אתם משתמשים כדי לגרום לממשק הגרפי לזוז). 

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

Tuesday, April 18, 2017

שתיים ועוד שלוש הן חמש

Two plus three is five

Source: Every conversation between a parent an a child in four conversations (link in the text)
- אני יכול את זה?
- לא? 
- אולי לא הסברתי את עצמי היטב, ביקשתי כי אני רוצה את זה. 
- למעשה, הבנתי.
- אולי אינך שומע אותי היטב, אני רוצה את זה.
הקטע הזה ממשיך עוד קצת (והרבה יותר מוצלח בלי התרגום החובבני שלי) ואפשר לקרוא את כולו כאן (ומשם גם התמונה בראש. לאחרונה אני נזכר בטקסט הזה לא מעט. 
ואיך כל זה קשור לתוכנה? זה לא סוד שיש לפעמים פערים בתקשורת בין מהנדסים לבין האנשים שמנהלים את הצד העסקי של הדברים - אנשי מכירות, מנהלי מוצר וכדומה. הפערים הללו מתבטאים לרוב בדרישות מורכבות, לוחות זמנים בלתי אפשריים או סתם בקשות חסרות פשר. בערך כמו שקורה למומחה הקווים האדומים (וכן, גם בסרטון הזה אני נזכר לא מעט, באותו הקשר). 
בעבודה, יש לנו פרוייקט חדש. יש לו תאריך סיום שלא אנחנו קובעים, קצת כמו שתעשיית המשחקים לא קובעת מתי בדיוק תגיע עונת החגים. הפרוייקט היה צריך להתחיל לפני הרבה זמן אבל בגלל עומס של דברים דחופים לא פחות, לא באמת התחיל לזוז עד לפני חודשיים-שלושה. במהלך הזמן הזה, הקדשנו המון זמן לישיבות אינסופיות בהן מנהלי המוצר ניסו להבין איך אנחנו יכולים גם לא לאחר בשנה וגם להכניס פנימה את כל התוכן שאנחנו רוצים. תוכניות נכתבו, שעות הושקעו בהערכת מאמצים, מדי פעם נערכו כמה חשבונות בסגנון "אם נשים עשרים אנשים על הפרוייקט, נסיים אותו בתוך תשעה חודשים" (מה שהזכיר לי את הבדיחה על מנהלי פרוייקטים והריונות), מה שהוביל לכל מיני משחקים בהם עובדים חדשים הופיעו יש מאין, משל היינו בתרגיל צבאי ומנהל הפרוייקט הוא השליש שמשלים את מצבת הלוחמים במטה קסם, תוך התעלמות מוחלטת מכך שלוקח לנו לפחות שלושה חודשים לאייש משרה.
בקיצור, למישהו היה כיף, והמישהו הזה לא היה אני. אבל, סוף כל סוף, נגמרו הקשקושים ואפשר לומר שאפשר להתרכז בעבודה ולא בתכנונה. ואז, במסגרת אחת מישיבות העדכון, מנהלת המוצר הודיעה על שינוי כיוון - אחד הספיחים לפרוייקט הזה הוא שיתוף פעולה בינינו לבין חברה אחרת, ושיתוף הפעולה הזה אמור להכניס לא מעט כסף לכל הגורמים המעורבים. כל התוכניות שנעשו עד כה הניחו שאנחנו יכולים לסמוך על כך שסיימנו את עיקר הפרוייקט הראשי ולהשתמש במה שנבנה שם, מה שמיקם את הספיח במרחק יפה על לוח השנה. ובכן, שינוי הכיוון היה כזה - הנהלה החליטו שאנחנו רוצים את הספיח מוקדם ככל שאפשר. רגע, מה? זה אומר שכל העבודה שצריך לעשות לפרוייקט הראשי ונדרשת כדי לתמוך בספיח צריכה להיעשות קודם. כלומר, כל מה שחסכנו הוא חודשיים או שלושה. תגובת מנהלת  המוצר הייתה פשוטה, ומרגיזה להחריד - "זה לא מספיק טוב, אני צריכה תוכנית שתאפשר לנו להעלות את זה לאוויר בתוך חודשיים מהיום". אוקי, אנחנו מכירים את המשחק. בטווח של חודשיים לא רלוונטי לדבר על תוספת משאבים, ואם התאריך נעול, כל מה שנשאר לדבר עליו הוא על התוכן. אבל גם על התוכן אי אפשר לוותר, כי את כל הוויתורים כבר עשינו כשהגדרנו את הפרוייקט הראשי. בכל זאת, בדקנו - "האם את מוכנה לוותר על א'?" "לא". כך גם לב' וג'. בקיצור - איך שלא מסובבים את זה, הבקשה היא לדחוף תשעה חודשים קלנדריים (לא חודשי אדם) לתוך שלושה. התגובה לכל הסבר שמצביע על הפער הזה הייתה "אז תעשו משהו מהיר ומלוכלך" (עד לנקודה בה אחד המפתחים הסביר שאנחנו אמנם יכולים לכתוב את הקוד מלוכלך יותר, אבל יותר מלוכלך ממה שכבר מתוכנן לא יהיה מהיר יותר).
אני יצאתי מתוסכל מאוד מהישיבה הזו, מקטר ביני לבין עצמי שזה לא משנה אם סופרים שתיים ועוד שלוש או שלוש ועוד שתיים, ואפילו לא שתיים ועוד שתיים ועוד אחת - התוצאה תמיד נשארת חמש ולעולם לא תהיה ארבע.

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

Child: Can I have this?
Me: No.
Child: Ah, perhaps I’ve miscommunicated. I’m asking for it because I want it.
Me: I understood that, actually.
Child: I think maybe you’re not hearing me. I’d like it because I want it.

This quote is from a longer text that goes on (and gets funnier), which you can read here. Lately, I'm reminded quite often of this text. 
And what does it have to do with software, you wonder? Well, it's no secret that there are sometimes gaps between engineers and business people - salespersons, project managers etc. . Those gaps often manifest as complex requirements, impossible timelines of simply senseless requests, as is happening to this poor red lines expert (yes, I'm reminded of this video as well, in the same context). 
We have a new project at work. It has a deadline that we do not set, in the same manner that the gaming industry cannot move holiday season just because the game is a bit more complex to build. Worse - this project should have started quite a while ago, but a load of other urgent tasks didn't actually begin to move until about three months ago. So, what's the first thing to do when you start a project late? Naturally, begin with a month-long estimations and planning phase. Ok, I'm being a bit over-sarcastic here, as the planning was quite important for us to know what we actually need to do, and start having a discussion about what must be released in the first deadline of the project and what can wait a bit, so there was value to it, but it was just so annoying to go through.  During those endless meetings, the product management goal was to understand how can we get all of the content that we need and not miss our scheduled release date in a year or certain times there were some calculations such as "if we'd put 20 people on the project, we could be done in 9 months". This reminded me the joke about project managers and child bearing and then I was reminded of some war-games where dead or injured soldiers are magically replaced by other troops when the discussion started guessing that we could assume we'd recruit three new employees within the next couple of months, ignoring the history (in which finding a suitable candidate usually takes us between 3 and 6 months during which the effectiveness of the employees interviewing drops sharply).
So, to state it simply - someone was having fun, and that someone wasn't me. But, finally, we got to the point where we can shift our time and focus from talking to doing. great. Then, during one of the update meetings the project manager announced a change of direction: One of the side tracks to this project was another sub-project that depended on many of the capabilities in the main project. This  sub project is a collaboration between us and another company, and should produce a nice revenue to all involved parties. So, instead of waiting until the main project is done, now we want to have the sub-project done as quickly as can be, so all of the work that had to be done in the main project and supports the sub project now have to be done separately and all that we would save is probably two or three calendar months. The product manager's response was simple and frustrating: "This isn't good enough, I need a plan that will enable us to go live with this in a couple of months". OK, we know this game - it's the triangle of resources\time\content.  Since it's a schedule of 2 months, adding people is not really an option, and the time is set, so it must be content. However, we already cut content to a minimum when defining the main project. Still, we asked "Are you willing to give up on A?" the answer was "no, we must have A", and the same went for B and C. In short, we were asked to find a way to cram some 9 calendar months into 3. Doesn't really matter how you do the math, it does not work. Any attempt to explain this was met with the response "just do something quick and dirty". This phrase came up so many times in the conversation that one of the developers reacted with "we can do it as dirty as they want it to be, but at the point we are, dirtier won't be quicker".
Personally, I got out of this meeting feeling very frustrated and ranting to myself that two and three is five, as is three and two, and even two and two and one - it does not matter how you count it, it won't stop being five.

But, later that day something interesting happened. After we were done ranting and got used to the fact that this new requirement is the reality - we need to do something in three months, what can we suggest?  - we came up with a solution: it solves only part of the problem, and it depends in our partner's capabilities and goodwill, but we can do it in a single month. We have something management can work with.
This made me think - It's really easy  to rant about how management knows nothing, It's easy to be annoyed with impossible schedules. But the whole purpose of a delivery team is to find solutions to problems. Those won't always be perfect or complete (or on schedule), but they are still good solutions. Sometimes, that little annoying brat who says "I want it!" and won't take no for an answer is what needed to nudge the team to find a solution.

Also, on another note - you people who preach #NoEstimates , how do you cope with projects of this size that have a deadline and you need to know whether or not you should recruit more people? If there's something these last months convinced me it's that I really don't enjoy estimating stuff. I would love to hear of another way of dealing with this problem. 

Wednesday, April 12, 2017

מה אני מחפש אצל מועמדים

What do I look for in a candidate

This post is written after James Thomas, who has a fascinating blog of his own, commented on this post and pointed out that I did not mention what I was looking for when interviewing candidates, and why. And, since to the best of my knowledge, James does not read Hebrew, I'm starting this post with the English version. 

Generally, we are trying to get an understanding about the following points:

  • Testing skills
    • System-wide view\ understanding
    • Technical affinity
    • Asking questions and questioning authority. 
    • Identifying context and understanding what does it mean for testing. 
    • Risk awareness (and tendency to spot risks)
    • "Thinking on your feet" 
    • familiarity with testing theory & terminology. 
  • Programming (roughly at the skill level of a university graduate)
  • Interpersonal skills
  • Career goals
      Each of these points can be broken down to smaller parts, and in some cases, those parts can be broken down again. And breaking those definitions is exactly what I'm about to do.

      • Programming - probably the easiest thing on this list to explain. We expect the candidate to be able to write code, we don't care in which language. We look for the ability to come up with algorithms that solve simple problems, some basic understanding of data structures, good coding habits (e.g.: meaningful names, division into functions) and while it's not a must, we sometimes also try to see if the candidate has some idea about what is happening in the memory below the code (not registers and assembly language, just an understanding of the stack, heap and garbage collection).
        Why are we looking for that? In short - because we use programming in our work. No, we are not "automation engineers", but we do write automated checks in a framework that we built and maintain (and I'm even somewhat proud of). Learning to code on the job is possible, but it's way too expensive for us to accommodate that. In addition, formal learning in this case will be more thorough and cover the things you need only once in a blue moon, but we're long past the point where one needs "just enough programming to manage", and a decent theoretical base is always helpful. Sure, one does not need 10 years of programming experience to work with us (in fact, universities graduates might  fit well), but sometimes there are problems that require some investigation and fiddling around. In a team as small as ours, we don't have the luxury of having this task within the skill-set of only part of the team. 
      • Interpersonal skills - A bit undefined, and can be roughly translated to "how much we like you". We look for people who are pleasant to talk with, won't cower in a corner in face of a loud voice. Into this category comes also the ability to explain oneself, to accept criticism and just about a million other things I can't exactly name, but can tell when they are missing.
        Why are we looking for that? First of all, because we look for people we would want to work with. I don't want to work with people I feel unpleasant around, so if I can affect that - I will. Secondly, because as testers, our work is all about communicating with others, so a candidate better not be horrible on this account. Third, and most importantly - We are quite of an aggressive team. We have some people in the team who respond fast and think while talking - which might push aside the more timid team members. Like it or not - and until we manage to change that - timid people will be run over, so when we assess the candidate fit for the team, this must be a parameter, even if it's only so that we'll know how much protection the candidate needs. Candidate who can hold the conversation when there is some cooperative overlap (I found this term here) and will not let themselves be pushed aside when the overlap becomes a bit competitive, will have easier lives in our team. One need not posses the glib tongue of a lawyer or a salesperson, but we prefer candidates who can join our team painlessly. By the way, this is more important for female candidates who will face unconscious gender bias on top of the general pushiness. 
      • Testing skills is a title for a long list of possible skills, and everyone has a slightly different definition of what it actually is. It's also an umbrella term for stuff we don't have anywhere else to put but deem important for a tester - stuff such as professional pessimism, familiarity with different kinds of testing (there's very little in common between performance testing to localization testing, despite the fact that both are "testing").
        Within this list, we try to focus on the following:
        • System-wide view: There are two ways in which systems can be understood: bottom-up, in which one learns all the fine details and slowly constructs the whole, and top-down, in which one learn how things are connected and what is the role of every part, and only later fills this schematic with details. The added value of testers is usually in putting the new feature in context - who will be using it? what other parts are affected? and so on. A person who learns in a top-down manner will probably have it easier to provide this kind of value, but in the end, it's about being able to see the system and zoom in and out as needed: if someone is very comfortable in the high-level descriptions, we'll drive to more technical details. If someone's very keen on the details, we'll push for a higher abstraction level. 
        • Technical affinity - Be as it may, we are testing software (or hardware), which is something technical. A tester should not be afraid of it, and should understand how computers work instead of regarding to it as magic. In addition, when something stops working, we dive into it and investigate, and this requires technical skills.
          (Also, if you're using "technical" as a euphemism for "knows to code", please stop. Thank you.)
        • Questions in face of authority: I hope I don't have to convince any of the readers that asking questions is one of the most important things testers do. The authority part is no less important. We ask questions that people don't like to hear such as "are you certain you want to release with this unfixed?" and sometimes we just call other people's baby ugly with questions like "will your solution still work when five people click on the button simultaneously? " There's always some sort of pressure against such questions, especially close to a release. A tester should not be too much intimidated by such pressure, and leave a question unasked only when there's a decent professional reason for that. Also, good questions that are based on understanding the system can save a lot of time and effort to everyone. 
        • Identifying context: This one's simple. We don't test everything the same way, and we don't test the same thing in the same way on a different project. Being able to justify our testing and prioritize them is important. A tester who can do that with no context is reading from a manual that was never relevant. 
        • Risk awareness & tendency to see risk: It's an extension to the previous bullet. Risk is what drives testing. If there is no risk, there's no need for testing. It also provides us with language to communicate with other team members - "I'm going to invest three days on this, since a minor defect will cost a whole lot of money, while no one will really care about the typos and spelling mistakes in the help file, so I'll go over it only if I'm really bored").  
        • Thinking on your feet: In many cases, a tester need to provide a quick response. For instance, if someone raises an idea during a design review meeting, the best time for a feedback would be right then, not after a week of analysis. In fact, in most situations I can think of, saying "here's my initial thoughts, and it seems to me that there's a week of analysis that can be done here to find out what I've missed" is by far more useful than "oh, really? Gimme a day to analyze and I'll tell you what I found". 
        • Familiarity with testing theory & terminology: Well, that's usually a probe to see if the candidate is familiar with some of the basic terms found in the ISTQB syllabus, maybe the difference between testing & checking or the ability to hold a short conversation about "why test?". Having a common language enables passing information precisely and concisely, but it has another aspect to it - behind each such term there's an idea. Once something has a name it can be easily recalled and used. Boundary values, for instance, is a really simple idea (which doesn't mean it's shallow) - but it's not something one will necessarily think about if they never heard of it before.
          In addition, being familiar with the jargon is a good indicator that the candidate is learning testing in some ways. There isn't anyone who is interested in testing and did not encounter some basic terms such as equivalence partitioning or a test oracle. From the experience I gained thus far, it seems that candidates that are not actively learning are not familiar with such terms. Sadly, it's true also for people who have recently bought their ISTQB CTFL certificate (and I say bought since learning or earning was clearly out of the question in their case. They passed the test, probably without cheating, and they didn't learn a thing).
        Why are we looking for that? Because we are hiring testers. Because we don't know how to teach stuff such as "system view" and while we can help people learn to stand their ground, it's not a short process, nor it is perfect (or fun to all involved parties). To put it simply - we are looking for employees, not offering training. We will be happy to hire inexperienced people, but they have to show us that they did the first steps themselves (or have some natural affinity to the testing mindset) to convince us that there will be value in investing in training them. 

    • Career goals: Here we try to guess whether the candidate is regarding software testing as a profession.  We try to understand what are the short term career goals of the candidate, and ask about the long term ones (we don't usually ask about the short term goals, since it's an invitation for a lie).
      Why are we looking for that?
      Two reasons: The first and only one that matters is that we have a long ramp-up period. Our product is carrying over fifteen years of history, and is quite complex. Usually we consider the first three months as pure training time, and don't really expect an employee to be highly effective in the first year. If a candidate will ask to switch role after a year (or worse - leave in favor of another place), we invested a lot and got little in return. Additionally, employees that are interested in testing will be more open to acquiring new skills in this domain. Employees that want to use testing as a stepping stone towards a different role will try to acquire skills that are relevant to that role.
      We ask for the long term goals for two reasons: One is to gain insight for the short term goals. The other is to see if we can accommodate such goals - Not everyone can be a manager, and if someone is keen on accessibility testing, there are better places for them to be in. A candidate that can only see progress as "becoming a manger" might need some guidance to find other options (unless specifically recruited to become a manager) in comparison to someone who is familiar with the technical career paths that are out there.
      The second reason is  a matter of ideology. I see testing as a profession and not as something temporary to do in order to "get into high-tech", or because someone lacks the skills to do what they actually want to do. I prefer to work with people who share this view. 

    • ------------------------------------------------------------------------------------------

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

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

          מותו של הבודק הידני

          Abolishing manual testers


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

          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


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

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

          הגעתם לראיון איתי? זכרו שזה אומר שאני מאמין שיש לכם סיכוי להתקבל. זכרו גם שאני רוצה שתעברו את הראיון. הנה כמה דברים שכדאי לכם לעשות.
          •  שאלתי אתכם שאלה שאתם לא בטוחים לגביה? יש מעט מאוד דברים שיגרמו לי להעריך אתכם יותר מאשר האמירה "אני לא יודע\ת". אם שאלתי אתכם שאלה על איך מנוהל הזיכרון בג'אווה וזה משהו שלא למדתם אף פעם, אני ככל הנראה שואל כי אני רוצה לדעת מה אתם יודעים ומה לא, או כי אני מנסה להוביל את הראיון לנקודה מסויימת. אם אתם לא יודעים, אני אספר לכם את מה שצריך לדעת ונמשיך הלאה. אם תנסו לנחש ולזרוק מונחים חצי קשורים, אני אאבד את ההערכה שיש לי אליכם. 
          • גם אם אתם בטוחים - שאלו שאלות. לדעת לשאול את השאלות הנכונות ולהתאים את עצמכם בהתאם לתשובות הוא כישור חשוב לבודקי תוכנה (ולכל מי שעובד עם הראש). ביקשתי מכם לבדוק עיפרון ואתם מתחילים לפלוט מקרי בדיקה בלי ששאלתם אותי אם, במקרה, מדובר בעיפרון איפור? חבל.  בעולם בו יש כל כך הרבה מה לבדוק, אני רוצה לראות איך אתם מתעדפים את הבדיקות שלכם, ואתם לא יכולים לעשות את זה בלי לשאול שאלות. למעשה, אני מנסה להבין עד כמה אתם טובים בשאילת שאלות וחלק מההנחיות שלי מעורפלות בכוונה.  
          • אם אתם מגיעים לראיון איתי, אל תטרחו להתאמן על "איך לבדוק עיפרון", אני מראיין אתכם למשרת בודק תוכנה, לא למשהו בעיצוב תעשייתי. אם אבקש מכם לבדוק משהו, הוא יזכיר קצת יותר את הדברים שאפשר למצוא ביום עבודה סטנדרטי. 
          • בתחילת הראיון אני אבקש מכם לספר לי על המקום האחרון בו עבדתם, או על פרוייקט שעשיתם בלימודים, או על קורס שמצא חן בעיניכם - אני מנסה להבין עד כמה אתם מבינים פרוייקטים טכנולוגיים ועד כמה אתם מסוגלים להפריד בין עיקר לטפל. אני אבקש מכם לתאר את המערכת בכללותה, או לצלול לפרטים - אני מצפה שתדעו להסביר מה עושה המערכת ומי משתמש בה, איך מידע עובר ואילו רכיבים גדולים נמצאים במערכת. כשאני מבקש לרדת לפרטים הקטנים, זה לא כי אני מנסה להשיג מידע על המערכת, אלא כי אני מנסה לדעת כמה לעומק אתם מכירים אותה. רוצים להתכונן לשאלה הזו? ודאו שאתם מסוגלים לצייר תרשים כללי של המערכת ואז לבחור באקראי חלק של הציור ולהרחיב אותו עוד רמה או שתיים פנימה. שימו לב שאתם לא מספרים לי על פרטי פרטים כשביקשתי מבט כללי, ושאתם לא עונים תשובה כללית על בקשה שלי לפרטים טכניים.
          • דעו להגן על העמדות שלכם - לפעמים אני אשאל "למה?". בחלק מהמקרים, זה כי אני חושב שעשיתם בחירה לא נכונה. בחלק אחר, כי אני רוצה לדעת האם אתם פועלים מתוך הרגל או שאתם יודעים להסביר את הסיבות לפעולות שלכם. לפעמים אני רוצה לראות איך אתם מגיבים כשמקור סמכות (המראיין, במקרה הזה) מפעיל עליכם לחץ.
          • אם עשיתם טעות, זה לא אומר שנכשלתם. כמו "לא ידעתי", גם "נכון, טעיתי" קונה לכם נקודות זכות. אני מודע היטב לכך שהראיון מלחיץ, ושאתם רק אנושיים. מותר לטעות. 
          • קורות החיים שלכם יוצרים ציפיות. כתבתם שיש לכם "הסמכת 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.