הוסמכת, סרג'יו Ranting on certification

אחת הסיבות בגללה לא כתבתי כאן כבר זמן מה היא שהתכוננתי לבחינת CISSP (שזה, אם ממש מתעקשים, Certified Information Systems Security Professional), אותה עברתי השבוע (אני עדיין לא מוסמך באופן רשמי, אבל את החלק הקשה עברתי). לכל אורך הלימודים וההכנה לא יכולתי שלא לשים לב לקווי הדמיון בין ההסמכה הזו, לבין הסמכה אחרת שמתחבאת אצלי במגירה כבר כמה שנים, הלא היא CTFL של ISTQB.  גם כאן, השימוש במילה "הסמכה" הוא, בלשון המעטה, נדיב, מה שלא מפריע לגוף המסמיך לקשור כתרים לתעודה הזו ולטעון שהיא מעידה על מקצועיות אין-קץ. ההסמכה הזו, למרות המוניטין הקצת יותר מוצלח שלה, לא באמת משפרת את היכולת שלי לתפקד בעולם אבטחת התוכנה ולא חידשה לי שום דבר שנראה לי שימושי כרגע - אולי אספתי כמה מילות מפתח שאוכל לחפש בהמשך אם אכנס לתחום חדש, אבל זה פחות או יותר הכל. גם בתחום חיפוש עבודה (שלא עומד כרגע על הפרק, תודה ששאלתם) אין להסמכה הזו יתרון נראה לעין  - חיפוש באולג'ובס העלה תשע משרות שהכילו התייחסות לCISSP, אף לא אחת מהן קשורה לפיתוח תוכנה או בדיקות. באופן משעשע במקצת, קיבלתי את אותו מספר משרות כשחיפשתי ISTQB (על CTFL, אין ממצאים בכלל). אני מוכן להאמין לסיפורים שסיפר המדריך בקורס על חברה שאיבדה עסקה של מיליונים כי הצד השני לא הסכים לדבר עם מי שאין לו את ההסמכה, אבל המצב בארץ לא נראה לי דומה, וממילא - עסקאות של מיליונים זה תפקידם של אנשים אחרים.

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

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

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

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

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

One of the reasons I didn't write here lately is that I was preparing to take the CISSP exam, which I did this week. While preparing, I couldn't help but notice some similarities and dissimilarities with a certificate I already posses - the ISTQB CTFL. For starters, calling either of those a "Certification", in the sense of "testimony of capability" is quite generous. In both cases, the way to pass the test is to memorize some data which might be even correct or relevant, and when choosing an answer based on that data, the test-takers should remember to skew their perception so that the subject of the certification is the number one priority. Passing the CISSP test (note - unlike the CTFL, passing the test isn't enough to be eligible for CISSP), and learning towards it, didn't really improve my ability to work, and it didn't add much to what I know about security. Even when looking at the selfish aspect of opening new job opportunities, this certificate does not have much to offer - There is nothing in my current workplace which requires it (and I know of), and when I reviewed a job posting site and the few openings that mention CISSP are something along the lines of "we are looking for someone to configure our firewalls and manage our networks", which is really not what I would look for if I was looking for a new position. 

When I spoke about taking the exam with a friend, she asked me "why bother?" If this doesn't add knowledge and won't find you new work opportunities  - there's really no value in taking the exam, right? 

That's a good question, and one I didn't think thoroughly enough to have an eloquent answer (hence this post). 

My answer is that even if we assume that the certificate itself is useless and adds zero value (which I don't say - I think this certification could be much stronger, but it still has some value for me), I regard having the certificate as as a statement of taking security seriously as a career path. What enables me to regard this certificate as this statement are three main differences between CISSP and CTFL: 

1. The exam is difficult. Difficult enough so that I won't be comfortable attempting it again now, when I am as prepared as I was when I attempted the exam. Certainly, it is not something I would try in a year (or a couple of weeks) from now - when the material learned specifically for the exam will be forgotten. For CTFL, if you want me to take again the test, feel free to wake me up in any hour of the night and I expect to pass it. In any other hour of the day where I'm not sleepy, I can't imagine managing to somehow fail it. 
2. A condition for keeping the CISSP certificate is  to continue learning relevant material - a CISSP must gain a certain amount of CPE (Continued Professional education) each year. 
3. Gaining the certificate requires five years of experience (and vouching from a person that was already certified). A test, even if it is a difficult one and not a multiple choice memorization test, cannot really attest for a person's fit to work. Past experience, on the other hand, can do that to some extent. 

One other difference that I liked less is that when preparing for the exam there was no real learning happening, and considering the wide scope of the material (I'm still dizzy when I think about it) - I don't think there could be any learning process crammed into it. When learning for the CTFL test, I had time to go over the basic concepts and think them through, and force the preparation to be valuable for me. Well, I will have this time of going deeper when I learn to keep the certificate valid (that is, after I will get it). All in all, I'm quite satisfied with making this statement. 

Yes, this. Exactly.

When was the last time you read something and said "This is precisely what needs to be said on this topic"?
It happens occasionally, but it's rare enough. And since I'm a bit busy and not getting to write new posts (hopefully I'll get to it soon), the least I can do is give a (small) shoutout to Albert Gareev's post on the ever annoying question "is manual test dying?"

דיון מתורבת באינטרנט? Having a meaningful online discussion

Last Tuesday, I joined (again!) Tuesday Night Testing for an hour of talking about testing, which was great.

One of the subjects discussed was raised by Andrew Fraser who shared a recent experience he had after posting this blog post and receiving some rather violent comments (I'm assuming they were deleted, or are somewhere in the twitterverse) and wondered whether the testing community is a harsh place,and the discussion went rather quickly to whether it's ok, or what causes this phenomenon. Personally, I was quite happy that I didn't want to register to yet another platform, and that Medium does not allow for non-registered comments, since my initial reaction to that post was "where's my pitchfork?" (Alternatively, there's Randall Munroe's way of saying the same thing).
And the thing is - my personal experience is quite the opposite - blogs that I read are usually a rather pleasant place to have a discussion in (I refer to blogs I read, since this blog has yet to host a disagreement or a lengthy discussion), and I rarely see any harsh comments (that are not quotes from Twitter), Usually, what I see is comments that are to the point and do a fair amount of effort to avoid insulting. The same is true to other online discussions I participate in (such as a forum or facebook, which I try to avoid from other reasons) - Sure, there are the occasional petty quarrels and snappy comments - but they are normally met with a firm response from the other participants.
Somewhere during the discussion (perhaps even at the very start of it), Andrew said something along the lines of "The post was purposely agitating, so I guess I got what I aimed for" (the original statement was much better worded, but the general idea was that the post is written to make people react, and they did so emotionally) - and it seems to me that this short sentence is nailing it all - you get what you give - if you are using a language that agitates your audience, some of them will react in a strong tone, and will feel they can be more liberal about their choice of words. If, however, your tone is more to the point, and you take care to choose your words carefully, people usually react in kind.
So, what can I do to make my blog more inviting and less about mud-throwing? I still want to have discussions, and I love debates where I can disagree with someone, and by the end of the it we still don't agree but learned something new while trying to convince each other.
My honest answer is - I don't know. I can, however, make some guesses that match my experience - as reader, commenter, and occasional blogger.

One of the first things to do is to make sure that I choose a title is either matching exactly the content of what I write about in the post, or one that will not invite people to respond only to the title. If the title can be Tweetted, or if it's infuriating by nature (or even just annoying), people will probably react to it, disregarding the text I worked so hard on writing. Andrew's post, for instance, has a really good point - testers should not assume that they know better, and fighting for every bug to get fixed is more than just annoying, it is sometimes harmful to the business and is actually bad testing. However, he calls this behavior "bug advocacy", and states "Death to bug advocacy" - As a reader, this title sets my entire perspective of the post. I like the idea of bug advocacy, so I read and try to see what exactly is wrong, in Andrew's eyes, in it. Going through the post, I can see that Andrew is using this term to describe something else. Or rather - I see that he's attributing wrong properties to bug advocacy. In other words (and please, don't take this as my actual opinion, I'm trying to put words to an initial emotional reaction) - "this good-for-nothing person I have never met is saying stupid stuff because he doesn't understand a thing". When I read this post and react to it, I am reacting to a "death to..." statement. If, however, the title had less outgoing (say, something along the lines of "bug advocacy, is it actually a bad thing?"), my whole approach would be less aggressive and more inquisitive.

A second thing to take care of is to explain the terms I use - I won't always do that, but especially when I'm going against something, I will try to explain how I define it - just to make sure people know what am I referring to. Having a shallow agreement on terms can sometimes lead to wasteful debates where each side simply can't understand the other side's arguments.

And a last point, just to get to three - I believe that sharing experiences is less prone to violent comments, probably because my experience is mine, and mine only, but also because by sharing an experience I am delivering much more than the bottom line - I'm walking the reader through my thought process. I could simply write "Gui-based 'test tools' are inferior to actually programming", but by talking a bit about my experience with Human Resource Machine", I believe I can get the reader think a bit before going out all "I use ReadyAPI! and have a great automation suite!!! you have no idea what you are talking about!" (by the way, if this doesn't work, do tell me).

There are probably a million other things to watch out for when trying to write something that will invite a civilized discussion instead of a flame-war, but taking three of them seems to me like a good start.
----------------------------------------------------------

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

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

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

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

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

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

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

שובך יונים Pigeon hole

(Reaction to an English speaking source, so Hebrew will come later)

I listened to the Gem Hill's latest episode of "let's talk about tests baby" (Ep. 62), where she interviewed Neil Studd and they spoke about some very interesting topics - from motivation, to mental health, working 9 to 5 and coping & promoting change. It was a great episode that I will have to listen to again at least a couple of times to process everything that went there.
As usual, Neil is is always quicker than I am in posting something related, so you can read some background to this interview in his blog.

While I listened to the discussion I re-thought my views on 9 to 5 testers, and despite initially being pretty much in favor of the idea, and that there wasn't a single argument voiced against this approach, I started wondering whether 9 to 5 really is a valid choice. Each and every argument for not doing anything work-related after work is sound and solid, yet somehow each such argument just enforced my gut feeling that it is only a valid reason to completely avoid participation if you don't care.

But before I start, I just want to make sure that I'm clear on what I call 9 to 5 testers, since while I was writing this post I found that it's not the hour cap that bothers me, but what I associate with this term. For me, a  9 to 5 tester is someone who comes to work every morning, leaves somewhere in the evening or even late at night, and have exactly zero interaction with a testing community. They might work 14 hours a day, but if they know only what they see in their own work, I call them 9 to 5 testers.
Another assumption I am making and don't really feel the need to justify, is that testing is an intellectual work - which means that one must take interest in it in order to become really good. I'm not sure I would say that al 9 to 5 testers are bad testers  (though I am quite tempted to say that), but they sure can be much better.

I have mainly the projection of how I feel about my profession - I like being a tester. I think that when you do something you like, you cannot simply stop thinking about it when your shift is over. Just like any other subject - if you invest time thinking about it, you start seeing and interpreting other matters from that unique perspective - football (or soccer, as some of you might call this game) fans, for instance, will often borrow football terms to describe events or ideas that have nothing to do with football since the terms and thought patterns are readily available in their mind. This way, testing, if you care about it, doesn't stop when we're not at the office - we will still smile when we'll see this car and still use insights we learned as testers, or use what we experience outside of work to improve our testing skills. When I can put something aside and say "I don't do anything about it outside of the time I have to", it means that I don't care. Putting aside something I care about is a gradual process - I decide to do something else, then, after the third time I decide it's time to wrap things up, I actually do that, and I will still occasionally think about it.

Neil & Gem mentioned some good and valid reasons for testers not to participate, but while each such reason sounds convincing, I found that I don't see them as good enough to completely avoid participating. There were two distinct reasons I could identify: Having other commitments (such as family or other interests) and Being an introvert, which means one feels drained when socializing.
When facing those reasons as binary questions - there's a clear cut: Work stuff should not trump one's personal life, and forcing someone to overcome their discomforts and fears just because I say so is quite inappropriate. But the question at hand is not Boolean - it's a scale, and there's a world of difference between turning down the dial to a comfortable level and switching it off. I came to this understanding when I've heard Neil describing himself as an introvert, and mentioning that his way of coping with the massive energy drain at CAST was being the first one leaving in order to crash at the hotel (which, at least from my perspective, was completely invisible. I think I recall at least one evening where I left before him, simply since I wanted to get five or six hours of sleep). While I can't really imagine how does being an introvert feels, since I tend to take energy out of interaction (which makes me an extrovert, I think) - but unless we take the extreme case of a person left in a state of acute lethargy or anxiety - Neil describes the  perfect solution: Moderate your participation level. One does not have to attend each and every event, and it's perfectly fine to leave a meetup after an hour or so. It's also ok to prefer small events where you can get to know people. And even if participating in any sort of event is extremely difficult, there are ways to participate online - Writing a blog, or commenting in a web discussion. You gain a bit less from written discussions, but it's still a way to keep track on what's going. People can just share something interesting they read with their team.
Having other interests that take time is a great reason to skip a specific event, or avoid taking on big commitments, but given enough time ahead and high enough priority, scheduling an evening event once every six monts or so is feasible. If someone says "I don't mind going, it's only that I can't fit my schedule", that person is saying "I don't care enough to make time for it". Someone with a tight schedule can still find time to do things that are important enough - it might not be as often as desired, but aiming for an evening once or twice a year is not impossible. There are also some events that take place during work hours - it will take a bit more effort to get permission to attend such an event, but it's doable.

You might have noticed that despite my claim of not approving the "9 to 5" choice, I don't expect everyone to start investing heavily outside of work - There will always be different levels of involvement between people, and that's fine. I get to work every day on my bicycle, and I even enjoy riding a bit in the countryside in weekends. despite that, I wouldn't call myself a bicycle enthusiast - I don't own a 10,000$ bike, have no idea what's the difference between the different brands and part names and I don't spend my time in any biking forum looking for my next trail. Still, since it's something I enjoy - I invest in it a bit. I own a nice pair of bike, I join a riding event once a year and siphon some knowledge about bicycle maintenance and stuff from my local experts. It's a nice thing to talk about with others who bike. Similarly, a tester who has this amount of interest in testing is perfectly fine. I just find it really difficult to imagine such a tester remaining invisible - even such level of care should be visible at least to some of the co-workers around.

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

הקשבתי לפודקאסט של ג'ם היל (let's talk about test baby), לפרק בו היא אירחה את ניל סטאד ובו הם דנו במגוון נושאים די מעניינים - ממוטיבציה ובריאות נפשית ועד התמודדות עם שינוי ובודקי תוכנה של תשע עד חמש (תשע עד שש בארץ). זה פרק מצויין, ואני כנראה אצטרך להקשיב לו עוד פעמיים לפחות כדי לעכל אותו כהלכה. 

כרגיל, ניל כותב מהר ממני, אז אפשר לקרוא קצת רקע על מה שהוביל לראיון בבלוג שלו.

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

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

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

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

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

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

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

בעייה ייצוגית Advocating for a user?

(Note: Even though the trigger for this post came from an English speaking source, I don't really consider it a reaction, so English will be at the end, as usual.)

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

ובכן:

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

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

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

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

Every now and then I hear someone mentioning that "A tester is the user's advocate", and I believe it's time we've stopped repeating this mistake. This time, I was reminded of this saying when I listened to Joe Colantonio's interview with Melissa Tondi (By the way, if you haven't heard Joe's podcast, I quite enjoy it), when he asked about Melissa's talk in STPCon about "balancing technical acumen and user advocacy" (around the 16th minute), and it seems that they both accept without question the statement that a tester is expected to advocate for a user (to be fair, they mentioned a pendulum movement between being "technical" and representing a user). 

Well :

Software testers, in most cases, can't represent the user efficiently, and shouldn't do so even when we can. First and foremost - because the user isn't the one paying our salaries. We are hired to promote our employer's interests. Sure, those interests often include caring for the wants and needs of the end user, but it's not always the most efficient use of our time. And while it's true that bugs that are not manifesting in real usage are not really a concern, but acting as a user isn't necessarily the best way to find interesting problems. There are also things that are of no interest to the user, but should definitely interest a tester (For example: code tidiness and simple design are a in the best interest of the team, and are definitely within the testers' scope). 

Besides, in many cases, a tester simply cannot represent the user - How many of us have banking experience? or civil engineering? Doctoring? Piloting? education? accounting? How many of us can represent users from ten different countries?

What's worse is that as long as this saying is still out there, it creates the misconception that the main capability of a tester is to think like the user, and therefore a real user would be a great tester (They might be, just as they might happen to be great developers or expert doctors, but there's no relation between their skill as tester and the fact that they are real users). 

Even if we accept the narrow view that preaches that a tester's role is to find bugs (which I don't. you can see some initial thought around it here), "The user will want to act *this* way" is a very small subset of the interesting problems a tester should search for. No legitimate user would want their work to be lost just because one of the other 3000 concurrent users have performed an action at the exact right moment to cause a race condition - but no user will ever be concerned  about such a thing (While a tester should be). No legitimate user cares about how the system management actions are being monitored (but a problem there might cause a security auditor to disqualify the product). No user will object buying stuff at a 50% discount due to a software bug in the billing system (but the finance team will dearly care about it). When we go and test a piece of software, there's so much more that we do than just "think like a user" - we should start saying that.

Landslide

(No Hebrew this time, and for once, I don't feel a need to explain why)

It just so happen that I was a bit late on my reading list, and so I heard about what is now referred as "The slide" (or "the slide incident"). And my first encounter with it was through Maaret's blog (here). I started by reading the slide's content - not knowing a thing about the context in which it was presented, what was said alongside it, or what Maaret had to say about it. My first feeling was that I am just seeing someone sneak a nasty punch to the face (something a bit like this). And, as we all know - emotions are an oracle that should be considered. So, with that preliminary uncomfortable feeling I set out to read what is this all about. By the end of the post, I felt an urge to express my disagreement with what I saw in the slide, since I interpreted it as injustice, and staying silent when faced with injustice is almost as worse as taking part in it.
Still, I took my time - I could not find proper words for it. There was no need to "go out and help" Maaret, since she can stand her ground better than I can stand mine, and seemed to handle it pretty well, so there was no urgency, and I wondered if perhaps I should let this one pass along. Maybe I am missing some details? Surely I should hear what James has to say about it first, because I don't suspect his goal was to throw such an insult.
Today I progressed a bit more in my reading list, and got to some of the reactions - James's post, Kate Falanga's post (which, according to her, might be removed in the future), and probably Patrick Prill's post as well.
I won't pretend that I have now a better understanding of what actually happened, but my gut-feeling was not eased. The fact that two people I deeply appreciate, and have learned a lot from materials they have created or talks I had with (I have spoken with Maaret at the last European test conference, and while I haven't met James face-to face, I emailed him once when I had a question - which lead to an interesting discussion I learned a lot from) are at odds with each other is quite discomforting, since transforming a professional discussion to a personal argument makes me question the maturity of the profession (or rather, the communities I take part in) and it's ability to contain constructive disagreements.
As it so happens, tomorrow is the Jewish new-year, and ten days after comes Yom-Kippur, the day of judgement (literally, "Day of atonement"). These days are known as "the ten days of repentance", where everyone asks for their sins to be forgiven. In the Judaic tradition, there are four steps to penance: recognizing a sin, abandoning it, deciding not to repeat it, and confessing.
Personally, I'm not a fan of confessions in most cases, but I really like the first three steps.
From what I have understood of James's post, the summary is something along the lines of "I am sorry that Maaret's feeling were hurt, and this wasn't my intention, but I think what I did was perfectly legitimate and would act similarly in the future" (do check me up on this, it is possible that I have misunderstood the post, or missed something critical).
So, I want to focus on why I think having such a slide is not proper.
First of all, there is the actual result - regardless of intent or other possible ways to interpret the slide, many people (myself included, and that's one of the main reasons I'm writing) have understood it as an attack on Maaret. If there's a mismatch between the expected reality and the actual reality, it does not matter how solid was the reasoning, since it was clearly wrong. It's ok to make mistakes, but it is important to recognize them in retrospect and act upon such recognition.
Second - There's a world of difference between quoting someone and interpreting them - it can be acceptable to honestly quote from someone and say "I don't agree with that". It's less fine to build a straw-man around an interpretation of what the speaker understood - because it's likely to be inaccurate. A good way to mitigate this would be to approach the person thus quoted and ask them to review your ideas and make sure that the interpretation is close enough to the intent.
Third - when standing on the podium, the speaker is quite powerful (just as I am here, in my blog): the slides and narration are setting the tone, and the speaker is now the source of authority. putting publicly questioning someone who is, currently, in a less authoritative position, is a violent act. Sometimes, such violent acts are in place (for instance, I believe this post is such an act).

Fourth - A speaker should assess the way his story will be understood. The specific format in which the slide was built is inviting an interpretation of accusation. For instance, if I would "reverse" the slide, it might look something like this:
How I differ from James?

• I value collaboration. I don't waste time on futile quarrels. I want to collaborate while remaining true to my standards. 
• I think dialogue is critical to learning and to the maintenance of a respectable craft. 
• I don't believe experts should limit their contribution only to the narrow field in which they specialize.

Now, the naïve way of understanding these three bullets is that I claim that James is anti-collaboration, does not believe in dialogue as a learning method, and is needlessly limiting his scope. Sure, I can say that anyone who have seen the slide I was referring to will know that I actually mean that I put a strong value on collaboration, and that I see "niceness" as a strong collaborative tool, while James puts a stronger stress on staying true to his core values. I don't imagine he has anything against collaboration, he just places it in a lower priority (which, unlike opposing it, is quite reasonable) - But the slide I present does not reflect that context, and does not reflect the complexity of my idea. In fact, I cannot present such a slide without reminding the audience what I actually mean (or, to put it to the extreme, I will say something such as "don't take this slide as is, what I actually meant is..."), and I don't think a slide that should always be followed by a cautionary explanation is a good slide to have (unless someone wants to insult people).

And lastly, why don't I want to see such slides in the future:

In a short comedy piece quite familiar in Israel the comedian defines dialogue as "two persons talking to themselves" (Luckily, the piece is framed as "English lesson in an Arab classroom", so most of the text is in English with a fake Arab accent, and everything but the first 20 seconds is accessible to anyone who understands English. You might enjoy it). In the professional community I want to be a part of, people listen to each other, and learn from each other (or learn by listening to counter-arguments and defending one's stance). When people are offended, we digress to the state where people are talking to themselves instead of talking with each other. So yes - it is vital to keep integrity and sometimes to say things that are difficult to hear (and to say), but this is exactly where politeness, respect for others and kindness can facilitate the flow of information, and help opening people to ideas and opinions instead of shutting them out. I want to hear people who disagree, I have gained a lot from listening to both James and Maaret, and to see a wall growing between them (or, as James stated in his blog "I will no longer be conferring with her, until and unless those differences are resolved") makes me a bit sad. 

 

רכיבה על אופניים חשמלייםRiding an electric bike

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

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

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

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

מצד שני - אם נשווה את המוצר הזה למוצר של Testim.io, שני המוצרים עושים את אותו הדבר, אבל טסטים נראה יפה, רץ על כרום ומספק כל מיני שירותים מגניבים כמו הקלטה של כל הבדיקות שרצו. כשעובדים עם כלי כזה - לא כל כך קל לשים לב שהבדיקות שאנחנו מייצרים מוגבלות באופיין. ואם אנחנו עוברים מבדיקות דפדפנים לתחום אחר, כמו למשל בקשות SOAP, המצב הולך ומשתפר: כלים כמו Ready!API מספקים די כוח כדי לענות על צורכי הבדיקות של כל מיני מוצרים באופן טוב מאוד - מקליטים כמה בקשות, או אפילו רק מספקים לכלי WSDL ומקבלים ממשק נוח מאוד לבדיקות פונקציונליות (שבניגוד לכלי ההקלטה שמזיזים דפדפנים, מכילות גם הפנייה לבדיקות מסדי נתונים בצורה מובנה), בדיקות עומסים, לפחות בקטנה, ובדיקות אבטחה בקליק אחד. ואם כל זה עדיין לא שכנע אתכם, החבילה כוללת גם שירות סימולציה שמאפשר לקבוע את התשובות שיוחזרו לבקשות השונות.  בקיצור - אם אתם משתמשים בכלי הזה, לא חסר לכם הרבה. 

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

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

After I've compared between writing automated checks and riding a bike, I played a bit longer with the idea, and thought about tools that were meant to provide non-programmers with automated checks capabilities. The metaphor that stuck in my mind was riding an electric bicycle.
In theory - Electric bike is a great idea. It's relatively cheap, relatively eco-friendly, and does not involve all of that sweating and effort  that prevents people from using it as a transportation vessel  for short & medium ranges. Riding a bike saves time for just about every ride inside a city, reduces traffic jams (or at least, mostly unaffected by it) and is generally fun. Unless rain is a problem for you - there are not that many reasons not to use it. You don't even need a driving license for it.
However, in practice (at least here in Israel), the reality is quite different - a combination of poor infrastructure and some other factors (such as the young age of many electro-cyclists), results in cyclists terrorizing pedestrians, and being involved in an unproportional amount of accidents that are not as common with regular cyclists (I didn't manage to find official figures, but the numbers I've seen while searching were around 2 injured people per day during 2014, including pedestrians that were run-over by an electric bike, while regular cyclists are mainly counted as "were hit by a car" and get to a bit less than one a day). But honestly - I am willing to believe just about any ridiculously high number I might hear, since I see how electric cars are being used. I've seen electro-cyclists ride with their eyes in their phone (held in one hand), riding in couples or even triplets, or folding a leg beneath the rider, and even one time I saw a rider with both legs on the top tube (The phone, naturally, was in one hand).
Each and every time I see such a thing I ask myself "why are they doing that?" And each and every time I answer "because they can". While using the pedals, there are a lot of forces moving in many directions - were I to look at my phone while on my bike, It would take me less than 10 seconds to fall to the ground. I must constantly look ahead to see if I will need to shift gears, and picking a friend on my bike will mean more effort for me. With electric bicycle, those "costs" are not really visible. People don't have to be as attentive and as careful, they can reach a grater velocity without any effort, and they can get out with losing concentration for more than a couple of seconds.
That is, until one time they can't. An accident caused by an inattentive electric rider is more likely to cause grater damage - It's faster, heavier (if giving a friend a ride) and by the time the rider gets to the brakes, the accident has already happened.

Tools that are marketed under "the end to your automation problems" or "everything your automation needs" (not to mention "code-less automation) have finally reached the point where we can compare them to electric bike. When I first got to work, we were in the late phases of getting rid of a tool called "Badboy", and it was fairly obvious why - It was a record & playback tool, that used it's own proprietary browser to run. Anyone looking at it could tell that it might be a good time to hire someone who can do a better work. The tools wasn't really bad, but it didn't help with actual browser coverage, and most importantly - it was ugly and uncomfortable to use.
One the other hand, we can look at Testim.io - this is a newer record & playback tool, that works on chrome, looks nice and modern, and provides a bunch of useful things such as grouping actions for reuse, some strong built in validations, and a test report with images. A great time-saver. Working with such a tool, it's not that easy to notice that we are missing stuff (the first thing that comes to mind is non-web stuff, such as database checks). And, if we move to some non-browser tools - we get an even more complete and powerful tool, such as Ready!API by SmartBear for SOAP\REST testing which provides, on top of DB checks and strong validations with a simple way to setup things (just add a WSDL, and you're good to go) some neat capabilities such as automated security and load checks and even some simulation services that enables mocking (and controlling) the response for a request.
So, we're making a great progress, right?  We can leverage those tools to get rid of the infrastructure fuss and focus on creating checks. We don't even need to know how to code. The best of all worlds!

Well... no. Not really.
Those tools, powerful as they might seem, are pretty limited. It might be because GUI is not really suitable for programming complicated logic, or simply a limitation of the tool's scope (Browser testing, for instance, is out of scope for Ready!API). But with the shiny tools out there today, it's getting more and more difficult to build a case against using them, or for migrating out, because we do gain a lot out of them. So why should a company invest in building an extendable, tailored test harness, when we can get all of those cool things for the price of using a tool? Most tools can even be run from the command line, and thus integrate into our CI. And the fact that the tool is configured outside of the main product's code? that's fine. Every now and then we'll just have a tester go and update the scenario parameters. for that small nuisance, why should we pay for testers that can code?
Besides, when using a tool, there's only so much you can know about the tool's internals and what's actually going on in your tests - and if something isn't working, you can't just peek under the hood and fix it - you have to contact the vendor support (or, if it's an open source tool - you can start diving into the code and compile your own version of it, and it will be quite painful to do).
Also, to return to our bicycle analogy - it's great to ride while using the phone and zooming around, and you will normally stay out of trouble - until suddenly, you don't. If you get to a conclusion that the tool you're using is no longer doing the work you need - it will be that much harder to migrate out of it, and to develop all those nice capabilities you've grown accustomed to in your framework.

And, one last point of similarity I found while writing this blog - regular bicycle riders tend to sneer and look down at electric cyclists. They can come up with several scenarios where using them is an acceptable choice (for instance "I don't have a shower at work" is an acceptable excuse), but every time I see someone riding an electric bike I get that feeling of moral superiority. I've noticed pretty much the same feeling towards tool users - despite the fact that I can describe several scenarios where using a tool is better than writing everything at home - as a tester who codes, I can't help it but look down on testers who automate without coding. 

לרכוב בלי גלגלי עזר Riding without training wheels

(English first, as this is also a response to a source whose owner probably does not speak Hebrew)

I'm assuming you have at least heard of Gem Hill's podcast let's talk about tests baby and if you didn't, go and listen to a few episodes - they are short and I usually find them interesting.  I've listened to the episode on using selenium IDE. It just so happens that on the same day I've listened to it, I also attended a local selenium meetup (which, in case you live in Israel, or just happen to be in the neighborhood when one is occurring, can be found here) and after the meetup a few of us grabbed a cup of coffee (tea in my case) and continued to chat for a bit. One of the subjects that came up during this chat was about record and playback tools. If you've read this post you can probably guess that I feel very strongly against this kind of tools.
Listening to Gem's podcast, I noted that I was listening to the rare occasion where the person using selenium IDE¹ is doing it properly with the right goals in mind - create a base, use the recording to flesh out some crude scaffolding quickly and then go and fix the generated code. Then, after the chat I had following the meetup, I thought about it a bit more, and realized I don't like selenium IDE even when it's used responsibly (Though, if I understood correctly, Gem's done it right - use once or twice to bootstrap the code, then defenestrate).
Why? Because it's like riding with training wheels.
When I was young, like all of the kids around my age, I had a bicycle with training wheels, and I rode them around. At some point, came the time for me to remove them, and my father spent several hours running behind me, holding the bicycle rack and releasing it when I wasn't noticing. If you've been anywhere near bicycles lately, you probably know that the new fashion on teaching kinds to ride is by having them ride a balance bike - the reason is simple: When using training wheels the kid might get used to using the pedals and the breaks, but will miss the most important thing - learning to self balance on the bicycle. You also acquire some bad habits you will need to get rid of when you'll later learn to properly ride a bike (for instance, the way you turn around is completely different). Finally,  removing the training wheels is quite scary.

The same is true for using selenium IDE - it helps you do something that looks a lot like writing an automated check, and using it you are able to get some results that are (at least at the beginning) better than not using it, but by using it, you are missing the central skill that is required to write decent automated checks - which is the ability to think in algorithms and organize code in a reasonable way.  And just like training wheels, it can be very scary to let go of it. Worse - using it as a learning tool leads to learning some bad habits - such as having each script live in it's own world, initialize everything for itself and so on. In fact, if we were to convert a recorded script to fit into a proper test infrastructure, not a single line of code will remain - initialization and teardown code will be in the superclass, every selenium code will be in the page-objects, and chances are that even page-objects will be hidden beneath another abstraction level. A bad habit that is a bit harder to shrug off is that by using Selenium IDE we are getting used to try and mimic human actions with our automation and completely ignore the fact that humans and computers are different - and things that are easy for a human being are sometimes difficult, or impossible, for a computer - and vice versa. In addition, recorded scripts are usually quite meaningless in terms of what they actually validate.

So, what should we do? To answer that I want to go back to my bicycle example - How do I like to teach riding a bicycle? I got to do that several times in the past - teaching my cousins, and a couple of friends closer to my age that managed to grow up without learning to ride. What I did was to start from the running point, but instead of holding the bicycle from behind, I run side by side with them, holding them by the shoulder and balancing them until they start doing that themselves. It takes about two hours of doing that before they can ride without my help, and then we go on to the more complicated parts of getting on and off the bike. All in all, after four hours of training, we can ride side by side for a short trip. An equivalent behavior will be learning with a mentor - strong style pairing seems to fit well this image, assuming that there is some basic coding knowledge to begin with (otherwise, focusing on at least some basic coding skills should be the first thing to learn). Lacking a mentor around, I guess you could start by copying some template of "how to write a selenium test in language X" from an online tutorial (there are dozens of them). Though, if you don't have a mentor available to help you, feel free to send me a message (there should be a "contact me" form on the left, or you could leave here a comment) and I'll try to help you getting started - though if you are using a language I'm not familiar with, my help will be limited.

---

1 Just one note - I use here "selenium IDE" quite often, but if you are actually using selenium IDE, you might want to check out "Selenium Builder", since IDE is planned to reach end-of-life for at least 3 years now. ^↩

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

אני מניח שמי שקורא כאן מכיר את הפודקאסט של ג'ם היל let's talk about tests baby, ואם לא - לכו להקשיב לכמה פרקים. הם קצרים, ואני חושב שרובם מעניינים למדי ונעימים להקשבה. האזנתי לפרק האחרון שהתעסק בשימוש בסלניום IDE, ולגמרי במקרה, באותו היום גם השתתפתי במיטאפ סלניום בארץ (אם טרם הגעתם לאחד - למה?). אחרי המפגש נשארנו (לא כולם) לדבר קצת על כוס קפה, ואיכשהו גם כאן השיחה הגיעה לדבר גם על סלניוםIDE. אם יצא לכם לקרוא את הפוסט הזה אתם יודעים מה דעתי על כלי הקלטה. 

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

למה? כי זה כמו לרכוב על אופניים עם גלגלי עזר. 

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

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

---

1 אני משתמש בשם סלניום IDE, אבל אם אתם משתמשים בכלי הזה, עשו לעצמכם טובה והעיפו מבט בSelenium builder שאמור להחליף אותו אחרי שהתמיכה בIDE תסתיים, כמו שאומרים שיקרה כבר לפחות שלוש שנים.  ^↩

Comic relief

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

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

וולי שוב מתעצל ומנצח את המערכת, לא? 

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

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

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

I'm assuming that everyone who reads here is familiar with Dilbert, and that I don't really need to present the characters in it, so you canstart by reading the above comic-strip (or you can read it here). Usually, Dilbert is amusing for a short moment, and sometimes I get a feeling of "I see that all the time at work!", but that's pretty much it. This time, the strip made me think - The main theme is quite clear, and frankly - not new. Wally is demonstrating again his incredible skill of doing absolutely nothing, and the poor character against him has no chance of changing that (or, in the case of PHB, no clue it should change). Up until this point - business as usual. But, if we look closely at the third panel, we see the ace pulled out of the sleeve when the guy in the blue shirt (I assume he's a product owner of a sort - either a PM or a customer) asks about "a tiny change". This always works, right? Well, not this time. The response is actually reversing the usual scenario and turns it against the poor PO.  Every change, no matter how small, will cause tardiness, and we both know there will be some changes...
Wally's laziness wins again, right?
Well, technically, yes. It does match the usual trope. This time, and unlike previous strips (such as this one), I found myself almost agreeing with Wally's approach, or at least with the non-caricature version of it. The words "tiny change" often hint for a major pile of work hiding behind what seems, on the product side, as something small and trivial. It appears to me that this dynamic is embedded in the way we communicate - most of the time we work under some tight schedule constraints (or at least, we have more work to do than time to complete all of it), and within this environment comes the product owner and asks for a change. This is the cue for everyone around to say their equivalent of "no" (usually it's "next sprint", or "next release"), and then the PO comes with "but it's a really small change", and we all engage in a negotiation in which we will discuss the feature's value, urgency, cost and possible trade-offs that can be made. Usually we all leave this discussion more or less content.
Wally's response determines the nature of this conversation in a way that pulls the rug under the communication form that we (and especially the PO) are all accustomed to, so there is no real opening for a discussion or a negotiation. Maybe that's why the guy in the blue shirt looks so lost.

I must admit though that I don't really have a deep insight into this situation - my mind mainly wanders around toying with some ideas. In the meantime, the strongest link I have is to an idea I heard Matt Heusser mention about "Frame control". Wally is projecting his frame very strongly. In fact, I don't recall ever seeing Wally's frame challenged (not to mention seeing him enter someone else's frame). Each and every time he's talking with someone, he does so under his own terms. And, while the specific frame that he projects is a destructive one (as it is based on the sole idea of wally being useless), holding a frame can be done in a productive manner as well.

Chances are that deeper insights won't be coming along - after all, it's just a funny comics. 

Online lean coffee

(An event report, so no Hebrew)

During CAST last lean coffee (or shortly after), Alex raised the idea of an online lean-coffee, and my initial, and fairly vocal, response was "I can't imagine this would ever work".
Well, I'm happy to say I was wrong.
I joined a session of Tuesday Night Testing that I found by sheer luck. I registered, and shortly after I got instructions by mail on how to join. Now all I had to do is wait.

On the technical side, we used appear.in to chat, and a google-doc was used as a table to put talk ideas on (or "in", since it's a document? not sure...). The video chat was quite nice, and despite missing most of the non-verbal cues of "I want to speak" (it's quite difficult to use body language when people only see your head, and when there isn't any peripheral vision in which those cues can be received) - we managed pretty well. It might do with the fact that we had a small group of 4 (Simon, the organiser, Mark , Nataliia and myself) or it might be the slower pace we took (up until now I participated in sessions where the timer would go off every 5 minutes, and here we had 8) but as the saying goes - if it isn't broken, don't fix it.

As things happen, we took a short while to write down some ideas, and after I spent the last week trying to find subjects I was interested in talking about (with very little success), once the session started, two more ideas came to my mind to join the three that already had, and the others had just as many ideas themselves and we found ourselves with the usual problem in lean coffee where there are more interesting subjects than there are points to distribute. The voting itself was a bit chaotic (which is fun) - where we got to see each other go from one subject to another and text was being added in multiple places in the document all at once. we got almost the same buzz like when meeting in person.  The discussion itself also went pretty well and was both engaging and interesting.

However, there were some differences between meeting in person and meeting online - The main difference, perhaps, is that once the event is done, it is really done. When meeting people in person, the event slowly scatters and people drift off together finishing some conversations. When it's online - you disconnect at once. Also, it's much harder to read people and see whether or not they are bored. With most of the non-verbal communication cut out, I was much more surprised with people voting about whether we should continue a subject. There are also a lot more distractions that were available to me - even switching between the video chat screen and the google doc took some of my attention away, and just browsing in another tab was just at the tip of my fingers (It would have scattered my focus completely, though, so I ruled this option fairly quickly).
Despite those differences, what I really took out from this event is that it's all about the people meeting and changing ideas with each other. The rest is mainly flavour.

And, on a semi-related topic: One of the subjects that came up during the lean coffee was "what is missing in the testing community?". At this point, I wondered to myself - which testing community? The others, who reside in the UK seemed to have it as a given that there is a testing community, and by listening to the discussion I think I got a glimpse on the feeling that I'm missing. In Israel, I can probably name five or six testers who are active, and count two community-focused events that are more-or-less recurring and relate to testing. In the UK there's ton of stuff, or so it seems to me as an outsider.
I think it's really cool to work in such an environment, where the question is "what is the community missing?", instead of "how do we jumpstart a community?"

יום פקודה Command and Conquer

echo "olleh#dlrow~" |rev|cut -d~ -f2|sed "s/#/ /"|awk '{print $2 " " $1}'

Can you read this? great!

(By the way - some code, so no Hebrew)
When I got out of the university, I had exactly zero familiarity with the linux shell, and found myself in an environment that heavily relied on this exact user interface. I learned pretty quickly that "less" is a way to read a file, and that "ls" is the equivalent of "dir", but that was mostly it.  It took me several months to start and see the vast world of the command-line utilities that come built in with linux (or are easily available), and since then I get every now and then reminder of how powerful those utilities are. Lately I got a quick series of reminders, so I knew I should pass the message around and remind everyone else of this fact as well.
What I really like about those utilities is that it almost does not matter which one you'll choose, it deserves a separate post all by itself (and, while we are at it, here's a great post on sed). But - despite having some complexity to dig into, most utilities are simple to use and have a single goal that can be described in a short sentence (with the exception of "awk" that seems to do way to much). The combination of simple and powerful makes them a great tool to use and a huge time saver.

So, inspired by a short session passed by Natalie Bennet during TestRetreat, A short list of my favorite command line tools, in no particular order.

• XmlStarlet - this tool is my most recent reminder of why I really like those seemingly small utilities. It does not come out of the box with every linux distribution, but it's a powerful tool for editing XML files. If you ever tried to edit an unstructured XML in a programming language (such as Java) you know it can be a bit cumbersome. And I had a list of identical elements that I wanted to change their ID so that it will be unique. I wrote something very similar to the following three lines, and lo and behold - the file was updated just the way I wanted it (note - sometimes the command is called "xml", depending on the way you installed it)
  

  for i in {1..30}
  do 
     xmlstarlet ed -L -u "/root/testElement[$i]" -v text$i testFile.xml 
  done

• xmllint - While I am speaking of xml tools, xmllint is what I use to search within an xml file, or to validate that the file structure was not corrupted.
  

  # if there is no output from this line - the XML is valid.
  xmllint --noout myFile.xml
  #opens a shell where I can ask to print a specific element described by an Xpath expression
  xmllint --shell myFile.xml

• grep - Yet another powerful tool. In principle, it does a really simple thing - it filters text to help you find stuff. By default you get the whole line that matches the search condition (which is a regular expression), although you can set it to output lines that do not match the condition, or to output only the match itself.
  This will look a like this:
  
  

  echo "hello world \n and to you too"|grep hello  --> hello world
  echo "hello world \n and to you too"|grep -o hello  --> hello
  echo "hello world \n and to you too"|grep --color hello  --> *hello* world (the asterixes are to mark "bold")
  echo "hello world \n and to you too"|grep -v hello  --> and to you too

• find - Simple, yet powerful. With the correct flags you can find a file, a directory or a link with specific name, or that was created before or after a certain period of time. 
• xargs - this isn't a utility by itself, but rather it's  an instruction to linux to provide the output of a previous command as an input to the next one. So, for example:
  

  find . -name *.java |xargs grep --color "searchString"

  will find all of the places where "searchString" appears in any java file. Running the same command without the xargs instruction, will just result in finding all of the java files that have "searchString" in their name. 
• sed - a simple way to do search and replace. Do read the post linked above for more details. 
• du - Gives information about memory taken by files (du is disk-usage). Most of the time, the only proper way to use it will be
  

  du -h --max-depth=1

  This will give you the results in human readable form, and will not dive any deeper than one folder down, so you won't end up having a million lines that indicate a file of 200Kb. Very useful when cleaning up space on your hard-drive. 

It's getting a bit long, and this post isn't really "all you need to know about the linux command line", so I'll skip other utilities I'm using frequently (such as cp, mv, less, vi, wget and some others) and instead I want to share the story of how I learned - the hard way - the power of the command line utilities. 

I was quite new at work - less than a year after I finished university, and we were doing a security ramp up for our application. Since we deal with payment cards we are bound by PCI-DSS, so we have a handy security requirements document to refer to if we're out of ideas ourselves. This time chose to focus on the requirement never to print card numbers to the logs, even in debug logs. So I set to the task - create a check that will help us spot card numbers in the logs. Sure, why not. We were (and still are) writing our automated checks in java, and I set out to add another scenario to those tests - I performed some activities with several cards, then went about thinking of looking for a way to scan the files for card numbers. The check ran, and even found a place or two where we had card numbers printed. The test was a couple of hundreds lines long, and gave us a very small sample of the actual activities in our system. I wasn't very happy with the result. When I asked for advice from a more experienced tester in my team he asked me "why don't you write a script?" So I did. I wrote all of the card numbers we use in our system to a file, and wrote the following script (I ommitted some variable definitions here, since they are not that interesting) - 

#search for PAN files in logs  directory
for fullFileName in $(find ${LOGS_DIR} -type f -follow); do 
        for card in $(egrep -a -o "${searchPattern}" $fullFileName||uniq); do
                echo $fullFileName $card >>${resFile}
                filename=`echo ${fullFileName}|rev|cut -d\/ -f1|rev`
                cp ${fullFileName} ${resDir}${filename}_${card}
                wasFound="Y"
        done
done

### SEND E-mail#####

if [ "${wasFound}" = "Y" ];
then
        (echo -e "PAN was found in logs in machine: ${HOSTNAME}.\n copies of the logs are kept in ${resDir} (copies are kept as <fileName_date>_<PAN>). \n\n PANs found are:\n";cat ${resFile})|sendmail myemail@workplace.com;
        echo "PAN found"
fi

Basically, what I'm doing is to loop over the files and in each search for card numbers (PAN stands for "personal account number"). I then copy each of the resulting files and adding the card number as a suffix to the file name, so that I'll know what to look for when investigating. 

Do you see how short is this piece of code? and it covers a whole lot more ground than the automated check I wrote in java and was several hundred lines. Deleting the java code was a strong lesson (and to my surprise, I really enjoyed deleting a week's worth of effort).

So, if you are not familiar with the command line - invest some time in getting to know it a bit. It will probably open a whole new world of options for you. 

P.S. 

If you are using windows, you probably don't have access to linux commands. The way I hear it, powershell is as powerful. 

למה ללכת לכנס?So why attend a conference?

לפני קצת יותר משבוע חזרתי מCAST, וחוץ מזה שהיה לי כיף חיים, אני גם חושב שהפקתי מהחוויה הזו תועלת. 

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

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

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

A bit over a week ago I got back from CAST, and had a great time. I also think I benefited from the experience quite a bit.  While a post that will summarize my general thoughts from this conference is still about to come, I want to dedicate this post to list a few reason for why everyone should go to a conference, because, to be honest - going to a conference is not a very obvious choice - it involves work-related stuff outside of work, getting to far places (unless a conference is in your city, you'll probably have to get to a place which is farther than your office), and even for relatively cheap conferences that happen to be next-door, conferences are still a significant expense. Besides, there's a ton a free material out in the internet, including talks from conferences. Moreover, unlike a course, conferences don't usually come with a defined "what do I get out of it" list that can be used to sell the idea to either your manager (who might pay for the event) or even to yourself.
First of all, I want to state the obvious - not all conferences are alike, and you don't want to attend all of them (Also, by "you" I mean my intended audience - software development practitioners, testers or otherwise. If you sell something, you might prefer the conferences I would tag as "don't bother"). One way I've seen and liked to identify conferences and decide whether you want to go can be seen here. For those of you that want only the short version, The division is between a practitioners-community and almost-a-sales-pitch, and the compensation received by speakers is a good hint).
So, assuming you go to the right type of conference, what do you get out of it?

• A chance to hear about a variety of interesting subjects- Yes, There are even more interesting subjects out there online, some of them are high-definition videos, and you can watch them at your own time, rewind, skip and see only things that actually interest you.
  But! when was the last time you actually sat to watch something on a computer uninterrupted? or without doing three other things at the same time? With real face-to-face encounters you have less of these distractions. Another advantage in conferences is that you might go to a talk that didn't consider to be in your field of interest, just because it's there, or that everyone else are going. This talk might end up opening your eyes to something, or "only" be interesting. This happened to me in the CAST2nd day's opening keynote. 
• A chance to ask questions - Attended a talk by an expert in something you're struggling with? You didn't understand something said in the talk because you're new to the field? If you are there you can ask. If the talk is recorded, your question will be there for future viewers. You can also catch the speaker for a longer chat later, maybe over lunch.
• There are a lot of interesting people that get to conferences and don't speak in fact, at any given conference, chances are that most of the participants are not speakers. So you might find yourself spending an hour or two talking with someone you just met about a common interest you have, or you might meet an expert in a field you are struggling with (and now that you've met, you have a communication channel open and you can ask that expert for help later, or even ask them for some consulting work if they do that sort of thing). 
• There are workshops - The cool thing about workshops is that you get to actually try out what you are learning. The workshops won't usually be recorded, and even if they will, participating in one is much more useful than watching it.
• You get to learn what is happening in other places - It is very tempting (at least for me) to think that we know everything, and that everyone are doing the same things we do, but the reality is quite different. Part of the people are doing similar things, others may be far behind us, or far ahead of us while the rest simply have different conditions and need other things. Hearing that such things exist is quite different than actually meeting someone who is facing a different kind of challenge.  
•  A great energy boost - chances are that if you're reading this you care about testing. In that case, you can probably use one hand to count others around you that visibly show the same enthusiasm. Add to this a smidgen of daily routine, and you get that sort of wear and tear that tags along. Attending a conference where almost everyone shares your enthusiasm is very energizing. 
• A humbling lesson -  If you happen to be the only one who seems to care (see previous bullet), it is quite easy to fall into the fallacy of "I'm the best around here", which isn't such a great motivation to keep learning. In conferences you will meet people who are at least as good as you perceive yourself to be (some are better). Seeing them in action, say during a workshop, can remind you that there's still a lot to aspire towards, and you might get some pointers as well.
• A chance to promote yourself - Not everyone present at a conference. Yet, conferences are a great place to present yourself and make yourself known to other professionals and build yourself a reputation. Conferences today enable a wide variety of opportunities to make your voice heard - lean coffees, open spaces, lightning talks and so on. Even if there's no formal place for you to get some spotlight, just chatting with some people makes your voice heard a bit. 
• It's fun - Usually there will be a plethora of events after the formal conference. Some of it will be pre-organized, some will be spontaneous, or you might just find yourself in a pub with a small group of people you met at the conference. And even just attending the conference is really fun - people around you will be having a great time, and it's contagious.

So, how do you find a good conference? You start to get involved in the community (or actually, in a community). You read some content in blogs, maybe even in twitter. Attend a meetup or two (The benefit of meetups, besides being great by themselves, is that the entry cost is very low - most of them will cost you only the time you invest in attending, which will be a couple of hours or so), and you open your ears and eyes. Eventually you'll hear about someone going to a conference, or wanting to go to one, or sharing an experience of having been to one (in which case you'll have to wait for the next conference). Another option is to see some videos from previous events.