Blog

(Once again, I’ll start in English, as this is a response to something originating by a non-hebrew speaking writer. Specifically, a short discussion in the comments to this post)

Up until now, I had twice commented on James Bach’s blog, and in both cases I had a short but very interesting discussion.or at least, interesting for me.
Putting aside the admirable amount of time and effort he invests in reviewing comments and responding to them quickly, I really like his care for using terms in a precise manner and trying to define them so they will be useful. One of the most important things I have learned in my university was that words are a thinking tool. Without having the proper word for something, it is harder to think about it, or even to see it. This way, when Roman Jakobson defined his six “functions of language” he has enabled a refined discussion about the interactions of these functions (for instance – can a “speech instance” have more than one functions? can it be phatic and referential at the same time? What would be a pure manifestation of the poetic function? A whole new set of questions that can now be discussed concisely and with everyone knowing more or less what everybody else are talking about.
Following the discussion I found two terms that I don’t really like, one should be used is a slightly different meaning then the one used By Bach, and the other should just be abolished and never heard again.
The first is the term “Toolsmith”. The second is “Technical tester”.
The notion that some testers are good at creating tools is a really important one, since it gives visibility to yet one other type of activity done by a tester. However, when talking about a toolsmith, something sounds to me a bit off-key. When I hear the word “toolsmith” my understanding is that this is someone whose profession is to create tools. And you know what? Even though I spend some of my time writing code, creating tools is not my profession. Let’s take an example from the movies, where we have two examples of people who make swords. The first one is Hatori Hanzo from kill bill, a master swordsmith with legendary skills, the other is Connor Macloed, the expert swordsmith who forges his sword (In the 3rd highlander movie). What was that? Connor Macloed isn’t a smith?But he creates a sword! He’s really knows stuff about sword making! At best, he’s a warrior who knows quite a bit of swordsmithing, and this is where I have a problem with “toolsmith”. Sure, as a tester who can code, I write tools that will help me – a script to do automatically and quickly what would otherwise take me a day of work, some automated regression checks, improvements to my test framework – you name it. But, even when I do all of that, I do it to improve my testing, since I’m a tester.
A toolsmith, on the other hand, is not a tester. A person whose main goal at work is to create tools is not a tester, even if these are test tools, even if this person does also some testing now and then.
During the discussion I used the term “artisan” as a replacement to toolsmith, and while I think it’s slightly better due to specialized manner attached to this term, in retrospect I think it suffers from the same problem of focusing on the product instead of the end goal. If someone feels they are benefiting from being called a toolsmith – let them have it, me? I’m sticking with tester.

The second term, on the other hand, is outright damaging. Calling coding testers “technical testers” implies that non-coding testers are not technical, and apart from being insulting to testers that don’t code, it is both incorrect and creating harmful misconceptions. Let’s start with why is this incorrect:
First, while we are used to think of coders as “technical people”, the two terms are not the same, and there can be someone who’s technical despite not knowing how to code. Business analysts should be technical even if they can’t code, since they will be those transforming the business requirements to technical requirements (I’m using business analysts, but I’ve heard this task being done by a wide array of roles – from product managers to architects), and if the business analysts are technical, what about the testers reviewing their work? or checking the design against their requirements? aren’t they technical as well?
Second – investigating bugs requires technical skills. Sure, not all bugs require deep investigation, but providing useful information in a bug report often requires digging into logs, minimizing a “how to reproduce” scenario, DB checks – all of these are technical skills.
Third – When retesting a fix, only poor testers would repeat the same scenario mindlessly and be done with it. Better testers understand the nature of the fix and do a quick analysis of what could if affect. Again – technical skills.

I can go on with this list of “things testers are doing and are technical” for at least a couple more points (translating between developers and business people and ask good questions at design meetings and to that you can add security testing and code-reviews as well), but I think you see where I’m going.

Now, to the damage part –
I claim that this damages the following areas:
– Reputation of the testing profession.
– Non-coding testers ability to perform their job.
– Basic skill-set and development of testers.
– Inappropriate compensation to non-coding testers.

The first point is clear to me, but I’ll try to explain it nevertheless: Testers work closely with developers. Most developers I know tend to appreciate “being technical” above many other traits when judging someone professionally. Why? Because they have a hard time talking with the non technical folks about what they do. When testers are by default “non-technical” (because all technical testers code), they will value less the non-coding testers, even without meaning it.
This, in turn, leads to the next point – Please raise a hand if someone ever told you “Don’t busy your pretty head with this” (or anything similar). I had this response several times (not from my developers), and it’s annoying as hell, and it hinders the tester ability to do their work. How can a tester perform better, when presented with “I’ve added an LRU cache”, or “I tweaked the infrastructure a bit and stuff should now work faster”? Sure, you can always ask for more details, but the person that can give it to you won’t do that if they are under the impression you won’t understand it.
Now, for the basic skill set and improvement path – I have no idea how is it in other places, but around me, there’s an assumption that anyone can do a non-technical job. Sure, not all of us are great at sales, but I can sure try and get a job at sales without having to prove anything – I might need experience for the high-level positions, but for entry level I need mainly to try. The same applies to testing – when someone asks “I want to get into high-tech, but don’t want \ can’t invest in learning, what should I try?” Probably the first answer will be “You can try QA”. Meaning – we get a lot of skill-less people trying to get in the profession, and with some of them being persistent enough – they find their way in.
Next thing you know – you have a bunch of under-skilled  testers. But they will get better, won’t they? No, they will probably not. The same culture that has let them in, is letting them stay without developing their skills very much. The lack of widespread concepts to improve in is not creating enough pressure on them to invest much effort. So they stay dormant. If testing was considered a technical skill, it would help because people believe technical skills easy to measure and important to advance in. By blocking the way for unskilled juniors, the paradigm will change to push people to hone the skills differentiating them from all those that were left out.
And the last point is, again, obvious.
As a coding tester, my salary is comparable with developers that have the same level of experience. My initial salary was close to double of non-coding junior testers’ salary, and higher than that of some test managers. The value I brought to the company in my first year wasn’t anywhere near that of my colleagues that can’t code, but when one of them got fired due to personal issues, we couldn’t replace him since we were not hiring non-coders any more, and his salary wasn’t comparable to what was needed.

Sure, all of that isn’t only because testers are considered non-technical, and there are sure some not good enough testers out there that justify being called “non-technical”, but I believe testing is a technical profession (based on the skills required to perform tasks well), or at least, an “also technical” profession. And I also believe that the impression that it is not is contributing to the ill effects I mentioned above.
Oh, and while we’re at it – stop using “manual testers” as well, it’s almost as bad as non-technical, and it’s defining a tester by the one skill they don’t posses.

—————————————————–

עד כה היו פעמיים בהן יצא לי להגיב בבלוג של ג’יימס באך ובשני המקרים היה לי דיון קצר אך מעניין איתו. או לפחות, מעניין מבחינתי. 
גם אם נניח בצד את ההערכה שיש לי לזמן שהוא מקדיש למעבר על כל תגובה שמתפרסמת אצלו ולמענה מיידי, אני די מחבב את הדרך בה הוא מקפיד לנסות ולהגדיר היטב כל מונח בו הוא משתמש ולעשות זאת כך שהמונח יהיה גם יעיל ולא רק מדוייק. 
הסיבה בגללה אני מחבב את הגישה הזו, שרבים עשויים לראות בה טרחנית, היא שבאוניברסיטה למדתי שמושגים הם כלי מחשבה. בלי שיש לנו את המילה המתאימה להגדרת תופעה כלשהי, יהיה לנו קשה יותר לחשוב עליה, ולפעמים יהיה קשה אפילו לראות אותה. לדוגמה, כאשר רומן יאקובסון הגדיר במאמרו “בלשנות ופואטיקה” את שש הפונקציות הלשוניות הוא אפשר קיום דיון מורכב על הפונקציות האלה והאינטראקציה ביניהן (למשל – האם מופע-דיבור יכול לכלול יותר מפונקציה אחת? האם דיבור יכול להיות פאטי ורפרציאלי בעת ובעונה אחת, או שהשניים סותרים? כיצד נראה ביטוי טהור של הפונקציה הפואטית?) בעזרת מתן שם לתופעה, ניתן לקיים דיון אפקטיבי ותמציתי כשכל האנשים מסכימים פחות או יותר על מה מדובר. 
בעקבות הדיון בפוסט הזה (הדיון נעצר ברגע בו מנגנון התגובות בבלוג לא אפשר להגיב לשרשור הרלוונטי) שמתי לב לשני מונחים שאני לא מחבב במיוחד, האחד צריך לשנות טיפה את הכיוון, ואילו את השני צריך להכחיד. 
המונח הראשון הוא מונח שתפס בסביבה הרעיונית של באך ושל קהילת הבודקים מוכווני ההקשר (Context Driven), וזו הנטייה לכנות את מי שכותב קוד למטרת בדיקות  “חרש כלים” (Toolsmith), בגדול, הם נעזרים במונח הזה כדי לציין את אחד הכיוונים בהם בודק תוכנה יכול להתמחות והוא לגיטימי לא פחות – אבל גם לא יותר – מאשר כל תחום התמחות אחר בבדיקות תוכנה (בניגוד למה שניתן לראות במקומות בהם מחלקים בודקים ל”ידניים” ו”אוטומטיים”, ועל כך כבר הערתי כאן). אבל, יש לי בעיה עם חרש-כלים. בפרט, כשאני שומע את המונח הזה, אני מבין אותו כתיאור המקצוע של מישהו שתפקידו הוא לייצר כלים. ונחשו מה? למרות שאני מבלה חלק מהזמן שלי בעבודה בכתיבת אוטומציה,המקצוע שלי אינו להיות חרש כלים. אם ניקח דוגמה בשני סרטים (שרק אחד מהם יש סיבה לראות), אפשר לראות שני אנשים שיוצרים חרב. הטורי האנזו, חרש החרבות האגדי ב”קיל ביל”, וחרש החרבות המומחה קונור מקלאוד ב”איש הנצח 3″. מה זה? קונור מקלאוד הוא לא חרש חרבות? אבל הוא מכין חרב! הוא יודע איך לעשות את זה! במקרה הטוב, נדמה לי שנוכל להסכים על כך שהוא לוחם שיודע דבר או שניים (ואפילו יותר) על ייצור חרבות.  
וזו הבעיה שיש לי עם חרש הכלים. אני יודע לתכנת. אני כותב את האוטומציה שתרוץ בכל לילה ותיתן לנו סטטוס על התוכנה, אני מרחיב ומשפץ את התשתיות בהן אני משתמש, אני כותב סקריפטים שחוסכים לי שעות, אבל את כל זה אני עושה כדי לשפר את הבדיקות שלי – כי אני בודק תוכנה. 
חרש הכלים, לעומת זאת, אינו בודק תוכנה. לפעמים תוכלו למצוא הגדרות תפקיד כמו “מפתח אוטומציה”. זה חרש כלים. מה הוא לא? הוא לא בודק. גם אם מדי פעם הוא מריץ בדיקות, המטרה העיקרית שלו היא לפתח כלים שישמשו לבדיקות. תוך כדי הדיון עם באך ניסיתי להשתמש במושג “אֻמן” כדי לייצג את מה שאני עושה, אבל במחשבה שנייה, זה לא עובד והמונח הזה סובל מאותן מחלות מהן סובל חרש הכלים. בקיצור, אני נשאר עם בודק תוכנה. 
המונח השני, אותו אני שומע בכל מיני מקומות, הוא התואר “טכני” לבודקים שיודעים לתכנת. מתן התואר הזה לבודקים שגם מתכנתים יוצר את הרושם שבודקי תוכנה שאינם מתכנתים הם “לא טכניים”. מעבר לכך שהרעיון הזה הוא עלבון ישיר, הוא גם גורם לרעיונות שגויים ומזיקים. 
אולי כדאי להתחיל עם תזכורת קצרה – למה זה לא נכון לומר שבודקי תוכנה שאינם מתכנתים אינם “טכניים”: 
ראשית – בעוד שאנחנו רגילים לחשוב על מתכנתים כעל “אנשים טכניים”, ללכת בכיוון השני ולהניח ש”טכני”–>”תכנות” זה לא נכון. למשל, אנחנו מצפים ממנתחי מערכות שיהיו טכניים, כי הם לוקחים את מה שהלקוח רוצה ומגדירים בעקבות זאת דרישות טכניות למהדרין. אין שום עבודת תכנות במה שהם עושים, ולמרות זאת הם טכניים (כן, אני יודע שאצלכם מי שעושה את זה לא נקרא מנתח-מערכות. יצא לי לשמוע מיליון ואחד שמות לתפקידים שזה נופל תחת אחריותם – מהנדס מערכת, מהנדס דרישות, ארכיטקט, מנהל מוצר. לא כל בעלי התפקידים האלה מתכנתים). ואם האנשים האלה הם טכניים, מה עם בודקי התוכנה שסוקרים את התוצרים שלהם? ואלה שמוודאים שהמוצר עומד בדרישות הנ”ל? אלה לא אנשים טכניים?
שנית – חקירת באגים מצריכה כישורים טכניים. נכון, לא כל באג דורש חקירה ויש כאלה שהם ברורים מאליהם (“יש לך טעות הקלדה בטקסט שרואים על המסך”), אבל לעיתים קרובות, כדי לתת דו”ח מועיל על באג צריך לחטט בקבצי לוג, לבדוק את מסד הנתונים, לצמצם את תרחיש הבדיקה למינימום האפשרי ועוד. כל אלה – כישורים טכניים. 
שלישית – יופי, תיקנו את הבאג שפתחתי. האם אני פשוט חוזר על התרחיש המקורי בלי לחשוב? לא. כל בודק ששווה משהו יטרח להבין מה בדיוק תוקן ולנתח מחדש את ההשלכות האפשריות כדי שיוכל לבדוק אם התיקון לא גרם לבעיות נוספות.  טכני? ועוד איך. 
אפשר להמשיך עם “רשימת הדברים שבודקים עושים ודורשים כישורים טכניים” (תיווך בין מפתחים ואנשים מהתחום העסקי, השתתפות בישיבות עיצוב, בדיקות אבטחה, סקירות קוד…), אבל נדמה לי שהנקודה ברורה. 
עכשיו, איזה נזק כבר נגרם מזה?
אני טוען שחלק מההשלכות הן: 
– נזק למוניטין של מקצוע הבדיקות. 
– לבודקים שאינם מתכנתים קשה יותר לבצע את העבודה שלהם. 
– כישורי הבסיס של בודקים מתחילים יהיו נמוכים, והמוטיבציה להשקיע בלפתח את כישורי הבדיקות נמוכה גם היא. 
– שכר לא הולם לבודקי תוכנה (בעיקר אלו שאינם מתכנתים). 
ועכשיו לפירוט. 
הנקודה הראשונה נראית לי מובנת מאליה, אבל בכל זאת ארחיב עליה קצת – בודקי תוכנה עובדים באופן צמוד עם מפתחי תוכנה. רוב המפתחים שאני מכיר שמים את התכונה “להיות טכני” די גבוה ברשימת התכונות לפיהן הם שופטים את האדם מבחינה מקצועית. למה? כי קשה להם יותר לדבר על העבודה שלהם עם אנשים לא טכניים. כי הם צריכים להתאמץ ולפשט את מה שהם עושים. אם בודקי התוכנה נחשבים לא טכניים (כי כל הבודקים הטכניים יודעים לתכנת), המפתחים יעריכו אותם פחות. גם בלי להתכוון לזה. 
זה, בתורו, משפיע על היכולת של בודקי תוכנה לעבוד בצורה אפקטיבית. אנא הרימו יד אם אמרו לכם אי פעם “עזבו, זה מסובך מדי בשבילכם” (או משהו דומה). יצא לי לקבל את התגובה הזו כמה פעמים (לא מהמפתחים שלי), ובנוסף לכך שזה מרתיח, זה גם מפריע לעבוד – כי מישהו לא נותן לי מידע שאני צריך רק כי הוא מניח שאני לא מסוגל להבין אותו. כדוגמה, באיזה משני המקרים ניתן לבדוק דברים טוב יותר – אם המפתח מספר “הוספתי LRU cache למערכת כדי לשפר ביצועים”, או “עשיתי כמה שינויים בתשתית כדי לשפר ביצועים” ? ההבדל נובע אך ורק מההערכה של המפתח לסיכוי שהבודק יבין על מה הוא מדבר. 
לגבי כישורי הבסיס והדחף להתקדם – מתי בפעם האחרונה הסתכלתם על מי שמנסים להיכנס לעולם הבדיקות? על אלו שנדמה להם ש”קורס בדיקות” באיזו מכללה יקנה להם מספיק ידע כדי למצוא עבודה? על אלו שאומרים “אין לי זמן\רצון\יכולת להשקיע בלימוד, אבל אני רוצה להיכנס להייטק” ומישהו אומר להם “תנסה להיכנס בתור QA”. כלומר – יש לנו הרבה מאוד אנשים חסרי כישורים שמנסים להיכנס לעולם הבדיקות. חלקם עקשנים מספיק או סתם בני מזל ומצליחים להיכנס פנימה. 
כל זה היה יכול להיות טוב ויפה, אילו האנשים האלה היו מתאמצים לרכוש כישורים תוך כדי עבודה. אלא שאין שום דבר שדוחף אותם להשתפר. הם יכולים להמשיך לעשות את אותה עבודה בסיסית ולא מאוד טובה שהם עשו במשך שנים, כי מי יחליף אותם?  מישהו שיצא ממכללה אחרת ומגיע עם אותו סט של אין-כישורים? הבודקים הנוכחיים לפחות כבר מכירים קצת את המוצר ואת האנשים. 
אילו בדיקות היו נחשבות כמקצוע טכני, היינו רואים שני דברים –  הראשון הוא שמכיוון שאנשים רואים בכישורים טכניים משהו שקל יותר למדוד וחשוב יותר להשתפר בו – היינו רואים השקעה בפיתוח כישורי בדיקות, השתתפות נרחבת יותר בכנסים וכד’. השני הוא פחות המלצות לאנשים מקריים שאומרים “אני רוצה הייטק בלי להתאמץ” ללכת לבדיקות. חסימת הדרך לאנשים לא מיומנים וחסרי הכשרה בסיסית ששווה משהו, תשפיע על הלך המחשבה ותדחף אנשים לשפר את הכישורים שמבדילים בינם לבין כל אותם אנשים שנשארו בחוץ. 
ולסיום – נקודה נוספת שברורה מאליה. 
כשאני התחלתי לעבוד, המשכורת הראשונה שלי הייתה בערך פי שניים מזו של בודק תוכנה מתחיל שאינו מתכנת, וגבוהה מזו של כמה וכמה מנהלי בדיקות. הערך שהבאתי לחברה בשנה הראשונה שלי לא היה בר השוואה למה שהביאו כמה מחברי הצוות שלא תכנתו, אבל בכל זאת, כאשר אחד מהם פוטר בשל קשיים אישיים, לא יכולנו למצוא לו מחליף, כי עברנו לשכור רק בודקים שמתכנתים, והמשכורת שלו לא הייתה קרובה למה שנדרש. 
נכון – זה מוגזם להפיל את כל הבעיות האלה רק על האמירה ש”בדיקות תוכנה לא נחשב למקצוע טכני”, מה גם שיש בחוץ בודקי תוכנה לא טובים שהם בהחלט “לא טכניים”, אבל למרות זאת, ומכיוון שאני בהחלט מאמין שבדיקות הוא מקצוע טכני (או לפחות “גם טכני”) – יש לתפיסה השגויה הזו חלק מסויים בכל הנקודות שהזכרתי, וצריך לשבור את המעגל הזה איפשהו, כי אם בדיקות זה מקצוע לא טכני, אז אפשר לגייס אנשים לא טכניים לבדיקות. ואם יש אנשים לא טכניים בבדיקות, אז זה מקצוע לא טכני. 
אה, ועוד משהו אחד. הגיע הזמן למחוק מהלקסיקון גם את “בודק ידני” – זה גרוע כמעט כמו “לא טכני”, ומגדיר אנשים על בסיס כישור אחד שאין להם, ולא על בסיס מה שהם עושים. 

 

Comments are closed.


Looking for something?

Use the form below to search the site:


Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!