טוב יותר מאשר ציפיתי 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. 

"קודם תלמד בדיקות" "First you have to learn testing

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

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

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

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

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

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

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

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

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

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

---

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 goal¹ 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 ^↩

Why do I (try, and sometimes manage to) speak at conferences?

In here, Maaret shared her reasons for speaking and attending conferences, and finished with a question - why do you?
So, I'm only starting my way in this area, and from where I stand, conferences are really fun. At every conference I find someone to wander with and have really interesting discussions. I get to hear ideas that open my eyes to other ways of working and I get a small peek at the challenges other people are facing. At this phase, at least - it's a marvel every time.
But, how did I get to the point where submitting a talk is something I even consider?
Well, that story starts with me watching a video - I was watching CAST-live in August 2015. Not ideal, as the hours were diving deep into the night with 7 hours time difference, but still, I enjoyed watching the talks. One of the talks I saw and stayed with me was Ioana Serban's talk: Taking control of your test environment, which is a really great talk to watch, especially for people at the start of their career. It was then that I really thought "hey, it could be nice to actually try and attend one of those in person" I did ask the place I work for to send me to cast that year(by some odd chance, cast was the first conference I heard about that looked interesting), but when they couldn't find the budget for it in the short notice I gave them ("hey, I found this conference, wanna pay ~3500$ to send me there?"), I just shrugged and moved on. Watching this talk put one thought in my head - there are cool ideas at conferences.
Then, lucky me, Maaret posted this, and I thought to myself - I really appreciate Maaret's ideas and writing, Romania is not expensive and is fairly close so the flight should be cheap as well, so if she's asking me to trust her to create a conference and in the by process I can also get a conference ticket in a price I can afford myself, I'm jumping on the opportunity.
I got to the conference, and the experience was amazing. People were very kind and I got a ton of new ideas and experiences. One funny thing I noticed was that with one single exception everyone with whom I had a conversation turned out to be a speaker. At the conference lean coffee session, I ended hearing from a developer about her experience in working with some doctors on a software for them and we had a nice chat that continued a bit into the break. The day after I attended her talk. I got a bit late to a workshop and started working with Gita Malinovska, who apparently was also a speaker. After hearing Emma Keaveny talk about dark patterns we had a talk that caused us all to be late to the closing keynote of the day. Later at the evening conference party I had a really nice talk with a friendly tester I then did not know by reputation (I was even less connected to the global community than I currently am), but Richard Bradshaw turned out to be a very interesting person to talk with. At a mobbing demo I got to work with some people including Abby Bangser that gave a talk I really enjoyed the day before, and somewhere in the conference I got to speak a bit with Franziska Sauerwein and Simon Schrijver  - both speakers at the conference. So, I figured, that's where all the cool kids are. I want in on that club.
It also really helped that in the conference slack channel (which I really liked) there was an open-space, and I got to talk a bit about my experience with threat modeling, and had a great time doing so.
But, then, sometime as the conference was coming to a close, Maaret said to me "I heard you spoke about software security, maybe you should try submitting a talk". That, probably, was the point where everything was decided - I had a string motivation (cool kids, remember?) a positive, safe, experience, and the little very needed nudge.
Next August, when I got my workplace to send me to CAST in Vancouver, the experience did repeat itself (though less strongly) and my resolution to start speaking got another confirmation.

So, next year I tried to submit a talk to ETC, and was rejected (Having attended the conference in Helsinki, I can attest that every talk there was at least as good as my submission, and most of them far better), but the rejection notice came with a suggestion (Nordic Testing Days are looking for speakers, why don't you try?), and they gave me the opportunity to speak there.
Talk's over, and at least for now - I'm hooked.

So, why did I start speaking?
I think that every reason we can find can probably be traced back to Maaret or something she'd done - Thank you.

Why do I speak?
 - As I mentioned, it's where there's a high concentration of cool people. This way I get in that circle and get to meet more of them.
- It's cool to share ideas that might help other people who face similar challenges.
- I can allow getting to more conferences, and, if that would be relevant, I have a good reason to ask my workplace to help financing me travelling (Quite happily, most conferences I'm interested in attending are covering expenses, which I see as ETC slowly achieving one of its goals of changing the conferences world, and for which I'm grateful).
- Preparing a presentation forces me to formulate my ideas and give people a chance to poke holes in them. It's challenging and fun at the same time.


You should too.
And, regardless of whether you speak or not, you should attend ETC. It's in Amsterdam this year, and I already regret not being able to be in three places at once to hear the talks I want to. Here, have a look.
-------------------------------------------------------------------------------------------------
(no Hebrew this time, at least not currently).

quick peek

So, I have not been here for a while. In fact, for too long.
This is because of... reasons.
One of those is that I'm working on the talk I'll be presenting at the European Testing Conference.
Speaking of which - you should be there. And if you do, I have a discount code to share with you a 15% discount code, just drop me a message (you can do so here on the left).
Also, If you hurry, the early bird registration is up until the end of the month.

Go and register, if you need a reminder why - here's what I have said.

I've fallen and I can't get up

A common theme around testing is answering the question "How did you fall into testing". Honestly? I cringe a bit every time I hear this question. It might be that English is not my native language, but when I hear "fallen" I get the impression of someone lying hopeless on their back, waiting for someone to come to the rescue.
Well, at a certain point, every tester chooses to become one - It might be after working as a tester for some time, or after a really crappy day at a different type of work, or, as is my case - after being exposed to testing as part of my CS degree. Sure, most people don't grow up dreaming of being a software tester,  but neither they want to become a project manager, or a financial analyst - those jobs are not visible to children as is driving a truck, being an astronaut or creating a piece of software. At some point, an opportunity presents itself, and a tester chooses it. People rarely wake up and say "whad'ya know? I've been testing for a decade, I must be a tester".

The Application Security PodCast is dealing with the same problem - most security expert have quite a versatile background and have chosen security as a career in a later phase. Whenever they interview someone, they don't ask "how did you fall into security?", they ask "What is your superhero origin story?"

Isn't that a bit more fun to hear?

Early birdהציפורים שרות לי בוקר טוב

Just in case you managed to miss this one - the Europen Testing Conference  has opened its gates and the early bird registration has started and will end soon (end of November, which, for those working in a corporate environment and wanting to use their training budget, is not a lot of time to get the bureaucracy sorted out).

Before I go on spilling some of the praises I have for this conference, do yourself a favor and go buy a ticket. 

Done? Great.

So, I didn't go to a lot of conferences so far, and I'm not about to start ranking those I attended - as they all great, each in its own unique way. Still, ETC is the conference I feel the most connected to. It might be because I was lucky enough to attend the first ever ETC in Romania a couple of years ago, or that this is the only conference (so far) I've been in more than once, or maybe it is just suits what I'm looking for in a conference. It also helps that this is a VERY good conference. 

So, what is it I really like about this conference? 

1. It's a peer conference. No one is trying to sell me stuff I don't need, but rather people share what they are interested in. 
2. The talk selection in the conferences so far has been superb. I still go back to the 2016 site in order to send people links to videos of the talks (Just a week ago I've sent Jesse Alford's talk about testers patching up gaps where needed, and I probably need to send Linda Rising's talk as well to someone else). If you have not done so yet, clear yourself some time and watch the talks.
   (By the way, if any of the organizers read this - I will probably ping you later about it, but just in case I forget - Those recorded talks are of significant value to me)
3. The organizers Credo.
   The conference is stating very clear values, and their actions are true to their words. If I have to try to put my own words to the main principles that guide this conference (which I'm sure the organizers did in much better wording, so any faults here are mine), it would be something like this:
1. This conference is about conferring. Meeting people who take interest in testing and getting a chance to talk with them. Yep, it's not only about the speakers, it's about listening to everyone who attends. 
2. This conference is as diverse and inclusive as the organizers can make it, and this means there are a ton of different experiences around. And they can  do quite a lot. 
3. They are here to change the conference world. In this case, it would be easier for me to point to what Maaret has written in 2016.
   The short version - They see speakers as partners and try to make sure speakers don't have to pay to speak. The really cool thing? They also help speakers who can't afford speaking in other conferences. 
4. They Learn and experiment. I thought they had it all nailed down the first time - Everything was great, and so well organized. I was amazed. Next year, There were several new experiments - speed meeting was one of them (I didn't like it much, others did - quite a lot). I really want to know what they are planning for this year. 
5. They listen - By the end of each conference day, they did a retrospective. They took the feedback in and worked to improve. For instance, following the feedback from last year, workshops will be given twice. They also go an extra mile to collect feedback - last year they had people with an app standing at the exits just asking for a good\bad\neutral feedback on the talk. 
6. They stress audience participation. I mentioned it once already, but it is such a huge thing in the conference I think it deserves a bullet of its own. Even if you are not a speaker, there will be place for you to share your ideas and what excites or worries or interests you - we had lightning talks, lean coffee and open space - all dedicated to letting the participants to find their own voice. 
7. They care. A lot. I can't really pinpoint this to one specific behavior, but every choice I could see shows great care for the people involved.

There are a million tiny things I like about this conference - from the fact they ask their speakers to attend the entire conference to help promote a discussion, to the way they select talks (They speak with anyone who has submitted a talk idea, and provide feedback. It is by far the most pleasant submission process I have seen in conferences). 

So, briefly, that was why I think you should attend - it is a great conference, and by attending you will be helping both yourselves and an organization with some causes and actions I think we should all support.

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

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

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

זהו? קניתם? 

אחלה. בואו נמשיך. 

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

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

אז מה אני כל כך אוהב בכנס הזה?

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

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

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

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

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

סוסי בעד תיעוד! My Horse for a document!

את הממלכה, אחרי הכל, כבר החלפנו בסוס. 

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

כמה תובנות שעלו לי במהלך החיפושים - 

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

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

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

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

The kingdom, after all, was already traded for that horse. 

Recently I had the opportunity of playing with several (three) open source(ish) projects. Trying to utilize them. Although the projects are very different in size, purpose, maturity level and community size, one experience was very similar - I knew what I wanted to do. I knew it could be done with the tool, but I spent a whole lot of time trying to figure out the "how" part. Despite the fact that in both cases there was some impressive effort invested into documentation, it just so happened that what I was trying to do somehow wasn't there. With the smaller, less mature project (Allure framework), I ended up cloning the repository and grepping through the source code looking for hints. 

Some insights that I came to while enjoying my wasted time: 

• Unit tests are not really documentation, but they are a semi-decent examples of how to use code. If there isn't anything better, I can try to decipher what I need from them - as long as they are readable. 
• For the love of G*d, write comments. I don't mean commenting the hell out of your code, but a header for every non-trivial class is nice. It's also a great place to write down the "why" part to supplement that "what" part that is in the code.
  Also, if you write an interface that others might implement, please do everyone a favour and write some javadoc above each public method, so that when I come to implement some of it, I can know what I should be doing there. 
• Discoverability is key. It shouldn't be hard to find information about your code, so please pay attention to as many aspects of it as you can - Reasonable naming conventions, clear division of responsibilities, example code, manuals. Heck, even an active user forum might be nice.
• Documentation, documentation, Documentation. I've yet to meet someone that enjoyed writing it, I've yet to meet someone who didn't mutter (or cry out in agony) at least once "why couldn't they write some clear instructions for this?" (Quite often, "they" will be the same team, 6 months ago). Maintaining it is hard, painful and not really fun, but it could be the difference between a product that is pleasant to work with, and something that everyone tries to avoid. 

So, if your team is exposing an API or releasing an SDK - pay double attention to those. You will be saving time to your customers, desperate phone calls to your support team, and you will gain a whole lot of good karma.

Everything is internal? are you building a perfect little closed garden? Cool. You can probably cut some corners. However, do keep in mind that the most important consumer of these discoverability services  - which is future you - will thank you for those little breadcrumbs you leave as you go. 

Or, you could take this approach: 

Your choice. 

תזכורת על חשיבות התזמון Reminder about timely feedback

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

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

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

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

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

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

One of the things commonly said about software testing is that it is the business of providing information - focusing on timely & relevant information. 

However, this doesn't always work out well. Yesterday, in Thursday, I spent several hours reviewing a document sent to me by a colleague. One of my comments was "the scope of this document is wrong" and another one was "I'm missing some sections about this, this and that". Knowing that these changes mean quite a bit of work I hopped over to the room next door and had a little chat with the author. We both agreed that the changes would make the document better, but a review meeting is already set to Sunday, and it isn't easy to get the relevant people in one room, so moving the meeting is quite expensive, even ignoring the other stress factor that want this review done (some very pushy project managers and possibly a miscommunication with some customers). Making those changes would require a bit more than half a day (Weekend in Israel is Friday & Saturday)  and we both agree that presenting the document as is would be better to presenting a better version of it later. Still, now both of us are bummed because we know this could have been better had I come up with this feedback a couple of days earlier. 

The sad part is that I don't think there's much to learn here. It's a reminder of why timely feedback is important, but given a similar situation I would probably behave in a similar manner, postponing the review to deal with more urgent (and more important) tasks. Most of the times, my comments might be numerous and require some work to fix, but it is usually less than half a day.  Maybe, had I skimmed the document... but it took me about half an hour to realize that the structure of the document was wrong, so I think it wouldn't have helped. All in all, that's the meaning of risk - something might go wrong, and I have accepted this risk. 

Ah, well, that's the sad part about heuristics (I used "if it was urgent and important, someone would be nagging me" heuristic) - they sometime fail. 

Rant

No Hebrew this time, ranting once is more than enough.

Every now and then, there's a deluge of memes and semi witty remarks on what appears to be testers favorite subject - bugs. Usually, bugs created by the oh-so-incompetent developer.
Well, I have a request for you - If you are about to create, post, retweet, or in any other way share such a hilarious pun - please don't.
Yes, I'm sure that everything is done in good spirits, and it's only a harmless way of venting out.
And yet - Stop.
Besides creating and enforcing a useless barrier between testers and developers (which, I hope everyone posting such stuff is aware of this side effect), this unproportional focus on bugs also portrays testing in the very narrow aspect of bug-hunters. It diminishes every other aspect of testing - exploration, collaboration, risk-analysis, facilitation & acceleration of shipping stuff - and focuses on obvious bugs, probably the single most superficial thing there is to testing.  
So yes, sure, a joke. Sometimes it's even a funny one.  Just remember that humor is one very effective way to convey ideas and make them stick.
So i would appreciate it if you would stop doing that. Thank you.

</rant>

Also, I have a challenge for you - Find some memes about testing that aren't about bugs or bashing developers, and share them the next time you encounter some of those.

Here's one I found: A bit of an internal testing joke, but still.

שני דברים שצריך לדעת Two things you should know

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

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

1. The European Testing Conference has published a call-for collaboration (which other conferences might name "call for papars\participation", and the people at ETC are serious about this difference).
   If you have not done so yet, you should submit your ideas there - It's a wonderful conference, the organizers are amazing, and they are jumping through hoops to make the content submission as easy and accessible as possible.
   Don't want to speak? well, it's time to get a budget (from work or by yourselves) and wait for the early bird registration to open. You want to be there. Trust me on that. 
2. Have you read recently the Wikipedia page on software testing? Did you notice that it could be immensely improved?  Well, Alan Page is doing something about it. Come join the party!

* picture on top was found here.

זה לא צריך לעבודThis shouldn't work

Over a month ago, the closing keynote of NordicTestingDays was given by Kristjan Korjus from Starship Technologies and he told us about their product - a small(ish) delivery robot meant to help with "last mile delivery". The general idea is ingenious - creating a self-driving, fully autonomic delivery bot is an extremely difficult task, but creating a mostly automated delivery bot with some human support when needed is a bit more feasible (still not easy, though).
Well, What happens when one brings such revolutionary idea to a testing conference? Naturally, you get a whole lot of questions challenging the validity of the idea. In fact, most people I've spoken with directly after the keynote did not seem to be convinced that it was a good idea at all.
However, while participating in the European Testing Conference I got to listen to Liz Keogh who, during an amazing Cynefin talk, mentioned that people tend to react to new ideas with four words: "That won't work because...". She also mentioned the value of this reaction in a complicated space and that this is one of the things testers are very well practiced on.
So, back to the the subject - A room full of testers, a new idea. Question after question that can be phrased as a "that won't work because..." statement (with one exception of "how can I become a robot-walker?").
What I liked in Liz's view about "that won't work because" is that it is a valuable to say when creating something since it allows people to consider possible setbacks and prepare for them - to lower the risk of probing (Which is, as far as I understood, Cynefin word for "quick experiment"). That this statement is balanced by the dreamers (traditionally, the dreamers are either in the developer or product manager roles, testers are most of the time hired as professional skeptics) that focus more on "imagine how great it would be if it did work", which is why new ideas are tried out and thus have a chance to succeed (you can't succeed in something you didn't do). Since the experience of TWWB was so strong for me in the room, I want to try an exercise in taking the other view and trying my imagination on the success of the delivery-bots presented at the conference.

So, what are the benefits of having a robotic delivery?

• First is the obvious cost reduction factor, where a robot, over time, costs less money than paying a human, so everything will have the potential of being cheaper as lower costs are embodied in the final price of a product.  
• Second, the risk of violence against the delivery person will be mostly gone (and violence against the robots isn't a major concern since they can call the police, and each one has 9 cameras that will record perpetrators).
• Third, a robot could deliver ice-cream without any de-frosting concerns (why wouldn't a robot be also a miniature freezer, or have heating capabilities to keep the pizza warm?)  
• Next, it will save people the need to interact with a complete stranger just so that they can have some food, or get a package. This will be great for people with social anxiety, but also imagine picking up your pizza delivery without bothering to get dressed - some people will find this appealing. 
• Taking it a step forward - how will it interact with the world? Currently the robot had not yet mastered stairs, will we see smart buildings opening their elevators for it? Will we see hatches in doors for more than just cats? 
• What about sending a package to a friend? I can totally imagine a business that will enable people to send small packages to friends - a small gift you made for your friend and want to surprise them with? The lunchbox your child forgot at home? The book you need to return to the library? Now you can get them to them without having to carry it all by yourself out in the rain. 
• Following your delivery today has probably some legal issues  - is it ok to track a person while they work, especially when they are not working for me? Tracking robots and wouldn't pose the same privacy issue. I could probably track the bot from my phone with no problem. 
• Oh, and finally, I just can't wait to see how well will the robots function with a 4 year old toddler sitting on top of it (after all, Roombas feature as cat-rides).

I could probably go on and try to create a very bright picture of how this world would look like - but I found out something interesting - as I was compiling this list of cool things, my tester habits took on a different angle, and accepting the delivery bots success as a given, I started imagining all sorts of difficulties such a success might present, it's not exactly TWWB, but rather "this idea might be less than great" -

• The current robots drive on the pavement, alongside pedestrians, do we want a lot of those boxes rushing along between our legs? How long will it be until separate lanes would be required? 
• Will there be a new service of "set your robot right after it has fallen (or pushed) on it's side?
• Who is to blame if a robot gets to a bicycle lane (which, in some places, might be also where pedestrians should walk) and a cyclist falls and gets seriously injured? what about an old pedestrian who fell because of such robot and broke a hip? 
• Will branded delivery bots be the target of vandals angry at your company? Will we see accusations of attacking the delivery system of the competing business? 
• With 9 cameras and a human "emergency" operator, will we see a phenomenon of the operators spying on their ex-partners? How common will be instances of accidental spying? And how large will be the operators screenshot collection of people in embarrassing situations?
• Speaking of spying, will the police have access to the footage if the bot witnessed a crime? Alexa was already a target of such request.
• Will a fleet of such robots create a significant load on the phone\internet operators? 
• Such bots are remotely operated - once hacked (and currently, it looks like every other piece of IoT, so it will probably be easy to hack) could it be derailed to the road and used to create Traffic jams and accidents? 
• Will we see "suicide bots"? Just imagine one bot carrying a bomb in the middle of a crowded street. 

Am I saying that the current suggestion of a robot last mile delivery is a bad idea? Not necessarily (ok, I am saying that a bit, but please recall that the same was said about the telephones, cars and personal computers, and I personally don't get how twitter is a thing, so I wouldn't take my word on what has or hasn't a chance) - I have no idea  which of the possible outcomes will actually come to be (tying back to Liz's Cynefin talk, this is an extremely complex space). What I am saying is that as testers, the tendency to see fail points is useful - but during this exercise I found that seeing blockers in our way isn't all that there is to it. If we are to reduce risk by thinking of the bad stuff that might (or might not) happen, there's also some value to guessing what might happen when we succeed. And it doesn't have to be just around innovative ground shaking ideas, thinking back a few years, we had a feature we thought is great, but a week after it was released more than half of our customers called in furious and demanded that we remove it, this is also a possible outcome. Don't let such thoughts stop you from developing  new stuff, but make sure that you prepare for some of the outcomes you can guess.



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

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

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

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

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

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

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

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

I don't find test-cases very useful

Well, Randall Munroe (the XKCD guy) has it right. Someone wrong on the internet is a great motivator. I was flipping through my reading list, when I encountered an article with the oh-so-daring title "You Don’t Have Test Cases, Think Again". Well - The people at PractiTest blog usually write deep thoughtful posts, so there is probably a catch hiding in the post that will lead to an interesting thought trail. Also, reading through my phone, I casually skipped the warning notice at the top of the page and went on reading. As I read through, it became clear to me that I completely disagree with the content there. Hence - this post here.

Probably the easiest thing would be to be the friendly neighborhood bully and pick up on some of the many mistakes there are in the post that indicates that the author either has no understanding of what exploratory tests are, or  he is using a very private and skewed definition of ET (some candidates are the claim that there is no test planning in ET, the axiom "good tests have well defined and agreed upon pass criteria in advance" or my favorite: "[...]some Exploratory gurus assiduously disdain requirements; so they’re very unlikely to get involved with intermediate development deliverables prior to executable code"), but I prefer to avoid public ranting and patronizing people I don't know, so instead, I'd rather say why I don't think in terms of test cases and why I usually avoid this language.

I'll start with the obvious truth - some of what I do can be described in test-cases language. While I'm "testing" (or "exploring", if you prefer this term) I'm doing a lot of checking that can be translated to test-cases language, as can some of my more vague observations (e.g. "this doesn't look comfortable") could sometimes be translated to a test case without stretching it (in fact, once a problem is spotted, defining a test case around it is usually easy). So, yes - if someone insists, I am "executing test-cases" and I'm doing it wrong in as many ways as shorthand writing is doing calligraphy wrong.
And that's, in short, is the reason I try to avoid using the language of "test cases" - It comes with a lot's of baggage. When I say "test case" I'm also saying "heavy predefined documents" and "step-by-step instructions", which is not what I'm trying to convey. When I talk about my testing, I focus on getting my team to agree on what we should test, on what risks do we want to address and I rely on my skills. During my work I will use checklists, I will review any source of information I have (and get those I need) and have my team review both my intentions and my work. Heck, we've recently spent a full week reformatting data into excel sheet just so that we could deal with an unusually large testing problem. And yet - I don't say "test cases".

Another matter I want to address is the odd dichotomy created between "exploratory testing" and writing a test case. When you think about it closely, it is pretty much the same thing. When I spent some time writing down very detailed test cases, I could never do it without actually having the software and performing it at the same time, and I have yet to meet a tester who wrote a test plan without "winging it". Sure, some of us improvise magnificently using all sorts of techniques  - from equivalence partitioning to combinatorial testing to personas and use cases - but all of that charade is simply masking the fact that we apply our experience, skills and gut feelings to choosing the data and the techniques that will be applied (no, I'm not saying those techniques are a sophisticated fraud, they are valuable, very much so sometimes, but the skilled tester will know when to apply each technique or tool and when not to).
I want to ask you to think of the following question: what would be the result of exploratory testing a requirements document?
...
...
...
...
Done thinking? have your answer? Great. Unless, of course, your answer was "exploratory testing must have a working product to act upon", which is simply wrong. But in any other case, great.
My answer is - test plan. When I test a requirements document (for those who use the ISTQB vocabulary, please recall that a review is a form of a static test), I come up with a model of how the software is supposed to function, with questions pointing at gaps in this model, or inconsistencies in the requirements, I compose a list of risks that we might want to put some safeguards against (some of them may be "test this area once it's done and look for that sort of glitches") and I add my knowledge and experience back to the team. I was definitely testing, and since I was learning about the product during this activity, I would say it falls under the definition of "exploratory" part as well (Also, if we avoid quoting anonymous "gurus" and stick with quotes we can trace, I tend to agree with Bach & Bolton's definition, according to which all testing is exploratory).
So, if we accept that writing a test plan is, in fact, an act of exploratory testing, why do we claim that executing the results is any different? And why do we insist on separating test execution from test planning? Sure, there are cases where we might want to plan more beforehand - to make sure we don't forget or to fight off some of the bias that we might have after testing the same thing for a while, but there are other cases where we might not want to do so. Relying on skilled testing allows us that freedom of doing what we think is right for our project. Which leads us back to why I don't like using the term "test case" - it just draws the focus from what's important.


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

מה יש לומר רנדל מונרו (ההוא מXKCD) ידע על מה הוא מדבר. יש מעט מאוד דברים שגורמים למוטיבציה כמו לראות מישהו טועה באינטרנט. הפעם, רפרפתי דרך רשימת הקריאה שלי כשהגעתי לבלוג של פרקטיטסט ושם היה המאמר עם הכותרת ההו-כה-מבריקה "You Don’t Have Test Cases, Think Again". נו, מילא. בדרך כלל אני מוצא שם פוסטים מרתקים, אז אולי יש פה ניסיון לתפוס את תשומת הלב כדי לגרום לי לחשוב. כמובן, כיוון שקראתי דרך הפלאפון, דילגתי בקלילות מעל האזהרה שהייתה כתובה באותיות של קידוש לבנה בראש העמוד והמשכתי לקרוא - מצפה לרעיון מעניין. ובכן, מהר מאוד הבנתי שמעניין זה לא יהיה, כי כל המאמר מבוסס על חוסר הבנה משווע של (הדרך בה אני חושב שצריך להבין) בדיקות חוקרות, ואפילו של בדיקות בכלל. ולכן (ובדחיפה קטנה מצד יואל) - הפוסט הזה. 

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

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

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

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

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

אני רוצה להציג את השאלה הבאה: כיצד יראו התוצאות של בדיקות חוקרות של מסמך דרישות?

קחו רגע לחשוב על זה. 

...

...

...

...

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

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

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

Nordic testing days - closing it all up

So, second day of NTD 2017... The scary part where I get to speak. At least, it was directly after the keynote, so I would have most of my day worry-free. 

Fiona Charles's keynote raised an important matter - As testers we should be responsible for our ethics - both towards the company that hires us, but more importantly, to the public that our product affect, and to ourselves. In a perfect world, everyone would be doing the right thing, so there will be no ethical dilemmas. Sadly, our world is not perfect, and we are asked to lie, or help in covering up information, or take part in a product that we think is morally inappropriate (my personal "no way I'll work there" include gambling sites, porn and most ad-services). In such cases, we have to know when to say "no". "No" to lying. "No" to deception. Also, it is very important to know that there are levels of saying that no. Most of the times, this no should be voiced internally - Letting the product owner know that the tests indicate a very high risk in releasing the software, asking again if we are comfortable with *this* business decision, going over your manager's head to make sure your concerns are not ignored irresponsibly, even resigning when you think the company is acting immorally (but not illegally) . Sometimes, when there's something more serious is on the line, it means that we should notify external entities - turn the external auditor's attention to the flaw that might cause a safety-critical component to malfunction, anonymously tipping the police when acts of fraud are being sanctioned by the CEO,  or even going to the media to reveal how irresponsibly the company is handling their user data despite all warnings and attempts to fix this. 

My main takeaway from this talk is that it's always easy to know what is the right thing for others to do. Especially in retrospect. Knowing the right thing to do yourself, and having the courage to do so - is not always that simple. Let's hope we won't face such dilemmas ourselves. 

Then, after the break, there was my talk. Was I nervous? yes. I think it went well, and some of the questions I got at the end indicated that my message had indeed reached at least some of the audience (my message, in short - threat modeling is very much like testing, so go and do that. 

After that, I could enjoy the rest of the conference worry-free, and went on to listen to some very good talks (such as Carly Dyson's talk on her insights from being a consultant, Melissa Marshall's thoughts about integration tests or Gwen Diagram's talk on logging and monitoring). 

Finally, was the closing keynote. Usually, I really like the keynotes - where you get great speakers with ideas that are inspiring and thought provoking. This one, sadly, was neither. The speaker, Kristjan Korjus, showed us a really interesting product - a robot that is meant to facilitate "last mile delivery" and make delivery a lot less expensive. It is, to borrow the Cynefin terminology, a very complex situation, and thus probably the most interesting situation, when the way forward is by probing fast and learning in retrospect, so I'm assuming that any of the directions there could have made out a great keynote that will give people something to take home except "oh, look, a cute robot". Instead, we got something that looked a lot like a sales pitch, and I'm not even sure who is supposed to buy what. 

Anyway, after the keynote and thanking the amazing conference team for their magnificent work we've moved to a nice bar for the after-party, where we got to say goodbye to those flying soon after the conference ends, and chat a bit more over dinner with those that were staying another night.

Yes, naturally we met a bit more with people at a(nother) pub for some more chats and fun. 

The last day where I could say it was still a bit conference-y was when we met the next morning for breakfast and final goodbyes. I then went with Sven for a day-trip in the countryside (where I took the picture you can see above). A really nice way to take a slow cooldown from a conference. 

So, all in all - it was a great conference. A lot to consider, great experiences and even greater people. If you are making a list of conferences you want to attend, this one should be very high on your list. 

Nordic testing days - day 1

So, the tutorials day is over, and the first day of talks began.
For starters, it was a lot more crowded. With ~500 attendees, it's the largest testing conference I attended, and the atmosphere is absolutely electrifying. A lot of things to learn and experience, and a whole lot of new people to meet.
With so much going on, I could probably babble about the experiences I had for quite a while, but instead I want to pinpoint some of the highlights of the day.
First to be mentioned is Franziska Sauerwein's workshop on refactoring JUnit tests. I'm quite comfortable with Java, so I came with the expectation of learning new coding habits by watching other people's (in this case - Franzi's) way of coding. And indeed, that is mostly what I got. The workshop went pretty well, at least as far as I can determine, and I got out with several pointers on how to improve some of the code I am writing (also, need to check Hamcrest, with which I was not familiar before). A workshop that makes a very clear promise, and then delivers it exactly.
Similarly, Kevin Harris's talk about losing third of the testers and surviving that. When a crisis happens, you must adapt, and Kevin shared with us some of the extreme measures they had to take to cope with this change. Some of them, probably, are better off when done with the luxury of time at hand - and even if they don't, they sure seem like the right thing to do (others, on the other hand, are crisis-only action, so I hope not to ever need them, but I'm stacking them in memory just in case).
The final keynote of the day was given by Alan Richardson, and was all about taking control of the way each of us treats testing. It was not a new message, but it sure was very inspiring and super important for new testers, while remaining not less important reminder to the rest.
And so, the day was concluded.
Or was it?
A conference dinner shortly followed, and then some sort of a party - with disco-lights and drummers. I took the chance to get some 20 minutes of quiet time before returning for the lightning talks and the Powerpoint karaoke - both of were real fun. I especially liked Gwen Diagram's lightning talk which was a very fast-paced,foul-mouthed ode to rapid development named "me and Mr. T".

A long day, and quite a fun one at that. Now, for the final day of the conference, where I'll be presenting my talk.
How did the Romans say? Ave, Imperator, morituri te salutant.

Nordic testing days - tutorials day

Today was the tutorials day at NTD, and what a lovely start for a conference it was.
Choosing a tutorial was really difficult (so I'm glad I've done that part when registering) - with the exception of "java for testers" that claims to cover stuff I already know, I simply couldn't tell which one I prefer going to. By the end, I chose Fiona Charles's workshop on heuristics. It started out really well, with a short overview of what heuristics are - and I do prefer her way of looking at it as "shortcuts" instead of the overly wide "fallible methods of solving a problem", since it narrows the field at least a bit. My main difficulty with "heuristics" is that it can be used to describe just about anything people do, and using "shortcuts" narrows the field of discussion to useful heuristics and enables some sort of a meaningful discussion about it.
Before lunch, we played some children games, and tasked with the goal of finding some heuristics to solve the puzzles and track our heuristics as they changed over the exercise. What really got me was that none of the initial heuristics we tried to apply first held true, and soon after starting to actually solve the puzzle. Doing something only because it seemed to make sense in the past is not necessarily a good idea. The cool thing in this, though, is that heuristics that are not helpful were als really hard to follow for a longer period of time.
The second part of the workshop started by watching this video and being asked "what heuristics would be useful for testing this, if all the information that you have is this video?" Well, that was tougher than I thought it should be. Armed with the (tacit) knowledge that coming up with heuristics before actually doing some of the work would not necessarily be productive, we got to the task of coming up with test ideas and filling the information gaps we had with assumptions. After doing that for a while, we've tried grouping the test ideas to similar categories in hope of distilling it to a point where it would be easier to notice some of the heuristics we were using - that didn't go as well as I thought it would, since we found ourselves looking at a checklist (which is a great heuristic by itself), and not really knowing what was leading us. In the latest 3 minutes or so of the exercise something clicked and we were able to detach ourselves enough from test-idea generation, and look at how we were doing that. Our main heuristic to generate ideas was using scenarios (or use-cases, if you would prefer), which had a lot to with personas (the phrase "redneck with a crowbar" did come up once or twice). I could totally see how naming those heuristics could help me get a better coverage given some more time, but as it usually is in workshops - time is of the essence.

The day ended with speaker's dinner, which started in the cute train you can see at the top. quite a nice way to get to where we wanted - it started with a toast on some sort of a balcony, overseeing the beautiful Tallinn, followed by a medieval-themed dinner (in a dark, candle-lit restaurant), after which we were dragged to a bar to try out something called millimalikas (or something of the sort, I heard it means "jellyfish" is Estonian, but did not verify that), which is two sorts of alcohol, one of which is anise-based (read: really disgusting) and some tabasco to make it painful. Thankfully, the tabasco  burn did eradicate the anise after-taste, but it is definitely not something I would repeat.
All in all, a packed day, which was a prequel to an even more packed conference.

שמות עתיקים ומעלי עובשnames that get old and stale

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

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

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

השבוע יצא לי להתמודד עם סוג נוסף, קצת יותר זדוני, של שם משתנה שהזדקן רע. 

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

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

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

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

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

One of the first things that are being taught at every introductory programming course is "choose meaningful names for your variables". Those names make your code more readable, and save hours of work. 

A small point that don't get mentioned enough, is that names deteriorate. Sometimes, the domain language we speak is changing and old terms become meaningless, sometimes, it a matter of duplication - After all, what's more sensible than naming the permission to deactivate the main flow of our product as "PERM_DEACTIVATE" ? and, if we have another feature enabling full deactivation, why not name it PERM_FULL_DEACTIVATION? Three years later, you'll find yourselves asking each time "when you say 'deactivate', which of the two do you mean?". 

This week I got to deal with another, nastier form of term deterioration. 

In our systems there are users. As can be expected, where there are users, there are also admins that can manage those users. One of them is called "admin-all". Originally (we believe) it was meant to create all kinds of users in our system. As sometimes happens in developing systems - more roles were added at a later phase, and no one updated the admin-all permissions (it might even be that it was intentional and not a matter of negligence). Eight years later (at least), a crisis happens! Customers are furious! managers are gathering over phone to discuss! Chaos is reigning!

I won't bother you with the exact details of the problem, I'll only mention that we needed to provide someone with an admin that can create all other users. "Well, easy", I said. "Just give them an 'admin-all'". All the other people in the conversation, all of whom have more years of experience with the product than my mere 5 years, voiced their agreement. Yep, that's the user we need. Each and every one of us have encountered at least once in the past the gap between the claim "admin all" and the actual privileges, so when a short check we did showed that some privileges are missing, all of us had this "oh, right, I forgot" moment. 

I don't really have deep insights from this story, except, perhaps - make sure to maintain the names you choose, and update them if you have reason to. It saves confusion and mistakes later.