הרקדן האוטומטיThe automated dancer

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

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

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

(For the non-Hebrew speakers in the audience, The title refers to a song from the 70's that somehow was not forgotten in the mists of time)

So far, the few posts I had written were triggered by an actual experience I had and got me thinking about something, or helped me understand an interesting point. This time, however, my main argument is that someone is wrong on the internet. This time, I have encountered the question (roughly translated) : "How can I become an automation tester". This question annoys me in several manners altogether.

Probably the first thing that annoys me is that I encounter this question a lot. It's almost always "how can I advance to automation?", "How can I acquire automation skills?". It is almost never "How can I become a better functional tester?", better in embedded systems testing, in user experience testing etc. One exception for this is performance testing (another might be security testing, but I'm leaving this out, since most security testers I've encountered defined themselves as "security consultants"), which I see frequently enough. The reason for that, sadly, is obvious - employers are paying more for those type of testing. For automation, since they are used to pay programmers higher salaries, and for performance testing, since it actually seems like something that requires expertise (and testing isn't being perceived  in such a way usually. I understand it, but this understanding annoys me even more.
Another reason that annoys me is that this question is usually "how can I move advance my career to automation?" and while this is an advancement in terms of pay and, sadly, also prestige, so does being a successful lawyer. The issue is that unlike other fields of expertise in testing, there isn't really a path that can lead someone from being a "manual tester" to being hired as tester that writes automation. For instance, I can catch up on security testing by involving myself in the security related features in my product, practicing a bit, reading a bit and being useful most of the time, I can't really learn how to program properly without investing a lot of effort in it, on my spare time. Not that it can't be done - it can, and does - but rather that the amount of effort is not that far from learning a new profession. The bar for starting to contribute is simply too high for one to contribute while learning.
A third reason, which is a bit petty, is that unlike advancing from junior to senior tester, there is nothing in "advancing" from tester to automation writer that means that one is a better tester. A performance tester is better in testing the narrow field of performance (narrow only in comparison to the entire field of testing that is, performance testing can be an astoundingly wide field), but a tester that can write automation is by no means better at testing anything. Programming is a skill that can assist greatly in testing, but so can SQL, or strong domain knowledge - possessing any of these skills doesn't make one a better tester.

But, finally, the main reason I find "automation tester" to be annoying is that using this term is setting a wrong connection between programming skills and testing. IMHO, there isn't, and shouldn't be, anything like "automation tester". Writing code is a skill that can help a software tester, and I will even say I consider it to be an important skill for a tester, but possessing this skill isn't something that justifies creating a new category of testers. I have yet to hear anyone refers to themselves as "SQL tester", even though some testers don't know SQL and don't use it in their work - this skill is too common to define a category. In a similar manner, some understanding in code (or, "in a scripting language", like some recruiters who wish to  pay less than a programmers wage like to phrase it) is so common today as is the requirement to participate in writing some automated checks, that the line between a tester that writes automation to one that doesn't is getting really blurry.  And, if that isn't enough, there are some very strong tools out there (such as SoapUI, or selenium IDE which is a less than perfect example) that provide just about everyone with some amount of automation capabilities.

So, next time you hear anyone referring to an "automation tester", take a squeaky hammer and smack them on the head.