Monday, February 19, 2018

ETC time again!

So, it's this time of the year, and this year the European Testing Conference takes place in Amsterdam.
I got here early (Thursday) to make sure I get to tour the place a bit, and that my feet are properly sore before we start (My favorite way of touring a new place involves a lot of wandering around, so I started my first touring day in ~10 hours of strolling), and the city has been very welcoming - with great weather (a bit chilly, but bright and sunny - just the way I like), beautiful sights and some very good tourist attractions (I highly recommend taking a free walking tour , and the Rijksmuseum is very impressive).
I started the conference early in a very good way by meeting Marit in Saturday for a really nice chat and interesting food.
Then, come Sunday, after paying a visit to one of our data center (from the outside, I'm not permitted to enter) and strolling around the lovely moat they have around it, the conference started at speakers dinner. It never ceases to amaze me how friendly and welcoming can a group of people be, and how fun and natural if feels to talk with them, or even join by listening, since just about everyone there has a lot of interesting things to share.
So, an amazing start to what I expect will turn out to be a magnificent conference.

Wednesday, February 7, 2018

Reading Listening to books - part 4

TL;DR - I'm listening to audiobooks, some reviews below, and I would love to get some recommendations from you.

This is the 24th part of a series of (audio) book reviews Here are the previous posts:
Part 1
Part 2
Part 3

Crucial Conversations Tools for Talking When Stakes are High, Patterson, Grenny, McMillan, Switzler:
Short summary: A book about people skills. Specifically, how to have better discussions.
What I have to say: I'm fairly ambivalent about this book. On one hand, it addresses a super-important subject. On the other hand, I was very alienated by the examples in the book.
Starting with the good stuff - the authors coin the term "crucial conversation", which are conversation that might have significant outcomes. Some are easy to detect - trying to agree upon a big business decision, asking for a pay raise, or deciding whether to relocate the family. Other conversations might turn crucial in a very rapid manner - a minor disagreement becoming a shouting contest, a family dinner resulting in multiple people sulky and hurt, or a routine work meeting where the wrong decisions are being made because people are not really listening to each other.
People, so it seems, are really bad at speaking - despite doing so for most of their lives. And just to make things more fun, people are acting even worse when they need to be at their very best thanks to the all familiar fight\flight mechanism that kicks in in stressful situations. Some people, however, seem to do better than others - and this book tries to explain how they do that.
The overall strategy, as far as I understood, is "pull out, relax, calm others, build confidence and start thinking together instead of trying to 'win an argument' ". Naturally, I'm simplifying things here, and skipping some of the tools they mention to actually do all of those points, but I think this is the core of all processes in the book.
When sticking to the principles and intentions mentioned in the book, I found myself agreeing vehemently. It does sound like a very compelling way to approach potentially difficult conversations, and some of the tools actually makes a lot of sense. It is only when I got to the examples that I started feeling a bit off - sure, the examples are simplified to make a point, but as I was listening, I found myself sometimes wanting to punch the teeth out of the example speaker. It is then that I started wondering whether the book is heavily biased towards American culture. For example, in the fifth chapter a technique called "contrasting" is presented. In short, it's a way to neutralize suspicion by acknowledging it, and the example goes as follows: "The last thing I wanted to do was to communicate that I don't value the work you put in, or that I didn't want to share it with the VP, I think your work has been nothing short of spectacular". When I hear something like that, I assume that someone is lying to me and trying to weasel their way into a hidden goal. Living in a much more direct (and way less polite) society, I feel such statements to be pretty glitter meant to cover up some ill meant actions. There are ways to phrase such a message in a way that will be acceptable for me, but this is not one of them. This lead me to think - it seems that the components of effective discussions mentioned in the book are very aligned with the stereotypes I have about the American behaviour patterns. There isn't a single example that I can find (audiobooks are not easy to scan quickly), but almost every example felt a bit off - a bit too polite to be real, a bit too artificial to be convincing, and in some cases, simply achieving the opposite goal: Sowing suspicion instead of trust, seeming detached instead of concerned, and so on. It reminded me of something a friend who has relocated to the states has told me: "At first it was very nice that everyone around were very polite and kind. After a while it started feeling phoney and annoying". All in all, the book left me thinking that in order to really benefit from this content, I would need a localized version of it, where the principles were taken, assessed and modified to match the culture, and the examples updated to something a bit more realistic. Given time and need, I think I can do some of it myself, so this is a book I intend to get back to in the future.

So,  those are the books I've listened to recently (and currently listening to Great Mythologies of the World, that won't receive a review here, being unrelated, but I think it's generally quite nice) and I'm gradually compiling a wish-list to tackle one at a time. What are the books you think I should listen to?

Monday, February 5, 2018

Reading Listening to books - part 3

TL;DR - I'm listening to audiobooks, some reviews below, and I would love to get some recommendations from you.

This is the 3rd part of a series of (audio) book reviews Here are the previous posts:
Part 1
Part 2

Weapons of Math Destruction: How Big Data Increases Inequality and Threatens Democracy, Cathy O'neil:
Short summary: Computer based decisions are every bit as biased as people, and less transparent. They should not be blindly trusted, should be used cautiously, and must be constantly monitored.
What I have to say: I find this book a must-read (or hear, apparently) for anyone who's taking part in software manufacturing, acquisition or regulation. It's probably a good idea to listen to this book if you are only using software. It's not that the book is presenting a revolutionary idea, or that it masterfully narrated (although I did find it quite enjoyable) - it is the way it makes something we are all aware of to some degree very explicit, and shows how prevalent is the problem it discusses. In short, the title of the book lays it all quite clearly - There are very harmful algorithms out there, and they pose a significant threat to the society. That's why they are named Weapons of Math Destruction (WMD, for short).
But, putting aside they hyperbolic phrasing, what is a WMD? and why do we care?
a WMD is a software using some sort of mathematical algorithm to achieve a task, which have the following three properties:
  1.  It's pervasive. It doesn't matter how nefarious is the algorithm I use to manage my local neighbourhood book-club, it's not a WMD unless it affects a large amount of people. 
  2. The algorithm is opaque. Visible algorithms are regularly scrutinized (or at least, can be scrutinized), and they lay out the rules quite clearly - so anyone affected by the algorithms can assess the expected outcome and act to change it. Or, if the system is measuring completely the wrong things, they can be challenged easily enough.
  3. Damage. Some algorithms are using bad math, some of those are scaling up rapidly, but only some of those are causing significant damage to people under their influence. 
A bit abstract, right? Most of the book is dedicated to discussing some of such algorithms, and showing the types of damage they create. Some of the most damaging algorithms are created with the best intentions in mind, and that is the main problem: The people using them are thinking they are actually doing good. Two examples that stuck in my mind are the teachers grading algorithms, and some criminal risk assessment programs used to help judges decide on the length of imprisonment. 
The teachers grading algorithm is simpler, since it has one main flaw - it uses lousy math (in this case, trying to draw statistical conclusions based on the achievements of 20-60 students). From the examples in the book, it is quite evident that this model has nothing to do with reality. So this algorithm is used, because it seems "objective" and "fact based", where in reality it is pretty much a random number generator that should not have been used at all.
The second WMD is a bit more intricate and complicated. The problem is that the software seems to be pretty much benign: it helps a judge assess the level of danger a convict poses in order to determine their punishment, or to assess their chance of recidivism when considering parole. The reasoning behind it is simple: more of a risk a person presents to society, longer should this person be detained, imprisoned or at least carefully watched. That way, minor offenders could get out, leaving the law enforcement mechanism to deal with bigger problems.  Chances are, that the algorithm predictions are fairly accurate, too - the company selling it has an interest in keeping it accurate, or seemingly accurate to sell it to the next state and fend off its competition. There are, however, some caveats: First, the algorithm; being the competitive advantage on the competition, is secret. Normally, a judge must explain the motives behind a given verdict, and those reasons can be challenged or limited. No judge today would say "I decided for a stricter punishment since the convict is poor, and therefore is more likely to commit crime again", and yet - the statistical model might do exactly that. There is a correlation between poverty and crime, and between poor neighbourhoods and criminal opportunities, so the model, measured for "correctness" will be more effective to use that. Even if we won't provide the income level of a person, there are a lot of proxy measurements that are highly relevant: Area of residence, whether the convict has a home or a job to go back to, even how many times was this person arrested in the past has some correlation to their financial situation, as wealthy people tend to get arrested less for minor misdemeanors.
On top using discriminatory elements, there's another risk for this WMD: it creates what the author calls "pernicious feedback loop". Meaning, the algorithm results are actually creating the reality it attempts to predict.
Imagine that: Two people are detained for drunk driving. One of them gets a low recidivism score and therefore is released with a warning. The other gets a high score, and so the judge chooses a more deterring punishment and sends him for 6 months in jail. Six months later, when getting out of jail, this person finds that it is more difficult to find a job with a criminal record (and the longer one was sentenced, the harder it becomes), and he got to know some "real" criminals while in jail, so when things will get rough, the route to crime will be ever more tempting. Point for our recidivism algorithm! The one marked as a likely felon was indeed the one who returned to crime. What did you say? it was only because of the first score he was given? Naaa, this is science, and science is always right, isn't it?
So we got an algorithm that discriminates weak populations, and then actually harms their lives and makes it harder for them to make their way in the world. Fun, isn't it?
Unlike the teachers assessment program, the recidivism model can be used for good, since wheher or not we like it, there's no denying that it is possible to correlate life circumstances with chance of recidivism. People without steady income, or with criminal family members do return to crime more often than people with a decent job who know no criminals. However, imagine what would happen if this algorithm would be used to determine whom to target with rehabilitation programs, or whom to support more closely upon release - In such a case, the algorithm ceases to be a WMD, since it improves the chances of its targets. Instead of deepening the chasms between rich & poor it would help level the playground by providing help for those who need it most. Any recidivist from the "safe" group? this feedback would return to the system and improve the algorithm.

I got a bit carried away, but I hope that I managed to show why I think this book is important for anyone involved in anything remotely technological: It raises some interesting points on the potential damage of careless or malicious use of big-data algorithms (I skipped the malicious ones, but think targeted marketing) and mentions that sometimes, a perfectly valid algorithm is becoming a WMD only because the way it is used, so take care to ensure your software is being used for good, or at least, does no harm. 

Sunday, February 4, 2018

Reading Listening to books - part 2

TL;DR - I'm listening to audiobooks, some reviews below, and I would love to get some recommendations from you.

This is the 2nd part of a series of (audio) book reviews Here are the previous posts:
Part 1

Quiet: The Power of Introverts in a World That Can't Stop Talking, Susan Cain:
Short summary: Our world today is appreciating mostly outgoing, confident seeming people, and there is a lot of place for the quieter people.
What I have to say: In a manner of speaking, this book is quite similar in format to Carol Dweck's book, as it presents how a single trait is affecting peoples life in many facets. Despite that, I found this book quite interesting - perhaps it was that I had not heard the book's main message before, but I found most of the listening quite interesting - It started by defining introversion and extroversion and distinguishing them from shy and outgoing. In short, an extrovert is someone who enjoys social events and is energized by them, while an introvert is someone who finds those type of events taxing and needs some quiet time to recharge. While there is a correlation between introversion and shyness, the two are not synonymous. Despite the book strong focus on the character benefits of introverts (things I remember - introverts are more careful, tend to give up less easily on frustrating tasks, and are interested in deep conversations), it does not carry the message that all should be introverts, but rather advocates quite effectively for the place of introverts alongside the extroverts, each side complementing the others and together achieving much more. The book touches upon the physiological aspects of introversion and extroversion (apparently, while one can learn to mitigate the limitations of their tendency, the basic physiological reaction can be spotted in infancy and remains mostly unchanged throughout life), the claim is that the reason is a difference in stimulation threshold - introverts are more comfortable with stimulation levels that will make extroverts feel isolated. There are a lot of interesting pieces of information about the attributes of introversion, but perhaps the one I found most useful is a practical advice about how to be able to function outside of one's preferred environment - how can an introvert act in a highly extroverted manner, and how can an extrovert adopt an introverted behaviour patterns. The main thing to do is to make sure one allows for recovery time and finds their ways to recharge - an introvert acting in a densely populated space (giving a presentation, hosting a party, participating in work meeting with large-ish crowd, etc.) would fare better if they can find a place where they can be in their quiet zone - a stroll alongside a river, a chat with a friend in a remote corner, or even taking several minutes to unwind quietly in the restroom. An extrovert doing quiet work (research, creating diagrams, writing or editing) can schedule an evening with friends at a bar,  listen to energizing music, take coffee breaks in the kitchen with other coworkers, and so on. It also helps if one does act outside of this tendency in service of some value they hold highly - it would be easier to put the effort needed to be active in a "hostile" environment when it is done for a cause one is genuinely enthusiastic about (the book gives an example telling about a popular professor  who was carrying very charismatic lectures, despite being a highly introverted person, which was possible in part because he cared a lot about educating the students).
Oh, and one more thing - It's almost unavoidable to try and figure out whether one is introvert or extrovert while listening to the book. A lot of people are what the book calls "ambiverts", meaning they posses some introverted traits and some extroverted ones, with the traits manifesting more strongly sometime depend on the situation they are currently in.
All in all, I strongly recommend this book both for enabling yourself to work with other, quieter people, and to find some tips to recharge yourself in the daily routine.

Saturday, February 3, 2018

Reading Listening to books - part 1

(Book reviews are English only)
TL;DR - I'm listening to audiobooks, some reviews below, and I would love to get some recommendations from you.

About two years ago, while attending the first European testing conference in Bucharest, I heard Linda Rising's keynote in which she spoke about her interpretation of Carol Dweck's book "Mindset, the new psychology of success". I really liked the ideas presented in the talk, and so, about a year later, when I re-watched the talk I decided to purchase the book. Lo and behold - there was a free audio-book version, as long as I registered for an Audible account - which I did, and as listening to books isn't really "my thing", I cancelled the registration shortly after.
It took me several months to go through this book, as I just didn't find the time to listen - Most of my listening time is while driving, which happened twice or thrice a week, and it was dedicated to catching up on podcasts, so I just didn't get around to it.
But, then we had about a year ago a team reshuffle, with half of the team at our other office, which is an hour and a half by train, and I was getting there at least once a month since. so, extra 3 hours of dead time? Hey... I still have that Audible app installed with that book I downloaded a year ago!
The second change was when I bought a small mp3 player that can be attached to a sleeve using a clip, and started listening to the podcasts while on my bicycle on my way to work - so now when driving, I have some free listening time. So, after getting another free book from Audible (after a year or so, they considered me a new user and allowed me to have another book if I just signed in to their service), I decided I'm listening to enough books to actually pay for an account.
The experience of listening to a book is very different than reading one - there's no skipping, no control over the speed of progress, and no getting back and re-reading something tricky I think I missed (driving, remember?). However, as a way to make use of the brain time otherwise wasted in commute, it is great that I can concentrate on driving and just hear the book being read to me.
With that being said, Here's a compressed review of the books I've listened to recently:
(Edit: forget about "compressed", it ended up being too long, so it will be one post per book)

Mindset, the new psychology of success, Carol Dweck:
Short summary: "fixed" mindset is bad for you, adopt a "growth" mindset.
What I have to say about it: I started listening to this book with expectations a bit too high. Linda Rising's talk gave me quite a lot to think about and process with regards to how people grow and learn, the importance of refusing to say "I simply suck at this"  and the focus on improvement rather than on achievement. The book, so I hoped, would further expand these ideas to provide some more interesting insights, or elaborate more on the ones I've got. Sadly, it didn't. What I got was a lengthy presentation of the concepts I mentioned, repeated over and over to show how it can affect multiple facets of life. It felt a bit like a sales pitch that goes on and on - I got the idea after the second chapter, really. Only in the last chapter the book gets to deal with a promise that has been mentioned over and over - how to approach changing your mindset. Up until that chapter, mindset seemed like something inflicted upon one by the environment - Parents praising their child on "being smart" instead of praising "putting effort", workplace with personal reviews based on results only and so forth. This chapter is titled "changing mindsets" and does contain some interesting tips. It mentions that simply being aware to this concept is causing some shift in the mindset, and mentions a workshop for schoolkids where the focus is on teaching them how practicing actually creates and enforces new neural links in the brain, thus explaining how one can actually transcend above his current self-image in any given field. It also gives one tip I found quite useful: deciding to do something is nice, but it isn't enough. In order to increase the chance of actually executing a decision, one must create a detailed and vivid plan of execution. Not "I'll write the blog post I've been postponing for over a month", but rather "This evening, after dinner, I'll sit on my couch, close all other windows on my computer, and write a paragraph or two". So, my advice - listen to Linda Rising, she makes the point clear in less time, and there isn't a big gap that I could notice.

Thursday, December 21, 2017

טוב יותר מאשר ציפיתי

Better than I expected

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

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

So, A while ago (almost a month now), I participated in SIGiST Israel.
Frankly? I got to this conference with low expectations. In the previous years the program failed to impress me, and this time the conference was organized as a part of a tech training vendor (Sela), and was swallowed by it. All other signs were setting me up for disappointment as well - the organizers did not have time to issue a CFP, so I got  one day a phone call saying "Amit, would you give a talk at SIGiST?", and despite the conference being a 4 day event, speakers got to attend only the day they were presenting (which means less speakers are wandering about the conference and available for attendees to contact, or even just a face to recognize. Speakers, at this conference, are apparently here to deliver a talk, and that's it. The conference is saying "I don't care about content outside of the scheduled talks" For comparison, the European testing conference is specifically asking the speakers to be available at other days of the conference).
At the day of the conference, I got a bit late due to traffic, and me being a bit too optimistic about how long it will actually take me to get there, but I still got to hear a good part of Igor's talk and could understand, for the most part, what he was talking about.
Then there was James Lyndsay with a great keynote (which he delivered twice, as there wasn't a big enough room for all participants). I took away from it two things (and there was much more to take) - When presenting data in a visual way it's easier for a human to detect problems (there was a great way of testing a PRNG in a simple way I believe is quite effective despite not being cryptographically sound). The second idea, which was a reminder more than anything else - if a test is cheap to run, just do it. Don't worry about considering whether or not to execute it, since by the time you'll be done considering you could have run this test twice.
Next was my time to present my talk, and as far as I can tell, the audience enjoyed it (I'm still waiting for the feedback te organizers collected, so currently I have only a gut feeling and a few questions I got from the audience). After that I got to listen to talks by Mor, Doron and Alon,each one interesting in its own way.
Between the talks there were 15 minutes brakes, that were officially "networking breaks", which I think could have been better had most of the attendees not arrived in groups from the same office. I got to see more people hanging around their colleagues than people getting acquainted to people whom they have yet to meet. To add insult to injury - I found out that attendees were divided by the track they registered to (registering for a track? really?) and each got a different color string with their badge. I a very versatile conference, it looked as if they were doing their best to isolate people: The .Net and cloud tracks were given in a different floor, and every floor had its own coffee and snacks station to make sure people had no reason to leave their designated area.
However, I had three advantages that helped me to get a bit of conversation here and there. First, thanks to a lot of good people, I had some stickers of our local meetup group, and the goal of distributing them to as many people as I could. It just so happens, that this is a nice way to restart a conversation. It goes something like that: "Hi, how are you? where are you from? what product are you working on?" *conversation dies out* "Say, did you get one of these already? No? Then here's a couple for you, do check out our meetup group, and you are more than invited to come, or present" And we got another three or five minutes of chat over the meetup.
Second, I was a speaker. I stood in front of a podium and people got to recognize my face and I managed to confuse them into thinking I was an expert in something (first rule of becoming an expert - don't correct people when they think you are one), so they had something to ask me about, which is far safer than simply going and saying "Hi, Let's talk about something".
Third - Thanks to the meetup group, I had some familiar faces in the crowd that were not from my own "click", so when I said hi to someone, I would automatically get introduced to whomever they were talking to. In fact, I ended the conference having a real nice conversation with someone I met exactly this way.
And last (yes, I said three, this one is not an advantage, anyone could do this) - I was set out to try and do exactly this.
So despite Sela's best efforts, I managed to actually meet some people.

As you can guess - I still wouldn't recommend this conference as one of the best I've been at (and I wasn't in that many), it lacks a lot in terms of organization and community building - but it wasn't all bad, and with the right mindset, I could make it into a day worth my time. And, compared to many other conferences - it was not extremely expensive, about 400 euro for three days isn't an awful lot of money to pay (though, the testing conference was one day only, so that would be closer to 200 euro for that day alone), and it's easier to get your company paying for a local conference (if it wasn't clear - don't bother flying in for that one). I am hopeful that in the future this will improve and become at least a decent conference. 

Saturday, December 9, 2017

"קודם תלמד בדיקות"

"First you have to learn testing

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

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

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

Every now and then I see a question posted somewhere "I'm starting my way in testing, should I learn automation?" And too many times I see the response "You should learn first to test well, and expand to automation only once you have a good testing foundation".

Well, I call bullshit. Saying such a thing is similar to stating that one cannot learn higher math before mastering Greek, as many of the symbols are Greek letters.
Programming and testing are two important skills for a software tester, and acquiring one is not impeding acquiring the other in any way.
So, what should a software tester know? Testing is one thing, programming is another, as are statistics, graphics, network, electronics, databases, communication skills, finance, management, psychology and ... - you got the gist.
There are a whole bunch of skills that help us when we test software, and it is a great thing to learn any part of them. Naturally, we cannot learn everything, and certainly not everything at the same time, so we have to prioritize. It's better to focus on the skills that will deliver the most value in most positions (or, if you know the position you aim for - most value in that position), and I'll call those "core skills" - it does not mean that everyone has them, but only that they are not esoteric and possessing them would benefit most practitioners. The core skills are what we should focus on "first". Learning other stuff? only if it does not hinder our efforts to acquire the core skills (or we are already comfortable enough with them to expand).

The question is - is coding a core testing skill? After all, many testers do not code. Personally, I answer this question with a definite yes, based on the fact that all of us are testing software, and we should have a pretty good understanding of "how software works" (and how it fails). The only way I know to get a feeling  around this (which later can lead to understanding, but feeling is good enough for beginners) is to actually write code. One can hear a million times about the "Off By One Bug" and even understand it pretty well, but those million times pale in face of the one time that person wrote a simple for loop just to find out that one step was missing.

Still, some people who have invested genuine thought about this subject still claim that one should learn to test before they learn to code. Could it be that they are all wrong?
Well, they could, but it's not very probable. Putting aside some of them who simply don't code and are trying to assert everyone that nothing is changing in the testing world, I can think of two reasons to prefer focusing on "manual" testing (BTW. I really hate this term, any suggestion of replacing it are welcome. I've tried "human testing" and it's not working for me) before learning to write automated checks.

  1. Survivorship bias: Some people learned to code after they had some experience with testing, and I'm assuming they see the value they gained from having this testing experience. This value then becomes "the way to do it". Naturally, my own opinion, as someone who started as a coding tester, is biased just as much. 
  2. Goal displacement: I want to point out that the original question was "should I learn automation". It is only my response that was "learn to code". People whose role is to "create automation" tend, amazingly, to focus on creating "automation" (which, in most places having such role, means E2E scenarios). When combined with lack of testing knowledge, it is not rare for people in this role to "automate" thoughtlessly - writing code at the wrong level, or trying to write code to solve problems that are better left to humans, or working around a defect in the system (say, a screen is taking 10-20 seconds to load) instead of investigating the problem or opening a bug. After all, if my role is to "write automation", I'm not here to test the product. I'm here to make sure the test execution is delivered on time and is stable. 
So, in short, the answer to "Should I learn automation" isn't "later", it is a resounding "no". 
It is important to learn how to code, since coding is a powerful tool that can help quite a bit with our tasks and there are several things we simply can't do without it. Our goal1 as testers should not be affected by whether we know to code or not - as long as the coding serves this goal. 

1 Initially I wrote "the goal is to test the software", which leads to another discussion about what is the role of software testing, which I'll leave for another time (don't hold your breath for it, though). Currently, I like ATAOSQ quite a bit