מותו של הבודק הידני Abolishing manual testers

 https://s-media-cache-ak0.pinimg.com/736x/94/6c/c7/946cc7383075dc6f3e645a5e27b0d794.jpg

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

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

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

At the last testing meetup I raised a subject that bugs me for some time now - it's time to stop using this nonsensical term "manual tester". It's a dinosaur that should have long been extinct. No, I'm not trying to say that all testers should learn programming (I think programming is a very useful skill to have for a tester and would recommend any tester to have it in their toolbox, but this is not the subject here), nor do I want to discuss the question "will testing be assimilated into the developers' role?". My issue is with this specific term. 

Of course, I'm not the first to write something on the subject and probably not the last, but there's something I want to add: "Manual tester" is a term that should be eradicated from everyone's vocabulary, and software testers should be the first to do so. 

The only piece of information one gets from this term is "I don't write code". There are a lot of skills that testers use all the time - Analysing systems and creating models, assessing risks, using SQL, testing security, performance, UX & accessibility. Testers also use tools that require skill & learning, and it doesn't matter if it's a test tool tailored for a specific hardware or if it's the browser's developer tools. In addition, there are a lot of areas in which a software tester can specialize: A UX testing expert isn't far fetched, right? Neither is localization testing specialist, and we've all met some security and performance testing experts. But what would it mean to be a "manual testing expert"? does this even say anything? 

"Manual tester", the way it is used in today's market, is a term used to describe what a tester does not do. It is both derogatory (would you call a chef who specializes in the Italian cuisine "the chef that does not make sushi"? ) and confining. It is confining since the job description states quite clearly what one is not expected to do. If a person wakes up one morning and decides to learn some coding and apply it in work since it's the reasonable thing to do in a given situation, the reaction of the environment would range between "I thought you are a manual tester" to "are you trying to switch\advance your career path to automation?" If, however, we would have used a more constructive term (such as exploratory tester, functional tester or even simply tester), writing code would not be something marked as out-of-scope but rather what it actually is - one way we can choose to get things done. 

And, if in the process we'll manage to turn the spotlight to the fact that there are some technical skills in testing that are not related to coding skills, it can be nice too. Who knows, maybe we'll manage to remove the almost-as-bad term "technical tester" as well.