Monday, September 18, 2017

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?

Sunday, August 27, 2017

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 בקנדה) ושוב - זה היה שווה כל רגע. 

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

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

Wednesday, August 23, 2017

סוסי בעד תיעוד!

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. 

Friday, August 11, 2017

תזכורת על חשיבות התזמון

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. 

Tuesday, August 1, 2017


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.


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.

Monday, July 24, 2017

שני דברים שצריך לדעת

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.

Sunday, July 23, 2017

זה לא צריך לעבוד

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