בעייה ייצוגית Advocating for a user?

(Note: Even though the trigger for this post came from an English speaking source, I don't really consider it a reaction, so English will be at the end, as usual.)

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

ובכן:

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

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

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

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

Every now and then I hear someone mentioning that "A tester is the user's advocate", and I believe it's time we've stopped repeating this mistake. This time, I was reminded of this saying when I listened to Joe Colantonio's interview with Melissa Tondi (By the way, if you haven't heard Joe's podcast, I quite enjoy it), when he asked about Melissa's talk in STPCon about "balancing technical acumen and user advocacy" (around the 16th minute), and it seems that they both accept without question the statement that a tester is expected to advocate for a user (to be fair, they mentioned a pendulum movement between being "technical" and representing a user). 

Well :

Software testers, in most cases, can't represent the user efficiently, and shouldn't do so even when we can. First and foremost - because the user isn't the one paying our salaries. We are hired to promote our employer's interests. Sure, those interests often include caring for the wants and needs of the end user, but it's not always the most efficient use of our time. And while it's true that bugs that are not manifesting in real usage are not really a concern, but acting as a user isn't necessarily the best way to find interesting problems. There are also things that are of no interest to the user, but should definitely interest a tester (For example: code tidiness and simple design are a in the best interest of the team, and are definitely within the testers' scope). 

Besides, in many cases, a tester simply cannot represent the user - How many of us have banking experience? or civil engineering? Doctoring? Piloting? education? accounting? How many of us can represent users from ten different countries?

What's worse is that as long as this saying is still out there, it creates the misconception that the main capability of a tester is to think like the user, and therefore a real user would be a great tester (They might be, just as they might happen to be great developers or expert doctors, but there's no relation between their skill as tester and the fact that they are real users). 

Even if we accept the narrow view that preaches that a tester's role is to find bugs (which I don't. you can see some initial thought around it here), "The user will want to act *this* way" is a very small subset of the interesting problems a tester should search for. No legitimate user would want their work to be lost just because one of the other 3000 concurrent users have performed an action at the exact right moment to cause a race condition - but no user will ever be concerned  about such a thing (While a tester should be). No legitimate user cares about how the system management actions are being monitored (but a problem there might cause a security auditor to disqualify the product). No user will object buying stuff at a 50% discount due to a software bug in the billing system (but the finance team will dearly care about it). When we go and test a piece of software, there's so much more that we do than just "think like a user" - we should start saying that.