אחרי שהשוויתי בין כתיבת בדיקות לרכיבה על אופניים, השתעשעתי עוד קצת עם הרעיון, ועצרתי לחשוב עוד קצת על כלים שנועדו לספק לבודקים שאינם מתכנתים יכולות כלשהן בייצור בדיקות אוטומטיות, והאנלוגיה שהתקבעה לי בראש היא אופניים חשמליים.
אופניים חשמליים הם רעיון נהדר - כלי תחבורה זול,נייד וקל שאינו מזהם מאוד את הסביבה, לא דורש רישיון נהיגה, לא סובל מפקקים ובזכות המנוע החשמלי, לא באמת חייבים למצוא מקלחת במקום היעד. אבל הרעיון הנהדר הזה נשאר על הנייר בלבד. בפועל אופניים חשמליים מטילים אימה על הולכי הרגל על המדרכות, ורוכבים רבים שוברים גפיים, או גרוע מכך. לא בדקתי את הנתונים בצורה מעמיקה, אבל המספרים בהם נתקלתי מדברים על שני פצועים ביום בממוצע (נדמה לי שבשנת 2014) שהיו מעורבים בתאונות אופניים חשמליים - הן רוכבים והן הולכי רגל. ובכנות? לא משנה עד כמה גבוהים יהיו המספרים בהם אתקל - ככל הנראה אהיה מוכן להאמין להם, כי כמעט לא עובר יום בו אני לא רואה רוכב אופניים חשמליים שמתנהג בצורה לא בטוחה.
יש מגוון רחב של סיבות להתנהגות הפרועה של רוכבי אופניים חשמליים, אבל המשמעותית ביותר לדעתי (ושוב, לא בדקתי את העניין בצורה מסודרת) היא העובדה שיש לאופניים האלה יותר מדי כוח. רוכב אופניים רגילים שינסה לשלוח מסרון תוך כדי רכיבה ימצא את עצמו בתוך חמש שניות על הרצפה. על אופניים חשמליים - לא בהכרח. רגלי הרוכבים על אופניים חשמליים מונחות על הדוושות, כי אחרת האופניים לא יזוזו. באופניים חשמלים כבר ראיתי רוכבים שמניחים רגל אחת על הרמה, ורוכבת אחת שהגדילה לעשות וישבה כששתי הרגליים שלה מקופלות על הרמה במה שנראה כמעט כמו ישיבה מזרחית, עם יד אחת על הכידון, כי השנייה החזיקה פלאפון. ובדרך כלל - למרות מרכז הכובד הגבוה יותר, למרות חוסר תשומת הלב הכללית, הרוכבים הפרועים האלה לא נופלים. עד שפעם אחת הם כן. או שהם לא שמים לב ודורסים מישהו.
מוצרי מדף שנמכרים תחת "פתרון האוטומציה שהחברה שלך צריכה" או "אוטומציה בכמה שלבים פשוטים" הגיעו למצב בו אפשר להשוות אותם לאופניים חשמליים. כשאני הגעתי לעבודה, היינו בשלבים מתקדמים של היפטרות מכלי בשם Badboy - כלי הקלטה ושידור של דפדפן, שמשתמש בדפדפן משל עצמו. וגם נראה די מכוער. עבודה עם כלי כזה לא תבלבל אף אחד - אנחנו צריכים אוטומציה שעובדת טוב יותר, ואולי הגיע הזמן לשכור מישהו עם הכישורים המתאימים. לא שהכלי רע במיוחד, אבל הוא לא עוזר עם כיסוי דפדפנים (כי הוא דפדפן משל עצמו) והממשק המכוער פשוט לא נוח במיוחד לתפעול.
מצד שני - אם נשווה את המוצר הזה למוצר של Testim.io, שני המוצרים עושים את אותו הדבר, אבל טסטים נראה יפה, רץ על כרום ומספק כל מיני שירותים מגניבים כמו הקלטה של כל הבדיקות שרצו. כשעובדים עם כלי כזה - לא כל כך קל לשים לב שהבדיקות שאנחנו מייצרים מוגבלות באופיין. ואם אנחנו עוברים מבדיקות דפדפנים לתחום אחר, כמו למשל בקשות SOAP, המצב הולך ומשתפר: כלים כמו Ready!API מספקים די כוח כדי לענות על צורכי הבדיקות של כל מיני מוצרים באופן טוב מאוד - מקליטים כמה בקשות, או אפילו רק מספקים לכלי WSDL ומקבלים ממשק נוח מאוד לבדיקות פונקציונליות (שבניגוד לכלי ההקלטה שמזיזים דפדפנים, מכילות גם הפנייה לבדיקות מסדי נתונים בצורה מובנה), בדיקות עומסים, לפחות בקטנה, ובדיקות אבטחה בקליק אחד. ואם כל זה עדיין לא שכנע אתכם, החבילה כוללת גם שירות סימולציה שמאפשר לקבוע את התשובות שיוחזרו לבקשות השונות. בקיצור - אם אתם משתמשים בכלי הזה, לא חסר לכם הרבה.
וזה דבר טוב, נכון? אנחנו יכולים להפסיק להתעסק בכל הדברים הטכניים שחוסמים אותנו ולהתמקד בבדיקות. וכבר לא צריך לדעת לתכנת כדי ליצור אוטומציה שימושית. הטוב שבכל העולמות!
ובכן - לא.
הכלים האלה, בסופו של יום, מוגבלים. אולי מדובר במשהו שפשוט נמצא מחוץ לגבולות הגזרה של הכלי (Ready! API לא מיועד לאוטומציה של דפדפנים, למשל, וטסטים לא מתעסק בשום דבר מחוץ לדפדפן), או שסתם מדובר בנושא שהכלי לא טוב בו במיוחד. אבל עם הכלים הנוצצים והחזקים שיש היום בשוק - קשה יותר לבנות טיעון נגד הסתמכות על הכלי, וחברות רבות עשויות להסתפק בבדיקות סוג ב', כי למה להתחיל ולבנות פרוייקט תכנותי מורכב שצריך לתחזק מרמת התשתיות ומעלה, כשכל מה שצריך לעשות הוא להריץ את הכלי הנפלא שקנינו - ובדרך כלל אפשר גם להריץ אותו משורת הפקודה? וזה שצריך להגדיר את הכלי בנפרד משאר המוצר? בסדר, פעם ב... יגיע אחד הבודקים ויסדר את התרחישים המורצים, או ישנה את הפרמטרים שנשלחים אליהם. אז זה קצת מציק. אז מה? בשביל זה לשלם לבודק שיודע לתכנת?
חוץ מזה - כאשר משתמשים בכלי כולל שכזה, לא באמת יודעים מה קורה מתחת למכסה המנוע. ואז, אם פתאום משהו לא עובד - אין לאף אחד את היכולת לחטט פנימה ולתקן את הבעיה, כך שצריך להסתמך על התמיכה של מי שמייצר את הכלי.
וכמו באופניים חשמליים - מדי פעם נופלים. לפעמים קורה מקרה ומגלים שהכלי כבר לא מספק את צרכי הארגון - כי הארגון השתנה, או שצורכי הבדיקות גדלו. במקרה כזה, המחיר המושקע בכלי עלול להיות גבוה מאוד - ועלות המעבר גבוהה אפילו יותר.
ונקודת דמיון אחרונה ששמתי לב אליה תוך כדי כתיבה - רוכבי אופניים רגילים נוטים להסתכל על רוכבי האופניים החשמליים בבוז מסויים, או אולי מדוייק יותר לומר - בהתנשאות. זה לא משנה שהם עצמם יכולים לתאר כמה וכמה מקרים בהם אופניים חשמליים הם הבחירה הנכונה (למשל - "אין לי מקלחת בעבודה"), תחושת ההתנשאות עדיין קיימת.
הדבר דומה לגבי כתיבת אוטומציה ללא תכנות - למרות שאני, כבודק שמתכנת, יכול לתאר כמה תרחישים בהם הבחירה הנכונה היא להשתמש בכלי מוכן מראש, עדיין, אני מרגיש את אותו דחף מתנשא כשאני שומע על מישהו שמבסס את הבדיקות האוטומטיות שלו על כלי שכזה.
-----------------------------------------------------------------------
ובכן - לא.
הכלים האלה, בסופו של יום, מוגבלים. אולי מדובר במשהו שפשוט נמצא מחוץ לגבולות הגזרה של הכלי (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.
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.
No comments:
Post a Comment