Sunday, November 3, 2019

Book review - Social Engineering: The Art of Human Hacking

"Sir, you can't board this train with your bicycle"
I faced this statement (or something that conveyed its message in different wording, the translation from Hebrew isn't exact) from a train employee a while ago. As luck would have it, I was just listening to Christopher Hadnagy's "Social Engineering: The Art of Human Hacking", and thus went on to try and board the outcome - I burdened the employee with a barrage of accusations, making him responsible for my situation ("You're stranding me here at the airport after I bought a ticket and used it to get here to my connecting train", "what do you expect me to do now?"), claimed for precedence ("I've been boarding the train with my bike yesterday, and the day before", "why do you change the rules?") and applied time pressure ("Look, you are causing me to miss my train"). After a couple of minutes of arguing, he came to the conclusion that "If I can't see it, I can't stop you, if you would wrap it in your bike-case it's not my fault I didn't see it".
Ordinarily, I would have just thought it was me arguing and getting my way with it, but as you can see - I was employing several tactics to get what I wanted - I counted on the employee's empathy and the fact that he didn't want to be the bad person, added time pressure and offered an escape route that allowed him to save face in the form of "what if the bike had been covered?". I believe being aware of what I was doing helped me "win" this argument, and it sure did make me feel  uneasy a about how "evil" I was acting - consciously putting pressure on someone who was simply doing his job.

Since I neglected my blog for too long due to a multitude of things taking up my time and energy, I thought a good way to start writing again is with a task that have been waiting for quite a while now - a review of "Social Engineering: The Art of Human Hacking" by Christopher Hadnagy which is the first audiobook I listened to twice.

The first thing one should know about this book is that listening to it is a bit scary, as the book shows time and again how reasonable human behaviour can be (and is)  exploited to cause harm and then goes on to say "and were I a real malicious attacker, I would have take this to the next level by...". Apart from that, this book is a great first step in becoming a professional security engineer, and provides the next steps of practice in each step.
After listening to this book, there are two takeaways I continue with:
First - Regular, day-to-day human behaviour can be exploited in way most people don't imagine and leveraged in ways far more serious than one might expect.
Second - Despite the first point, defending against social engineering does not require behaving like a heartless automaton. Most of the times, it is enough to pause for thinking and double checking before acting.

In a nutshell - that's it. However, there's much more to this book, which is very well organised to topics.
First we start by trying to define social engineering, or SE, for short. This, perhaps, is the only place in the book where I think the author is not doing the reader justice. The book dwells on the rather blurry line between influencing a person for their own benefit (e.g. - convincing someone to quit smoking) and persuading them to act in favor of our own interest and against their own. The book claims a simple truth - the same skills and techniques used by malicious social engineers can be used in a variety of other, benevolent actors. A doctor will try to persuade their patients to take on healthier habits, a teacher will "educate" students and a friend might put some pressure on you to take that vacation you've been yammering on for ages. Still, in my eyes, the book is trying to paint a nice picture over a term that is used almost exclusively for actions that are, at least, unauthorized and most of the times - straight out malicious. The examples in the book in later chapters also fall in line with this approach and are portraying examples of misleading, putting pressure on people and in all ways get the upper hand of the victims.
Following on, the book goes on presenting the SE framework (more details can be found here) and the different skills and activities that comprise it.
First thing's first, the 2nd chapter is all about information gathering, showing how some trivial details can be used as a stepping stone to further attacks. For instance,knowing that someone is a stamp collection enthusiast is a good way to lure them to a malicious website claiming that you've inherited a stamp collection from your late grandfather and made a website with the stamps to be sold. Besides some examples on how destructive random bits of information can be in the wrong hands, the book mentions some tools such as BasKet and Dradis to organize the data, and points out to common sources of information - from social media and search engines to job adverts, whois registry, personal blogs and even simple physical reconnaissance and dumpster-diving (which, the book says, you should do with dark cloths and a good pair of boots). The chapter then goes on to the seemingly irrelevant topic of communication models, It's quite interesting, at least from the theoretical viewpoint, and it provides a nice way to break down any single social engineering "scene" (e.g. - sending a phishing email, having a conversation with a target), but it is not really a part of information gathering - a communication model can be used wen planning an information gathering strategy, but at the same time, it requires the information already gathered to succeed. Based on the Shannon-Weaver model of communication a social engineer can ask more specific questions: what is the type of feedback I want from the receiver? what sort of message would work best? what channel is the most effective way to communicate my message?

Next on the menu is the mysterious skill called "elicitation" and apparently that's a real word. Its meaning, in case that you are not familiar with it, is "drawing out". In our context, it's about drawing information out of our target. I assume that it can be used also to invoke an action (such as keeping one door open for a person, creating the expectation they'll hold the next door for you, which just happens to be the one you need a key card for) but the book does not dwell much on that aspect after mentioning that the goal of elicitation is to make the target take an action to the attacker's advantage - as small as answering a question or as big as providing access to a restricted area. The book lists some elicitation techniques, from simple ones that range between simply asking a direct question  and getting people tipsy and talkative to more elaborate schemes that may involve pretexting (see below) and preloading the target with information and emotions that will make them more susceptible to your suggestion.

I mentioned pretexting, right? because that's the topic of chapter 4.
A pretext, in laymen terms, is the image one projects about themselves. For instance, I go to work every day, carrying the pretext of a professional software tester. A social engineer might display pretexts that will mislead people - posing as an IT expert, as a worried father or as a pissed off customer. An important point this chapter makes: A pretext doesn't have to be a lie. In fact, it is much easier to pull of a pretext if you are using your own interests and knowledge as part of it. In fact, one of the dangers in pretexting is trying to pull off something completely foreign to you. For instance, I couldn't build, even in a month of intense research, the casual recall of events a soccer fan has experienced talked about dozens of times, so keep it simple and within your expertise. If you have to pretext as something you have no knowledge about - distance yourself. Communicate via e-mail, or on a short, carefully planned, phone call. It is also important to look the part - if you pose as the garbage disposal company representative, a company logo and a notebook will do wonders to your credibility. If you pretend to be a salesperson,  wearing a T-shirt is probably going to get you some unwanted attention.
No matter what you do, your pretext has to be carefully chosen and tailored to your needs and to the situation you're in.

The 5th chapter is all about magic.
Yes, yes, magic. Or at least as much magic as that possessed by a stage magician. If the skills up to this point were a calculated use of common human communication skills, now we are about to discuss some uncommon skills. Micro-expressions, for instance, are a very powerful way to detect how is a person feeling and quickly adapt your strategy if you aren't getting the reaction you were trying to get, but it is also a way to signal to the other person's subconsciousness without the filtering of the thinking facilities - a slight wrinkling of the nose will go unnoticed by many people, but they will still get an uneasy feeling.
Even more controversial than micro-expressions is the use of NLP, which, basically, is all about using side-channels. Regardless of whether you think NLP is a complete fraud or actual magic, There's no denying that NLP does provide extensive record of efforts to understand how human communication works, and that at least some of its methods are having some results. Sure, changing your tone of voice isn't going to magically make someone do your bidding, but it can divert attention and plant ideas. One "tool" I liked is labeled with the terrible title "The Human Buffer Overflow". Basically, it is directing the SE to rely on the automatic responses of people, and take advantage on social norms and expectations. If I helped someone with something, even if it's trivial, they will feel obligated to help me back. I'm unsure as to what exactly here is the so-called "buffer overflow", but I imagine that in order to be more effective, the SE can make sure to occupy the mind of the target with other things - a constant stream of talking, a difficult question, and so on. This way the mind will leave other tasks to the automatic part more easily.

The final chapter presenting the SE framework is about influence. After all, once we've gathered information and learned to control some neat tricks to elicit a response, it is time to cash in on our efforts and make people do what we want them to. Generally, the message is "know your goal, and improvise towards it". This, naturally, is a gross oversimplification - One does not "improvise", but rather builds a flexible plan, with options derived from the information gathered and constantly monitoring the target's response using the skills acquired and practiced ahead of time. The chapter discusses some important tools and principles, such as building rapport, constant monitoring, influence tactics and framing. Like most chapters, this one has a part that made me cringe a bit in discomfort. This one has a part about "manipulation". Unlike other types of influence, this is a direct attack against a person. It involves tips like "gain control over the target's environment" or "creating doubt", it does not shy away from "heavy intimidation", which is about making the target fear for physical harm or other "dire circumstances". In essence, this is the part people dislike the most about SE. The part which not only makes people behave the way the attacker wants, but may actually harm the target as a side-effect or even as a tactic. Being the pinnacle of the framework and cashing in on the previous ones, this chapters is quite long and full of interesting (and scary) techniques and stories.

The 7th chapter is about tools - everything from a lock-pick and business card to hidden cameras and software tools found in Trackback (The previous version of the Linux distribution now known as "Kali") very educational, and provides a lot of entry points to the different topics.

Of course, a book such as this won't be complete without an impressive list of case studies, demonstrating the wide range of possibilities - from the highly technical story of Kevin Mitnick hack of the DMV which involved breaking into the phone system and routing genuine calls of police officers calling the DMV to his own phone (thus collecting the necessary details to impersonate them later) which required deep knowledge of the phone routing system and of the identification process used by the DMV, and then some very convincing pretexting, to the simple case of a security tester who found a genuine hacker roaming through an unprotected server and then chatted using notepad until he got enough details to find the hacker offline. The stories are interesting by themselves, and each shows a different perspective demonstrates different skills and shows how they are applied in real world situations.

Scary, right? It seems that the smallest detail could be used to leverage more details and create an opening to an even wider attack, and most attacks simply rely on people acting as human beings. This is why the final chapter of the book is so important - how to prevent and mitigate attacks.
Like all defenses, it isn't perfect, but if being used properly, the techniques in this chapter could frustrate and exhaust someone trying to social engineer their way into your organization (or your private life, for that matter).
The easiest tip here is "keep your software updated". It might not be easy to implement, but it is a generally good rule to follow - updated software tends to have less known vulnerabilities, and thus prevent many software based attacks, so it won't matter if the SE managed to get you to open that PDF file.
The second is to teach yourself and your surrounding how to identify an attack - know what is generally possible (for instance, by reading this book) and how to identify the stupid kind of attacks of each vector. You might not be able to defend against someone calling and asking "can I have your email address? I want to send you details about the event I wish you would attend", but you'll be able to delete the obviously false "This file includes a debt you have not cleared, if you won't pay by next week, legal action shall be taken"
Another tool I find important enough to mention is developing scripts that allow you to stay kind without letting someone what they want: "I'm sorry, but our IT people don't allow external USBs, if you want to print a replacement to the paper ruined by your coffee, there's a printing service around the corner". Practicing situations and such scripts can help when facing a real SE attempt.

All in all, I highly recommend reading this book, in any format convenient for you .

Sunday, June 2, 2019

להתחיל במקום חדש

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

מעבר לכל הפערים האלה, יש לי גם פערי ידע אישיים: אחרי שעבדתי על מוצר מבוסס WEB עד היום, המוצר הנוכחי דורש ממני היכרות טובה יותר עם מערכת ההפעלה (כרגע אני מתמקד בחלונות, בהמשך אתפנה גם למערכות הפעלה נוספות), וההנחה המאוד נוחה של מערכת SaaS - אני שולט בצורה מלאה בסביבה בה התוכנה שלי רצה, היא כבר לא הנחה שאני יכול להניח. בקיצור, סט שלם של כלים שאני צריך להתחיל להכיר וסט חדש לא פחות של משתנים שאני צריך להתחיל להתייחס לקיומם. בנוסף, העולם העסקי של סטארט-אפ זר לי, ולהחלטות עסקיות יש מחיר אחר שאני עדיין לא יודע עליו דבר וחצי דבר. אני גם לא מכיר את הלקוחות ואת מה שחשוב להם כדי שאדע איפה למקד את המאמצים שלי. אני לא מכיר את צוותי הפיתוח איתם אני עובד ואני צריך לצבור קרדיט בעבודה מולם כדי להשפיע כמו שאני רוצה. חוץ מזה, אנחנו כותבים קוד בפיית'ון, שזו שפה שאין לי ניסיון איתה ואני לא מכיר את הכלים התומכים בה שמאפשרים עבודה אפקטיבית באמת. 
עד כאן, הקשיים ההתחלתיים. 
עכשיו, איפה אני רוצה להיות בעוד נצח וחצי? מה המטרה אליה אני מכוון בטווח הארוך? 
בניגוד למקום הקודם, בו היה נראה לי נכון למחוק את צוות הבדיקות לחלוטין ולהטמיע אותו בתוך צוות הפיתוח (ולמיטב ידיעתי, עדיין עובדים על זה שם), קיומם של כמה צוותים שעובדים על חלקים שונים של המערכת גורם לי לחשוב שהמצב הנכון בטווח הארוך הוא של צוותי פיתוח שאחראים לבדוק את הרכיב שלהם, ונוסף להם צוות שאחראי לשלמות כל המערכת שיעזור לאתר כשלי אינטגרציה ולטפל בתרחישים המורכבים יותר. אני לא לגמרי בטוח איך צריך להיראות הצוות הזה, מה הכישורים שצריכים להיות בו או מה תחומי האחריות המדוייקים, אבל בינתיים יש לא מעט צעדי הכנה אחרים שצריך לעשות. 
אבל, המצב כרגע הוא שיש צוות בדיקות אחד שמספק שירות לכמה צוותי פיתוח, ולמעשה, מזניח לא מעט מהם כי יש גבול למה שיכולים לעשות שלושה אנשים. אם אני מנסה לצייר מפת דרכים גסה, סדר הפעולות שלנו צריך להיות בערך כזה: 
  1. בניית רשתות בטיחות וכלים שיאפשרו לצוותים לקבל מידה מסויימת של ביטחון במוצר שהם בונים. 
  2. תוך כדי 1, צבירת מוניטין ושיפור התקשורת. 
  3. בניית תהליכים שיעזרו לצוות הבדיקות לתקשר עם צוותי הפיתוח ולעזור להם בזמן אמת עם הפיצ'רים בניגוד למצב הנוכחי בו אנחנו מספיקים להגיע לפיצ'ר כשהוא בשלבי סיום. זה כנראה יצריך שימוש בחלק מהמוניטין שצברנו קודם. 
  4. יצירת קהילת בדיקות, או לחילופין, סיפוח של כל הבודקים לצוות אחד לטובת יישור קו בכל מה שקשור לכישורי הבודקים ולאסטרטגיית הבדיקות, כמו גם יצירת ערוץ תקשורת נוסף בין הצוותים. 
  5. אחרי שדברים מתחילים להתייצב - פירוק הצוות המרכזי והטמעת אנשי הבדיקות בתוך צוותי הפיתוח, כשהמטרה היא גם לשדר מידע החוצה, אבל בעיקר להכניס את תהליכי הבדיקות לתוך הצוותים על ידי חניכה פנימית של המפתחים וסיוע בהעברת האחריות על תחזוקת בדיקות המערכת מצוות חיצוני לצוותי הפיתוח. 
  6. כנראה שיחד עם 5, הגדרה מחדש של צוות הבדיקות תחת כותרת אחרת. לפחות בתחילת הדרך, הצוות הזה יהיה אחראי על המשך תיאום בין הצוותים השונים וסיוע לבודקים השונים לא ללכת לאיבוד בתוך הצוותים החדשים שלהם. מהמרחק הנוכחי, הרעיון של Engineering productivity נשמע לנו מסקרן, כמו גם גלישה לצד של ניטור המערכת וייבוא מסקנות פנימה, אולי תחת מחלקת operations. אני חושב שיש לנו שנה-שנתיים (או יותר) לפני שנצטרך להתעסק בזה. 
כרגע, בעודי לומד להכיר את האנשים ואת הסביבה, המיקוד שלי נמצא בסעיף 1, שהוא גם החלק הכי קל - לבנות כלים. בעיות טכניות הן כמעט תמיד קלות יותר מאשר השפעה על אנשים או על תרבות ארגונית. בינתיים, אני מטפל בבעיה פשוטה יחסית - אנחנו צריכים לכתוב מחדש את כל  בדיקות המערכת שלנו בלי לזרוק הכל לפח ולהתחיל מחדש, כי אחרי פעם או פעמיים בהן מישהו ראה מה יש ואמר "אי אפשר לעבוד עם זה, אני אכתוב לכם משהו חדש וטוב", אין לנו את הקרדיט הנדרש כדי לומר בדיוק את זה. אז אנחנו לוקחים את הפרוייקט הקיים ומעבירים אותו מתיחת פנים יסודית. זה נותן לי הזדמנות להיות יעיל עם מעט מאוד ידע ולהתחיל להרחיב את ההשפעה שלי משם.

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

זהו, פחות או יותר.

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

Starting in a new place

I blinked, and two months(to the day) have passed since I joined my new workplace. and now, siting at the airport with not much to do, is a great time to reflect on those two months and try to figure out what I have learned, what I've noticed and what I should be doing.
Since this is the first time that I join a new workplace  with some confidence about knowing my way around and holding some firm beliefs about the way things should be, I tried to be conscious about my ramp-up and notice the goals I set for myself - the long and short term ones. The most important thing I've noticed is that there is a big gap between where we currently are and where we should be. Or, to be more specific - We have a large debt around testing in the system and unit levels, communication channels that need to become more robust, lack of supporting processes and a cultural shift that we need to undergo. Mais à part ça, tout va très bien. Besides,
Besides all of these gaps, I have my own personal gaps to fill in: Having worked on a web based product until now, I never needed to dive into the workings of the OS (right now I focus on catching up on Windows, other operating systems shall follow) and the really convenient assumption of a SaaS solution - I can control the environment in which my product is running - is no longer true, which means that I need to think different variables than those I'm used to. In addition, the business world of a start up is foreign to me and business decisions have an impact I don't fully understand yet, I am not yet familiar with out clients or what is important for them to help me focus my efforts, and I still don't know the development teams I work with enough, certainly not enough to have the stack of credit I'm used to rely on to influence things. Oh, and we write code in Python, a language I don't have a lot of experience in and I'm not familiar with the tools and libraries that enable working with it effectively.
So, those are the starting challenges.
Now there's also the question of where I want to get to,  you know, once I had all the time in the world to set things the way I believe they should be. Unlike the previous place, where I believe it was right to completely remove the tester role and just stay with engineering teams (They are still working on it, to the best of my knowledge. I think that me leaving was a good step in that direction), I believe that in this place, since there are many teams working on different parts of the system, it is still the right thing to have a team that will be responsible for the larger picture. I'm unsure about how to brand this team or what exactly should fall under its responsibilities, but there's enough to do until then. One thing I am sure about is that this team should rely on strong testing capabilities that should exist within each team, so we still have a lot to do until we need to figure this out.
At the moment, though, the current situation is that there is a dedicated testing team that should provide service to three other developer teams (some of which have a dedicated tester, but from what I've gathered, they are being swallowed into doing feature development and are not able to contribute enough to educating the team or even just taking care of the testing gap), so  if I try to sketch a way forward, I imagine a growth and a shrink.

  1. Build safety nets and tools that will enable teams some level of confidence in the product they are building. 
  2. While doing 1, increase our reputation stack to better influence what is happening. 
  3. Set in place the processes required to connect with feature work while it is being defined and executed instead of getting something vague at the end. This will require using some of the reputation tokens we've accumulated. 
  4. Create a testing community, or, failing that, a testing team comprised of all people in testing positions - the idea behind this is to boost and align the testing skills of everyone, as well as a unified testing strategy and also to create another communication channel. 
  5. Once things are working, roughly, split the team and distribute most of the working force to be embedded in the development teams. With the goal of having them educating the rest of their new team, helping them take responsibility of testing and pushing out relevant information.  
  6. Probably at the same time as 5, redefine the smaller team left after most team members have been embedded in the teams. Initially, it will have the responsibility of maintaining the testing community and keeping the communication channels open, as well as help the testers not to get lost in their new teams,  but after this is covered, I'm unsure. For the time being, the concept of having an "Engineering productivity" team sounds quite appealing, but we won't know until we get closer if this is the correct usage of that team. Maybe, since keeping tabs on the bigger picture is part of that team's role, it will be a good idea to have that team as part of the operations group and push towards having a real DevOps culture. I believe we have at least a year or two before we'll have to deal with those specifics.
At the moment, while I'm still learning my environment, my focus is on the first bullet, which also happens to be the easiest one - build tools. Technical problems tend to be almost always easier than influencing people or culture. In the meanwhile, I'm dealing with a simple problem - we have to re-write the existing testing framework without actually saying we're doing that - after at least one time when someone said "We can't work with that, here, let me show you how to do that" we don't have the credit to do the same, so instead we refactor. Heavily. It gives me a chance to be effective quickly, even if only in limited capacity, and start building up from there. 
I need to notice that I'm not being carried away too much into the easy technical task and invest some time in building bridges to the other teams. I have also noticed how much I relied on the scrum daily standups - I feel a lot more comfortable hearing "I'm doing X" and then asking that person a bunch of questions, or suggest my help than I am comfortable interrupting someone and asking "Hey, what are you doing now? Oh, I have zero relevant input? Thanks for your time". People other than me are working on instituting such procedures, so I think I'll wait a bit and try to leverage those efforts. 

That's it, I think. 

Oh, one last thing, not completely related to this post, but I would like to use this opportunity and warn all readers: Python is a scripting language. It is not suitable for anything long-term or bigger than a couple of files. Once you are over that size, you have to fight the language to write maintainable code or do things that should be trivial, and there are too many convention-based practices out there to actually be able to rely on them. If you ever find yourself in a position where you can choose and you don't have some compelling reasons to do otherwise - avoid Python. I can go into details, but this is not the place, so here are some articles that do this for me.

Saturday, June 1, 2019

Nordic Testing Days - day 2

The second day of NTD had started just great with Alex's keynote about exploratory testing, microheuristics, and the general recommendation "notice what is it that you do" as a way to both improve (your own techniques as well as teaching others)  and help others notice the expertise you've gained. You are doing everything besides "just clicking around". This keynote had everything a keynote talk should, dinosaures included.

After the keynote I missed (again) Bailey Hanna's workshop on feedback and communication in the workplace, and instead, evacuated myself to ER.
To cut a long story short - I fell from my bike a bit over a week ago, and until then I thought recovery was going fine, so I didn't bother checking it up. After all, it was only a bruise, and it is normal to have a bulge where a hit has landed. However, once the coloration was mostly gone and the swelling did not, I did the obvious thing and googled my symptoms the night before. The results - scary. I woke up that morning at 5:30 AM and couldn't go back to sleep, so I did the responsible thing and called a doctor from my travel insurance. I described the fall and the symptoms, and strictly avoided sounding my guesses or fears to the doctor (which, in case you wondered, is the correct thing to do if you did google your symptoms - don't interfere the professionals with your uneducated guesses). I wasn't very happy to hear that the doctor was worried about the same thing as I was, and he recommended getting it checked quickly. So I did exactly that. I asked the organisers for the correct place and took a cab there.
The Estonian medical system seemed to me as efficient as I could hope for - I was taken within 10 minutes to have my vitals checked and soon after saw a doctor. Upon seeing my injury, The doctor made one of the sounds you don't want your doctor to be doing, and sent me to do an ultrasound. Then I waited, and as I did, I checked my options of returning home sooner, hoping that the doctor will say it's safe enough to postpone a surgery until I'm home. Just one thing - finding out that you might be in a life-threatening situation is no fun, and doing that far away from your home & family is even less so, please avoid that if you can.
A couple of hours later, the ultrasound results were in, and at least as far as it seems from the scan, the real situation is not dangerous at all (though it might get complicated a bit). The treatment: rest, and take an off-the-shelf medication for the pain.
Cool, that left me feeling a lot better (it's amazing what fear can do to your general feeling), suffering only the effects of not enough sleep and no real food since morning, where for the same reasons (lack of sleep, fear) I didn't have that much of an appetite. Anyways, I got back to the conference just in time to catch the closing key note, where Erik Kaju told us about the engineering practices in transferwire. It was nice, even if  I've heard such talks before. It is always nice to see that some companies are doing things a bit better than what we do back at home and we can improve.

After the conference I went to sleep for an hour, and then I joined Lisi and we went to eat dinner with Joep and Elizabeth. We tried some sort of an Indian restaurant, which was quite nice. Not as nice as the company, but still :) We broke off around 22:30 and walked back to the hotel (except for Elizabeth that was staying elsewhere). Somehow, we ended up talking at the lobby until almost 2AM, but then it was (well past) time to go to sleep.

Quite a good day after all.

Friday, May 31, 2019

Nordic Testing Days - day 1

Tutorial day is over, and it's time for the first day of the conference. I did the responsible thing and got enough sleep, despite some people (whom name shall remain undisclosed) who were dragging speakers to try out this "traditional" alcoholic beverage (and by "traditional", I mean "is probably going to kill you horribly"), so a fresh start for a new day.
I got into the venue just in time for the keynote about machine learning and testing. It was interesting,  and would have made a good track talk, I was expecting more out of a keynote.
Then, I went to give a workshop and teach people about unit testing. It's a bit long, and setup always takes longer than planned, but all in all,  I think it went well, I hope the participants agree.
After lunch i went to participate in Alex Schladebeck's workshop on testopsies and micro-heuristics, in which we spent some time learning about how to think about what it is that we do while testing. Narrating a testing session can be quite challenging, but very insightful. Being forced to communicate reason ("I'm surprised by x, so I'm going to investigate that by doing y") is a great way to both learn what we do and teach others how we think.
Apparently, one opening keynote and two workshops leave time only for the closing keynote of the day, in which Raimond Sinivee told about his journey and how relying on his existing testing skills he was able to become a well rounded software engineer (for the purpose of this talk, an engineer is someone who has both testing and development skills and is functioning in those two roles). It was a very good keynote, inspiring people in what I think to be a good direction.
Naturally, things do not simply end after the last lecture - we had a conference party, alongside with two activities I really like: lightning talks and Powerpoint karaoke. I could probably tell you about it, but it will not do it any justice. I guess you really should have been there.

Thursday, May 30, 2019

Nordic testing days 2019 - tutorial day

Tutorial day is over, and the conference is starting with a very positive note. After arriving late to Tallinn (and enjoying the beautiful weather here - rain and everything, while at home it's 35 degrees centigrade), I woke up, had some breakfast, and headed to the conference venue.
I didn't remember which workshop I chose (there were two options that I could have selected for different reasons), and was very happy that the one I preferred now was the one I chose on registration as well. I attended the tutorial on android security, hoping to have some insight to what's going over there and collect some pointer for future reference in case of need. Marko Belzetski did a fine work as an instructor and took us on a sightseeing trip that covered a lot of topics - from reverse engineering to repackaging and exploiting internal procedure calls, as well as using a proxy to inspect the outgoing data and avoid certificate pinning.
After a packed learning day, I went to the hotel to rest for half an hour, and then - off to speakers' dinner. We got up on a boat where good food and better conversation awaited.  All in all, a great way to finish a day, especially when the sun is still up at 22:30.

Tuesday, May 28, 2019

End of an era

Hebrew version

Almost two months ago ago was my last day at RSA, and I wrote a bit about it in Hebrew. I intended to publish The English version at the same day, but barely managed to get the Hebrew version out, and as it turned to be, I was a bit occupied in the past couple of months, part of it was preparing my workshop for Nordic Testing Days. Now, when I'm at the airport, waiting for a long connection, I have some time to catch on this gap.

After seven years and a bit, following an opportunity that jumped into my hands, I decided to move on. What can I say? It's not an easy decision to make after so much time, especially since RSA was my first "grown-up" job where I've learned a lot and where my entire professional persona has evolved. Such turn points are a good opportunity to look back and reflect, so here I am, reflecting.
The easiest thing is to drown thoughts with numbers, and thus I'll start with it:

  • Seven years
  • 41 team members
  • 8 managers (two of which were team members before)
  • One product, two versions (of a sort)
  • ~25 major releases
  • 13 conferences in which I've participated, in 4 of which I attended as a speaker
  • two certification diplomas, one is completely useless, and the other one is not much more so.
Naturally, those numbers are not telling any significant story, and tell nothing about how my professional approach has changed alongside with my role. 
Officially, my role in the team has not changed. I was hired as a (junior) tester, promoted to a (senior) tester and even to a (principal) tester. Each promotion came with the expectation "please continue to do what you are doing". In practice, what I did changed drastically. 
I started my way in RSA fresh out of the university after a friend who worked there referred me, and since all I knew about testing was what I've learned in one introductory course to software testing, I thought that the job of a software tester is to test software (spoiler - it is not). I started with almost decent programming skills, and with knowledge about testing that was just a bit over the required knowledge to pass the ISTQB CTFL test (The professor passing this course was a member of ITCB - the Israeli chapter of ISTQB, but we had some extra material in to fill a semester-worth of course for CS students that don't need to waste time on "what's a loop"). This meant I came prepared to write mountains of documents and to deeply analyze the software I was about to work on. Frankly, my initial experience was pretty close to that: I came to what soon became six regression cycles running back to back due to some major changes that incorporated a lot of risk - we upgraded the OS and then upgraded some central components in our system, so we had to go over most of the system just to see that nothing was very broken. We worked with tests that were written some time ago in Quality-Center, and with rudimentary automation that wasn't that great, and in most cases - simply wasn't there. In fact, one of the test scripts was so poor that I asked for, and got, some time to re-write it using the framework we've started building so that it will be easy to understand what's going on and in case of failure, understand what were the symptoms of the failure. All in all, my focus was on learning the product and while doing so, learn also how to test software. Oh, and bugs, what fun was it to find bugs. 
After about a year I got to a point of unease - I was a bit more familiar with the product, and I thought I did a decent job, but I felt that my theoretical knowledge on testing wasn't improving and I looked with my then manager (The third one, after maternity leave and a wave of layoffs) and we came to a conclusion that a course could be a good thing. But what courses are available on testing? We didn't find anything we thought was relevant or useful, but there was a CTFL certification course, so what the heck - company's paying and we're out of ideas. Now's probably the time to say: Despite what I have against this lousy certification, the preparation course can be used to learn a thing or two about testing if the instructor is experienced, you have some knowledge about how real software projects look like and you are prepared to ask a lot of "why" questions each time you hear a recommendation that does not align with reality (which is about 90% of the material). I got out of the course with some ideas for improving our process, which, unsurprisingly, included more paperwork. I think this was a point where I can mark a changing point - about the same time I decided to act upon a rumour I heard back at the university that said professional hi-tech workers should real to always stay current. I probably started doing some reading a bit before the course, but it takes some time for knowledge and impact to accumulate. That second phase came when I've encountered James Bach's &Co. ideas, out of which the most representative example is probably this video. Another idea that I found very helpful was the concept of the "testing schools" which I found convenient, as it connected well with what I learned at the university about different literary schools and, more importantly, different paradigms 1.
The concept of different testing paradigms seemed very sensible to me, and the division to five schools was convenient. The factory school, which is represented very clearly in the ISTQB syllabi (mostly in the CTFL, but it was in the others I skimmed through), is focused on managing the testing process, and treats software creation like an assembly line - where consistency and predictability are the main focus, as well as cost saving. The analytical school focuses on scientific and formal methods of measuring and improving testing, and it provides tools to practitioners of the other schools that are busy with the real world of software delivery. The agile school is focused on the developer's perspective - unit testing, TDD, fast feedback and freeing bottlenecks are the bread and butter of the agile tester, and this school provides language to engage non-testers in testing, which is mission-critical in most software projects. The control school (or, in Pettichord's terminology - "quality assurance school" tries to understand how to prevent mistakes from getting to production, on setting standards and regulations and deploying measurements to deal with bug escapes). The line between this one and the factory school is a bit blurry, but I think that having two focal points is important enough to have those two schools separate. The final school, which has assumed the title "Context Driven school" (To be honest, only people within the CDT communities are using the notion of testing schools. Others, such as Rex Black, are opposed to it) and is focused on the skills of the individual tester and treats testing as performance - In the balance between personal skills and methodology, the former has much more influence on how effective will the testing process be.
The message carried by the CDT community appealed to me very much - It said that *my* skills are the most important  to do a good job, and I found there encouragement to think on how I test software and to notice the language I was using. My focus shifted gradually from processes and bug finding to improving as a software tester.
Roughly at the same time, by the end of 2013, I connected, almost by mistake, to the local testing community. A colleague of mine told me of a testing meetup in Jerusalem and I thought it could be a good way to connect with people working in the city and maybe find my next position (I don't know if I mentioned it before, but when I first started in RSA I had full intentions of staying there for a year or two and then return to Jerusalem. A blink of an eye later and seven years have passed, me still living in a self imposed exile) I got there, met some people, and someone managed to convince me to participate in an online forum (Facebook wasn't as dominant as it is today in the testing community in Israel, or rather - the forum wasn't yet as dormant as it is today). This is how I began chatting with other testers and going to meetups.
In the meantime, things progressed at a slow and comfy pace at work - my coding skills improved, I learned the product, people and processes and there even were parts of the product I was the expert on, having been the one working on them. In addition, my team was maturing as a scrum team: We've learned to work closer and minimize gaps between functions in the team and the pace was speeding up nicely. As time passed, I noticed that most of my contribution was not while I was "working" with the software but rather when I chatted around with other team members, offering some advice, passing on rumors and asking questions, and then Brendan Connolly wrote this post, which connected well with what I was experiencing and  it helped me define my role as a nexus of information and not as "someone who comes to check that everything's ok"
Time passed, and some of the faces around me changed, when I started noticing that not enough testers at work are showing interest in professional development, and unsurprisingly, things had some place for improvement. It wasn't only that information didn't really pass between teams working on similar products, but the standards were different as well: People who worked for years in one team  didn't have the skills to even pass a basic interview for junior position in another, let alone function in that team. Once I noticed this phenomenon, it was impossible to un-notice it, so I looked for ways to help resolve this (I was sadly unsuccessful in that). Completely unrelated to this but about the same time I saw a post in Maaret's blog I was (and still am) following that published an experiment - half price tickets for a testing conference, based solely on the reputation of the organisers. Well, cool. I was wondering about professional conferences, but they were quite expensive to try out and pay for myself, and this one was not that expensive, and being in Romania it was a cheap enough flight and the extra expenses were also cheap enough for me to decide on taking a vacation and attend the conference. What can I say? The European Testing conference was a great conference to start with - I met awesome people, learned a bunch, and came back home with some ideas I wanted to try out. It was also the point where I met the European testing community2 and started disconnecting from the American CDT ideas (mainly because I connected more to an inclusive discussion instead of the debate oriented one).

I was also influenced by the changes in my team - when one of of our developers left, I found myself in a position where I was the only one in the team who was familiar with the bureaucracy around software security (or rather, the only one who was familiar with it and wasn't already swamped with back-to-back meetings) I had the opportunity to develop my understanding in software security and became the team's expert. On a side note, being an expert does not require any specific knowledge, just declaring "I'm an expert", and whenever anyone comes to you with a question, respond with "I don't know, but let's figure this out together". Another such event was when after 5 years at RSA my manager for 3 years, who was a technical leader in the team when I joined,  left to work at another place and I had to help my new manager to figure out what was going over, and in the meanwhile to shield the rest of the team from external pressures. I was thus exposed to just enough of the process of managing people to know that this is not something I want to do at the moment.

All of those processes, alongside the progress we made in combining the test and dev parts of the team, and listening to the ABTesting podcast helped me grow to the paradigm that currently appeals the most to me, which is phrased quite eloquently under the modern testing principles, which despite the name, is not a testing paradigm but rather a software production (or however you would call the process of defining, developing, testing and deploying an application) one. There is one point on which I disagree with those principles, and this is the exaggerated focus on the "customer". I wrote about this before, so I won't go into it again, I'll just mention that for me - the business comes first. I work for my employer, and in the cases where my employer interests are not aligned with the customer, I'll choose my employer.

After all this time, when I'm looking back, what I see is mostly people. Those who were there when I arrived and those who stayed there when I moved on. There were good and difficult times, and each person added their own unique something into this cauldron. I think I learned at least a bit from everyone I worked with (even if some people taught me patience by testing it over and over), I've learned that every software out is a matter of compromise, how to work as part of a team and how to write better code and talk about the principles that guide me. I learned a thing or two about software security and bureaucracy and how to both ask and receive help. Most of all, I've learned that the most important thing are the people you work with.
So, thank you for everything, and we'll probably meet again. 

1 In short, a school is a group of professionals that share a common paradigm (maybe more than one?), and a paradigm is an angle to look on and define the problem space in a field. It's a set of questions that are interesting and some tools to answer them.
For example, the "reader's response" school  is focused on answering the question "how is a text processed by a reader and what are the mechanisms through which a text is having its effect on us" (So, The Iliad would be a very different thing for contemporary readers and ancient Greeks). Questions such as "what was the writer's intentions" are mostly irrelevant and secondary to the perception of the act of reading as a dialog between the reader and the text) 

2 I use the term "European testing community" from my own personal perspective, There are multiple testing communities in Europe, with varying amounts of overlapping. I use this term to note the people I met through ETC (not necessarily at ETC, though) 

Monday, April 1, 2019

סופה של תקופה

היום הוא היום האחרון שלי בRSA. 
אחרי שבע שנים וקצת, בעקבות הזדמנות שפחות או יותר קפצה לי לידיים, החלטתי לעזוב את מקום העבודה ולהמשיך הלאה, ומה אגיד לכם? לא קל לעזוב מקום אחרי תקופה כזו ארוכה, בטח לא את מקום העבודה הראשון בו התפתחה כמעט כל האישיות המקצועית שלי עד כה.בכל אופן, סיכומי תקופה כאלה הם הזדמנות לא רעה להסתכל לאחור ולחשוב קצת אז הנה אני, חושב קצת.
הדבר הכי קל הוא להטביע את הכל במספרים, אז אני חושב שאתחיל בזה - 
  • שבע שנים
  • ארבעים ואחד חברי צוות
  • שמונה מנהלים (שניים היום חביר צוות מן המניין קודם)
  • שלושה אנשים שהיו בעבודה לפני ועדיין נמצאים שם
  • ארבע חתונות בצוות ולפחות שמונה לידות
  • מוצר אחד
  • בערך 25 גרסאות "גדולות" ואינספור תיקונים קטנים
  • 10 כנסים בהם השתתפתי , בארבעה מתוכם הרציתי
  • שתי תעודות הסמכה, אחת מהן מיותרת לחלוטין
אבל כמובן, המספרים לא באמת מספרים שום דבר משמעותי, ובטח לא מייצגים את השינויים שחלו בגישה המקצועית שלי ובתפקידים שלי בתוך הצוות. 
מבחינה רשמית, התפקיד שלי בתוך הצוות לא באמת השתנה - גוייסתי כבודק תוכנה מתחיל, ופעמיים במהלך העבודה סיפרו לי שהחליפו לי את הקידומת ל"Senior" ואז ל"Principal", אבל הדברים האלה קרו בלי להוסיף ציפיות רשמיות למה שכבר עשיתי. בפועל, לעומת זאת, השינוי היה דרמטי מאוד. 
התקבלתי לעבודה היישר מהאוניברסיטה, בעקבות הפנייה של חברה, וכיוון שכל מה שידעתי על בדיקות תוכנה היה קורס של סמסטר אחד, חשבתי שתפקידו של בודק תוכנה הוא, ובכן, לבדוק תוכנה (ספויילר - זה לא). הגעתי עם יכולות תכנות סבירות מינוס, ועם ידע בבדיקות שהוא רק קצת יותר מקיף מזה של מי שעבר את בחינת ISTQB CTFL (הקורס באוניברסיטה הועבר ע"י אחד מחברי ITCB, שהוסיף עוד נושא או שניים כדי למלא סמסטר). זה אומר שהגעתי עם כל הכוונות לכתוב הררי ניירת, ולנתח לעומק את התוכנה עליה אני עובד. ובאמת, החווייה הראשונה שלי הייתה  קרובה מאוד לציפיות - רצה הגורל והגעתי בדיוק לתחילתם של שישה סבבי רגרסיה מלאה על המוצר. בדיוק החלפנו מערכת הפעלה, ואז שדרגנו כמה רכיבים מרכזיים בהפתעה, ובכל פעם היה צורך לעבור על כל המערכת מחדש. עבדנו עם בדיקות שנכתבו בQuality Center ועם אוטומציה שהייתה, במקרה הטוב, ראשונית ולא מדהימה, ובדרך כלל פשוט לא הייתה. מתישהו גם ביקשתי, וקיבלתי, קצת זמן כדי לכתוב מחדש כמה מבדקים אוטומטיים בצורה שתאפשר להם לרוץ באופן שיאפשר לנו להבין מה קורה שם.  באופן כללי, הפוקוס שלי היה לנסות להבין את המוצר עליו עבדתי ועל הדרך ללמוד איך לבדוק תוכנה. ובאגים, איזה כיף היה למצוא באגים. 
אחרי בערך שנה הגעתי למקום בו התחלתי להרגיש חוסר נוחות מסויים - עבדתי על המוצר, וחשבתי שעשיתי עבודה לא רעה, אבל הרגשתי שהבסיס התיאורטי שלי לגבי בדיקות תוכנה לא מתקדם לשום מקום וחיפשתי עם המנהל שלי (אחרי חופשת לידה של המנהלת שגייסה אותי וגל קיצוצים, זה היה המנהל השלישי שלי) והגענו למסקנה שאולי הגיע הזמן לבחור קורס, וכיוון שאין שום דבר רלוונטי, ניקח קורס הסמכת CTFL. לא ציפינו להמון ידע חדש, אבל היה תקציב לקורס, ולא היה לנו רעיון טוב יותר. זה כנראה הזמן לומר - עם כל מה שיש לי נגד ההסמכה המצו'קמקת הזו, אפשר לנצל את קורס ההכנה כדי ללמוד דבר או שניים על בדיקות - בתנאי שהמדריך (ובמקרה שלי, מדריכה) מנוסה, אתם ראיתם דבר או שניים בתעשייה ואתם מוכנים לשאול הרבה מאוד "למה" בכל פעם בה החומר הנלמד לא קשור למציאות . יצאתי מהקורס עם רעיונות לכמה שיפורים בדרך בה עבדנו. שלא במפתיע, המשמעות הייתה עוד ניירת. אני חושב שכאן אפשר לסמן את תחילת הזמן בו התחלתי להקדיש תשומת לב לבדיקות תוכנה כמקצוע ותחום ידע בפני עצמו. הסימון הזה כנראה לא מאוד מדוייק, כי כבר באוניברסיטה שמעתי שמועה על זה שצריך לקרוא כל הזמן ולהישאר מעודכנים, ואני די בטוח שעוד קודם לקורס הזה חיפשתי בגוגל כמה בלוגים והתחלתי לקרוא, אבל לדברים האלה לוקח קצת זמן להצטבר. 
ואם כבר אנחנו מדברים על קריאה, השלב השני בקריירה שלי התחיל כשתקלתי בכמה רעיונות של ג'יימס באך ושות', מתוכן הדוגמה הכי מייצגת היא כנראה הוידיאו הזה, והרעיון של אסכולות שונות בבדיקות מאוד קסם לי. כשלמדתי ספרות באוניברסיטה, למדנו על אסכולות, ובאופן ספציפי יותר, על פרדיגמות1
הרעיון של פרדיגמות שונות בבדיקות תוכנה נראה לי שימושי למדי, והחלוקה לחמש אסכולות נשמעה לי נוחה - אסכולת המפעל, שמיוצגת באופן מובהק למדי בסילבוס הבסיסי של ISTQB, מתמקדת בניהול תהליך הבדיקות, ומתייחסת לייצור תוכנה כאל פס-ייצור במפעל, בו עקביות ויכולת חיזוי הם המטרה, יחד עם שיפור בעלויות הבדיקה. האסכולה האקדמית שמתעסקת בשאלות טכניות של מדידת ושיפור הבדיקות באופן מתודולוגי מספקת כלים לאסכולות האחרות שממוקדות ביישום פרקטי של בדיקות בעולם האמיתי. האסכולה האג'ילית שממוקדת בבדיקות מנקודת מבטו של המתכנת, עוזרת להטמיע בדיקות תוכנה בקרב אלו שבדיקות אינן מוקד הקריירה העיקרי שלהם,  אסכולת השומר בשער שמנסה להבין כיצד למנוע מתקלות להגיע לעולם החיצון, מתעסקת בתקנים, במציאת בלמים אפקטיביים ובאיתור תקלות שחמקו. הגבולות בין האסכולה הזו לאסכולת המפעל קצת מטושטשים, אבל אלו שני דגשים חשובים לניהול עסק. האסכולה האחרונה, שלקחה לעצמה את התואר "בדיקות מוכוונות הקשר" (ויש לציין, שיח האסכולות קיים אך ורק אצל אלו שמגדירים את עצמם כחלק מקהילת CDT, אז הם היחידים שזכו לבחור לעצמם שם) שמתמקדת בעיקר בכישורי בודק התוכנה ומתייחסת לבדיקות כאל ביצוע - במשוואה שבין איכות התהליך לטיב בודקי התוכנה, לפרמטר האחרון יש השפעה רבה יותר על אפקטיביות תהליך הבדיקות בחברה. 
הרעיון של CDT מצא חן בעיני מאוד, והוא עודד אותי לחשוב על האופן בו אני בודק תוכנה ועל האופן בו אני מדבר על בדיקות תוכנה עם אחרים. בהדרגה לאורך השנים מרכז תשומת הלב שלי עבר לשאלה הזו - כיצד אני יכול לשפר את האופן בו אני בודק תוכנה. 
במקביל, לקראת סוף 2013, מצאתי את עצמי מתחבר לקהילה המקצועית המקומית. זה התחיל כשעמית לעבודה סיפר לי על מיטאפ בירושלים, וחשבתי שזו יכולה להיות דרך מוצלחת להכיר אנשים ולשמוע על משרות בעיר (אני לא יודע אם כתבתי את זה כאן בעבר, אבל כשהגעתי לעבודה, הייתה לי כוונה מלאה להישאר שם שנה-שנתיים, לצבור קצת ניסיון ואז לחזור לעיר הקודש. מצמוץ ורבע אחר כך, ואני כבר שבע שנים גולה בהרצליה). אז הגעתי, פגשתי כמה אנשים טובים, ומישהו, בואו נקרא לו קובי, הצליח לשכנע אותי להיכנס לפורום בתפוז ולהשתתף קצת בדיונים שם. כן, פייסבוק היה פחות משמעותי אז. מן הון להון, התחלתי להגיע למפגשים, ולדבר עם בודקי תוכנה אחרים. 

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

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

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

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

2   אני משתמש במונח "קהילת הבודקים האירופאית" מנקודת המבט שלי, זו לא בדיוק קהילה אחת, והיא לא הקהילה האירופאית היחידה - מבחינתי, אני מתייחס לאוסף האנשים שפגשתי דרך ETC בשם הזה

Saturday, March 16, 2019

איכות בארון

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

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

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

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

Quality in the closet

Don't we just love this word? It gives us that warm and fuzzy feeling of doing something well.  But there's something wrong about the way we use it.
I've started thinking about it when I was processing my disagreement with the 5th principle of modern testing and mentioned Jerry Weinberg's definition of quality - value for someone. Then, shortly after, a lot of distractions took over (one very positive such distraction was European Testing Conference) and I put this issue aside for a moment, at least until other things reminded me I had some more to write on this subject.

So, what do I mean by "broken"? Or rather, why do I say it's broken? To answer that I want to go back to school and to the definitions of the trigonometric functions. More specifically, to sine & cosine.
When we were first introduced to the idea of a sine it was through a question: since we know that the relative edge sizes of similar triangles is the same, what can we tell about the size of a right angled triangle's legs related to the hypotenuse? To answer that question we introduced two new mathematical functions - the sine and the cosine. School being school, we went to practice it for a bit, calculating the size of various edges. After getting used to it, the teacher asked a question: What would be the value of a sine for values that are less than zero or more than 90 degrees? The action, at least for the moment, was undefined. Well, what about a new definition? The value of sine(a) for any angle a is the y value of the intersection point between the unit circle and a radius forming an angle of "a" with the X axis. cosine shall be defined to be the x value of that same very point. Great, right? Now we can have this function defined for whichever value we want, and can even deduct some cool properties of those function rather easily (for instance, cosine(x)=cosine(-x)) There's only one thing to do - prove that the new definition does not contradict our previous definition, and it agrees with it at any point where both definitions hold. This proof is rather easy, and the studious readers can complete this exercise by themselves, but this is where I return to the definition of quality in software. Something in the way we define quality is broken. Our definition is inconsistent with the definition of quality in other domains. Moreover, the properties displayed by "quality" examples outside of software are very different than those displayed by software.
Picture an armoire, and not a simple, generic one, a sturdy, dark mahogany armoire, with double doors decorated with fine engravings and polished brass handles. Do you have a picture in mind? Great. Now picture another one, roughly about the same size and shape, made out of plywood, assembled by you with the help of the very detailed Ikea guide, with most screws fitting snugly into their dedicated sockets. Which of the two would you say is of a better quality? Which one are you more likely to see in someone's appartement?
Most people would answer that the mahogany armoire is of better quality, but that the Ikea one is more likely to be used. Why? Because it's cheaper, more accessible, and it doesn't really matter a lot if your child would draw on it with crayons. It might be of lesser quality, but the price is low enough so that we won't mind replacing it every decade or so, and we might even look at it as an opportunity to replace and renew the furniture, which can be nice. Also, if we move to another apartment, as some people do, it will be much easier to leave that armoire behind or resell it instead of going through the fuss of taking it with us. Quality is not the same as "being used a lot", and in fact, the extra cost paid for quality usually makes it used less.
It's not only physical goods that have those properties, if we'll wander to the realms of literature for a moment and compare The Harry Potter series to the Iliad we'll see that the same is true there. Most people would agree that the Iliad is a masterpiece, and that Harry Potter, which sometimes is having difficulties even keeping consistent with itself, is not1. And yet, Harry Potter is being purchased and read far more than the Iliad. Despite the fact the most people would rather spend an evening reading Harry Potter, "quality" is not the reason they do it. In fact, with the exception of software, quality items are less common than their shoddy counterparts. Why would measuring the use of software be any indication of its quality?
We can try to understand the reasons behind this conceptual mistake, and I have my own lousy guesses, but that's not really that important. What is important is to understand that when we use an improper term (or use a term improperly), we mess up all of our gut feelings. It means that we are trying to use quality processes to solve marketing and sales problems, or that we borrow some odd measurements and processes from other fields that mention "quality" (Can anyone explain to me please how on earth did 6-sigma make its way from manufacturing to a presentation about software quality?) This mix also sends us chasing our tail trying to achieve "quality" in places we shouldn't. And, obviously, it causes many people to waste a lot of time and words trying to define "quality" (I considered looking for a link or two for examples, but what have you been reading here up until now?).

As software people, we should stop treating quality as a goal by itself and remember that it is one property that might help us achieve our business goals. When we think about it like that, it is perfectly fine to skip a meticulous definition of this term, since "I'll know it when I see it" is good enough for a single (not that important) property of what makes a project successful. Most importantly, we should embrace the fact that in software too, it is acceptable (and common) to look for Ikea-level quality.

1 I'm not claiming that Harry Potter is bad - it is fun and fluent and has many interesting things in it, it just isn't a masterpiece 

Friday, February 22, 2019

Exploratory Testing Peer conference 2019 (or: ETC 2019, day 3 - sort of)

As I've mentioned before, I found a way to extend ETC by joining "Exploratory testing peer conference" that was organised by Maaret Pyhäjärvi, Anne-Marie Charrett and Alex Schladebeck. In essence, a full day of people talking about ET and trying to see what does ET mean today, after 30-odd years since the term was coined and kickstart some work to current knowledge to this domain.
Regardless of how would this day go, I learned one thing already: simply ask - I would not be having this experience without asking to join, and I'm very glad I did that. I'm also very thankful for being allowed to join, as it was a great learning experience for me.
I've never been to a peer conference before, and I didn't know what to expect, besides a bunch of smart people (and me) talking in a room, which is usually a great start.
The discussion was facilitated masterfully by Alex, using K-cards and we had an interesting addition to this: we had on the whiteboard the twitter handles of every participant, and noted each time. It looked like so:

This had an interesting effect, at least on me - I was more conscious about giving others time to speak (I received in the past feedback about taking too much "spotlight time" and am trying to be more aware of that) and I could use this tool to actually measure how much do I speak in comparison to others. The answer, which is not in this picture, is that even when I try, and even after asking several times to drop my turn after someone said something similar enough, I still ended up speaking more times than most, if not all, participants.

The subjects themselves were quite versatile: we spoke about sharing intent while mobbing, teaching ET to developers, what happens when good exploratory testers are looking on unit tests, an experience report on trying to integrate ET practices on large scale dark-scrum organization, how to give a 5 minutes elevator pitch on ET and microheuristics. Those are only the topics we got to actually talk about, and there were many more ideas, as can be seen here:

One important feature of the K-cards for such discussions is the blue note (orange in our case, due to logistics), the ability to signal "We're done \ losing focus \ I'm bored" is important and helped us several time during the day. 
Another thing I liked was  that after each discussion (at least in the first half of the day) we did a quick retrospective on the discussion and came up with some improvements. I have never before seen such a large group of people having a discussion that was so well organised. 

Naturally, there are some things I think we can improve for the next time. The main thing is to have a clearer goal for the peer conference. With a topic as vast as ET and with so little time, I felt the need for a narrower question\topic. During one of the breaks, after a discussion that we felt went astray, Lisi and I stood next to the board and tried to see which subjects are in the intended theme of the day (As we understood it) and as you can see in the picture above,  out of the 12 topics on the board at the moment, only 5 were positively there, and 4 were about something completely different that happened to have some ET close to it.  We could either trust the organisers to design a format for the day, or spend a short time box and decide on the way we wanted to do things, but as it was, we started the discussion without agreeing explicitly on our goal, which I think caused some friction. 

One thing I can surely say - If I thought that participating in a conference is an intense experience, this peer-conference took it up a notch. In a larger conference, it is always possible to find some small places to rest - either lose some focus in a talk, or find a corner where the crowd is providing some white-noise. With 24 people in the room, even taking a break is still speaking with the same people, and the mind-work done by actively participating in a discussion is more intense. At some point, just to get some air and let the mind rest a bit I went outside to play catch with Mira. By the end of the day, most of us were a bit depleted, in the most positive way possible. 

Of course, no conference is just ending just when the official time is up, and we all started to walk towards the hotel. In a smaller group, some further discussion was continuing and I think I got to understand better some of the words people were using. Eventually, though, we've decided it was enough, and started talking about getting something to eat. As it happened, I ended up walking with Thomas and Lisi. We just walked about, chilling off and talking. After such an intense day, I felt very recharged just speaking with them quietly. Then we got to a park that had a notice sign - closes in 20:30. As we still had well over an hour, we entered and walked through it for a while. when at 20:00 we got to the gate through which we've entered, we found it locked, as were the next gate and the two after it. We were starting to be slightly worried, but not very much. eventually, we saw someone other than us in the park, and could see an open gate. From there we could walk back to the city center and had a nice dinner. A great way to finish the day. 

Monday, February 18, 2019

ETC 2019 - day 2

Sketch by Marianne Duijst

So, after going to sleep somewhere around 01:30, I woke up for a completely new conference day, and I even got almost 6 hours of sleep, which is quite good for a conference night.
I met with Mor for breakfast and we headed to the conference venue. Today’s opening keynote was Dr. Sal Freundenberg’s story on getting back to working as a coder after a long time of doing other things, and to make things more interesting, she was doing that while ticking some checkboxes that make hiring harder even without such a break – being older, female, and autistic. What I liked in this keynote was how she took action to her own hands and took conscious steps to get her goal – Older (and experienced)? That means there are friends she could pair with to brush off the rust and reacquaint with the current tools & trends. Problem with bright lights, big crowds and loud noises? Find a place that works remotely and customize the workspace (I really liked the fidget things on the table). All in all, it showed that getting back after a long pause is possible, and at least by the way it was told – there can be a lot of fun in doing so.
Then it was time for the workshops – I chose to participate in Anne-Marie Charrett’s workshop about exploring an API. Right at the beginning I was informed that the focus of this workshop would be the opposite of what I hoped for and would be an introduction to restful APIs and show how they can be explored, rather than to assume familiarity with APIs and systematically exploring one. I decided to stay, since even in this case I could still see some of Anne-Marie’s ideas of exploration and use them to learn. I wasn’t disappointed – we started by modeling the application under test (found in ) we then started questioning the model and using the software to get some answers. We missed a bit of the instructions and started only to form the questions, but it was valuable nonetheless.
After the workshop I went to Clare Sudbury’s talk about how not having unit tests for a game she was creating for herself came back to bite her in the rear and how she used pairing to keep herself honest and avoid costly shortcuts. I really wish I could convey the feeling she projected in the room and pass it on to everyone who thinks unit tests are a waste of time, since the dry facts don’t do this story any justice at all. The animated GIFs were a nice addition.
I stayed in the same room in order to listen to the next talk: "playing port authority", which was about "unit testing" your docker configuration files. From all of the events I attended, this is the only one I was disappointed with, probably due to having wrong expectations – This talk was about a specific tool, written in Ruby. While this tool does seem to provide some nice shortcuts, it does not really do anything revolutionary or even interesting, and I say that as a person who is completely unfamiliar with Docker beyond the basic concept. Those tests are long (makes sense, since the setup is “deploy a container, installed whatever is needed”) and all the tool is doing is to wrap Docker API in order to provide some verification. If I ever face the need to test containers in such manner and I happen to be working in a language other than Ruby, I’ll probably go and write my own wrapper around it instead of adding another language to the soup. Things that would have made this talk better for me would have been answers to questions such as “Why would I want to perform such verification instead of checking it once and run faster checks on the docker yaml file? When it is appropriate to use? When it isn’t? What concepts make this specific tool better than what’s out there? What would I have to implement myself if I am not using Ruby? When is it appropriate to run such tests? What sort of infrastructure is required to gain benefit from such tests?
As it was, it’s been “just another tool” talk, and I am less connected to such talks.
But, no worry – after a short coffee break came the time for open space, which I have never seen go wrong. This time was different only in one thing – I managed to avoid suggesting a session myself. There were so many other sessions that were interesting. Since my coding fingers were tingling, I participated in Maaret’s session on exploring with unit tests where we used Emily Bach's Gilded Rose Kata as our target. It was interesting and I think I got a thing or two about using unit tests from it. I then moved to a discussion about contributing to open source projects, and seeing that I don’t add or gain value there I invoked the rule of 2 feet and moved to the middle of a session by Jessica Davis about “tips for the new tester”, the session was briefly hijacked in order to help another tester with about a year of experience to set up expectations and prepare for onboarding a senior tester to the team. After the session has dispersed we continued to chat a bit around this and I provided whatever opinions I had (which, as those reading here probably know, are not very intelligent, but sometimes sounds convincing).
After the open space time-slot has ended, it was time for the closing keynote. This time – Ash Coleman’s Story of being a minority in tech. I cannot stress enough the importance of this talk, which speaks, as you might have guessed, about diversity and inclusion. Most of the time it’s easy to dismiss diversity issues with a plethora of excuses (those are the people we find, or those are the only who are staying, or anything else. But in fact, the reasons behind such excuses are that that place probably has some unconscious ways of excluding people different than the mainstream. It might be assigning value to irrelevant properties (“His salary is higher because he has a degree from a top-college” is an example – if people are doing the same kind of work with the same skills, it really shouldn’t matter where did they get those skills). My main takeaway from that was that difficulties that are common for an underrepresented group are usually ignored, misunderstood or dismissed by people of the dominant group, thus prolonging the inequality. I went to ask Ash later what can I do to mitigate this blindness, and her answer was to find in my environment someone I can trust who is part of such underrepresented group and ask them to tell me when I’m missing something, mirror to me my behavior or ask explicitly for my help in cases where I’m not seeing the need for such. I’m keeping this advice with me.
That’s it. The conference was done. Now it was time to say thank you and goodbye to a lot of people. I helped clean the auditorium (a fun part of that was to peel Marianne’s sketches from the walls and roll them up). Somewhere around that time I Asked Maaret about that peer workshop she mentioned during the open space and asked if I can squeeze in (The answer was yes, for which I’m grateful). After that I took a short while to rest in my room and joined a large group of people (including a few who were not at the conference but came to participate in the peer workshop) in a bar somewhere in the city center. We chatted a bit, had some fun and some drinks, then went to another place to eat.
Dinner was great – a whole lot of people that I wish I could spend some more time with. I don’t remember how we started speaking about languages, but we were all thrilled to learn that the same word (“rahat”) is used in Finnish to indicate money and in Romanian it means “poop” (There was a story about a parking tickets machine that asked for money, but i don't recall the exact term or it's translation from Romanian to English, maybe "Loud poop" or something like that). By the end of the evening I found myself with Lisi, Kristine & Jessica who told us how she got around to be in this conference (and her way into testing, as well). Kind of a cool story, I think.
Back at the hotel, some people were still at the lobby. I got to listen to Marit, Sarah, Franzi and Clare talk about difficulties in the work place that males do not experience.
An important reminder to any male readers – The fact that you are allowed to listen to such a conversation is not an invitation to sound your own opinions. It might be ok to ask a question here and there, but generally the right thing to do is to STFU and listen. Who knows, you might learn something new. I, for example, learned about the concept of a sponsor in a workplace and why is it important.
Then – sleep before the peer workshop starts, and more on this - in a later post.