"By that experience Tukey and I discovered that what goes on in different people’s heads when they think they’re doing the same thing—something as simple as counting—is different for different people."
בדרך כלל, כאשר אתה חושב על מקצועות אחרים מאשר בדיקות תוכנה, נראה כי אנשי המקצוע צריכים להיות הם עצמם כדי להשלים את המשימות שלהם - מורה הוא אדם שמלמד, מהנדס הוא אותו אדם שגם בונה תוכנית וגם משחק עם כלבו וכו'. אתה יכול לחשוב על שחקן שהתפקיד העיקרי שלו הוא להיות מישהו אחר. אבל אם חושבים על זה לעומק, שחקן לא מנסה לתאר מישהו אחר אלא לנסות להפוך את האישיות לאמינה בעיני הקהל. יש מקצועות בהם אתה חייב לדעת מה היריב שלך חושב, כמו שחמט או טניס. אבל גם זה לא ממש להיות הם בכל פעולה.
תחום בדיקות התוכנה כל כך עשיר ומפותח (לפעמים אני חושב שרק בודקים יודעים את זה, ואפילו לא את כולם), אנחנו כמעט אחד מתחומי הטכנולוגיה המובילים. ישנם מאמרים רבים וספרים על בדיקות תוכנה, כנסים, וכו'.
עם זאת, הקונפליקט הבסיסי של התחום שלנו נדון רק לעתים רחוקות כנושא בפני עצמו (אם כי היבטים שלו נדונו פעמים רבות): איך יכול בודק תוכנה להיות מסוגל לבצע משימות שהן, מעצם הגדרתן, סותרות. איך הוא יכול להיות בודק תוכנה מקצועי באותו זמן, במסגרת הבדיקות, וגם נציג האמיתי של משתמש הקצה?
מצופה שמהנדס הבדיקות צריך לחקות את הלקוח. זה תמיד היה חלק משמעותי של העבודה של בודקים. אבל הבוחן מגיע עם העבר שלו, כולל המקצועי, עם הראייה הרחבה שלו, והוא אף פעם לא יכול להשתמש ביישום לגמרי בצורה נאיבית כמו הלקוח, וגם אם כן - כלקוח אחד מני רבים. כאשר בודק מפעיל את היישום, כל מצב נפשו שונה.
הנה כמה הבדלים שעולים על הדעת בין בודק התוכנה המקצועי לבין הלקוח (כאשר אני אומר "לקוח" אני חושב במיוחד על מישהו שמשתמש באפליקציות לא ככלי משמעותי במקצוע שלו, כיישום חשבונאי לרואה חשבון, אלא אנשים המשתמשים באפליקציות כחלק ממשימות היומיום או הבידור שלהם):
Feynman, Richard P.. "What Do You Care What Other People Think?": Further Adventures of a Curious Character (p. 59). W. W. Norton & Company. Kindle Edition.
זה לא המקרה של בדיקות תוכנה.
תחום בדיקות התוכנה כל כך עשיר ומפותח (לפעמים אני חושב שרק בודקים יודעים את זה, ואפילו לא את כולם), אנחנו כמעט אחד מתחומי הטכנולוגיה המובילים. ישנם מאמרים רבים וספרים על בדיקות תוכנה, כנסים, וכו'.
עם זאת, הקונפליקט הבסיסי של התחום שלנו נדון רק לעתים רחוקות כנושא בפני עצמו (אם כי היבטים שלו נדונו פעמים רבות): איך יכול בודק תוכנה להיות מסוגל לבצע משימות שהן, מעצם הגדרתן, סותרות. איך הוא יכול להיות בודק תוכנה מקצועי באותו זמן, במסגרת הבדיקות, וגם נציג האמיתי של משתמש הקצה?
מצופה שמהנדס הבדיקות צריך לחקות את הלקוח. זה תמיד היה חלק משמעותי של העבודה של בודקים. אבל הבוחן מגיע עם העבר שלו, כולל המקצועי, עם הראייה הרחבה שלו, והוא אף פעם לא יכול להשתמש ביישום לגמרי בצורה נאיבית כמו הלקוח, וגם אם כן - כלקוח אחד מני רבים. כאשר בודק מפעיל את היישום, כל מצב נפשו שונה.
הנה כמה הבדלים שעולים על הדעת בין בודק התוכנה המקצועי לבין הלקוח (כאשר אני אומר "לקוח" אני חושב במיוחד על מישהו שמשתמש באפליקציות לא ככלי משמעותי במקצוע שלו, כיישום חשבונאי לרואה חשבון, אלא אנשים המשתמשים באפליקציות כחלק ממשימות היומיום או הבידור שלהם):
בודק יודע יותר על האפליקציה מהבחינות הפונקציונליות, הטכניות; מטרה חשובה היא למצוא באגים (מול המשתמש שבא להינות או לבצע פעולה מסויימת), עובד בצורה מתודולוגית; הבודק כנראה מעורב רגשית (הצלחת המוצר = ההצלחה שלו), לבודק רקע על קונוונציות, מוצרים מתחרים, על UX, הא - והוא גם מקבל תשלום על זה.
וכמובן, גם הסביבות שונות. בדרך כלל, לבוחן יש חומרה טובה יותר מרוב המשתמשים. הסביבה של הלקוח כוללת יישומים שהבוחן בדרך כלל לא. בודקים אוהבים להתחיל כל יום חדש, בעוד משתמש הקצה עשוי להשאיר את האפליקציה פתוחה במשך חודשים.
התשובות לבעיות אלו זמינות. אבל הן אינן אלא דרכים לעקיפת הבעיה, למשל: השתמש בצוות מגוון, Exploratory Testing, בצע כמה פגישות של ציד באגים (שם לא כל המשתתפים בודקים). העסק קבוצות מיקוד, מחקרי ממשק משתמש. יש רעיון אפילו לבדוק את האפליקציה בזמן שיכרות, תוך ניסיון לחקות סוג מסוים של משתמש. אפשר להשתמש בכובעים שונים וכמה טיפוסים ידועים. אנו משתמשים בבדיקות "קראוד " ואנו משתמשים בסיפורים של משתמשים.
הרשימה לעיל (+ בדיקות יחידה וכל כלי איכות אחרים) יכולה להוריד את הסיכון שלנו. אבל הם לעולם לא יחסלו אותו. מצד שני, אנו עשויים למצוא באגים שייראו לנו מאוד קריטיים, אבל לא רוב המשתמשים שלא ייתקל בהם או יהיה יהיה לו אכפת.
פתרונות?
אני לא יכול לחשוב על דרך פשוטה להתגבר על זה. אני חושב שלהיות מודע להבדלים לעיל עשוי לעזור לנו, למשל על ידי ניסיון לראות את היישום כאילו בפעם הראשונה. לא תמיד, אבל מעת לעת. אל תחשבו שאתם יודעים מה שהמשתמשים עושים או חושבים, ואם יש לך כמה רעיונות על זה כדאי לנסות לגבות אותם על ידי נתונים סטטיסטיים או סקירות משתמשים.
וכמובן, גם הסביבות שונות. בדרך כלל, לבוחן יש חומרה טובה יותר מרוב המשתמשים. הסביבה של הלקוח כוללת יישומים שהבוחן בדרך כלל לא. בודקים אוהבים להתחיל כל יום חדש, בעוד משתמש הקצה עשוי להשאיר את האפליקציה פתוחה במשך חודשים.
התשובות לבעיות אלו זמינות. אבל הן אינן אלא דרכים לעקיפת הבעיה, למשל: השתמש בצוות מגוון, Exploratory Testing, בצע כמה פגישות של ציד באגים (שם לא כל המשתתפים בודקים). העסק קבוצות מיקוד, מחקרי ממשק משתמש. יש רעיון אפילו לבדוק את האפליקציה בזמן שיכרות, תוך ניסיון לחקות סוג מסוים של משתמש. אפשר להשתמש בכובעים שונים וכמה טיפוסים ידועים. אנו משתמשים בבדיקות "קראוד " ואנו משתמשים בסיפורים של משתמשים.
הרשימה לעיל (+ בדיקות יחידה וכל כלי איכות אחרים) יכולה להוריד את הסיכון שלנו. אבל הם לעולם לא יחסלו אותו. מצד שני, אנו עשויים למצוא באגים שייראו לנו מאוד קריטיים, אבל לא רוב המשתמשים שלא ייתקל בהם או יהיה יהיה לו אכפת.
פתרונות?
אני לא יכול לחשוב על דרך פשוטה להתגבר על זה. אני חושב שלהיות מודע להבדלים לעיל עשוי לעזור לנו, למשל על ידי ניסיון לראות את היישום כאילו בפעם הראשונה. לא תמיד, אבל מעת לעת. אל תחשבו שאתם יודעים מה שהמשתמשים עושים או חושבים, ואם יש לך כמה רעיונות על זה כדאי לנסות לגבות אותם על ידי נתונים סטטיסטיים או סקירות משתמשים.
אין תגובות:
הוסף רשומת תגובה