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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

Comic relief

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

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

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

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

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

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

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

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

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

Online lean coffee

(An event report, so no Hebrew)

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

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

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

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

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