|
|
|
בודקים ממאדים – מפתחים מנגה?
|
|
מאת עפר קידר, ראש צוות QA בחברת Netwise. אפריל 2008
|
|
|
תקציר המאמר:
אחת הדילמות איתה מתמודד מנהל QA היא גיוס והשמה נכונים של בודקים בפרויקטים.
האם עדיף לבחור מפתח מתחיל או אולי מפתח שעבד על הפרויקט ומכיר את ה"קרביים" שלו, או לחילופין לבחור בבודק תוכנה שמכיר את המערכת הנבדקת בצורה שטחית יותר וללא רקע במדעי המחשב? המאמר Testers and Developers Think Differently מאת ברט פטיקורד (Bret Pettichord), מומחה לארכיטקטורת בדיקות תוכנה ולמתודולוגית SCRUM, עוסק בהבדלים בין הכישורים, התכונות והגישות שיש לאנשי פיתוח לבין אלו של בודקי תוכנה. לטענת המחבר, הבנת ההבדלים ביניהן תאפשר ניצול נכון של המאפיינים השונים של בעלי התפקידים הללו. המאמר פורסם במגזין STQE – מגזין לבדיקות תוכנה והנדסת איכות.
|
|
|
|
מפתחים ובודקים חושבים אחרת
|
|
ברט פטיקורד (Bret Pettichord), מומחה לארכיטקטורת בדיקות תוכנה ולמתודולוגית SCRUM בוחן במאמרו שניים מבעלי התפקידים בתהליך פיתוח פרויקט תוכנה: מפתחים ובודקים. בצוות יעיל, בודקים ומפתחים משלימים זה את זה על ידי מתן נקודות מבט שונות וכישורים שונים. טעות נפוצה היא לראות בבודקים "מפתחים קטנים", ולעודד אותם לחקות כישורים וגישות של מפתחים. למעשה, לבודקים טובים יש תכונות רבות הסותרות לחלוטין תכונות של מפתחים טובים. הבנת ההבדלים בתכונות הנדרשות בכל אחד מהתפקידים השונים חשובה ליצירת צוות שעובד היטב יחד.
|
|
|
|
בודקים לא חייבים להיות מומחים
|
|
בודקים טובים מסוגלים לתת ביקורת גם אם הם אינם מומחים בנושא הנחקר והם נדרשים להבנה רחבה במגוון נושאים. לעומתם, מפתחים נדרשים לעיתים קרובות להיות מומחים בתחום טכני מוגדר, לדוגמה: פרוטוקולי תקשורת. בודקים טובים נדרשים להשתלט במהירות על כל מערכת שיתבקשו. לעיתים קרובות מוקצה להם זמן מועט לטובת הכרת המערכת או הפיתוח שבוצע בה. לעומתם, מפתחים נדרשים להבנה מעמיקה של המערכת שהם מפתחים, לפני שיוכלו לעבוד עליה (למשל, הבנה של הספריות או הפרוטוקולים בהם ישתמשו).
|
|
|
|
לבודקים צריך להיות הידע שיש למשתמשים. הם צריכים לבדוק את המערכת כמו משתמש ולא באופן שהמפתח היה רוצה שהמשתמש יפעל. ניתן לומר אפילו, שחשוב שלבודק לא תהיה הכרה מעמיקה מדי של ארכיטקטורת המערכת הנבדקת. שמירה על רמה מסוימת של אי-ידיעה או עמימות לגבי המערכת יכולה לתרום לבודק. מפתחים, לעומת זאת, אינם יכולים להרשות לעצמם לפתח במצב של עמימות.
|
|
|
|
מפתחים מפרשים לפעמים את אי הידיעה של הבודק כסימן לחוסר מקצועיות. מאידך, כשמבקשים ממפתחים לבצע בדיקות, הם עלולים לגלות קושי בבדיקת מערכות מנקודת המבט של הבודקים, תוך התעלמות מהידע הנוסף שיש להם אודות הקרביים של המערכת.
|
|
|
|
בודקים אינם מומחים – הם צריכים להכיר את עולמו של הלקוח עד רמה מסוימת ולהיות בעלי הבנה של מערכות מחשב. הם צריכים להיות טובים ברכישת ידע בסיסי, וחשוב להבין שאין הדבר מעיד על חוסר יכולת, אלא על גישה שונה של רכישת ידע.
|
|
|
|
בודק טוב
|
מפתח טוב
|
|
משתלט במהירות
|
לומד לעומק את המערכת
|
|
מכיר את עולם הלקוח
|
מכיר את הקרביים של המערכת
|
|
שומר על עמימות המערכת
|
מומחה במערכת
|
|
|
|
|
לבחון את התנהגות המשתמש
|
|
אפיונים של מערכות תוכנה הפכו בשנים האחרונות למורכבים מאוד. מפתחים נדרשים כיום להשקיע יותר זמן ומאמץ מבעבר, כדי לוודא שהם מבינים את האפיונים. במקביל, חשוב שהבודקים יחקרו את צורכי המשתמשים והתנהגותם, כדי לוודא שהתרחישים הריאליסטיים של השימוש במערכת ייבדקו. בודקים מתמקדים במשתמש ומשקיעים מאמץ בבדיקת שגיאות שהמשתמש עלול לבצע, הבודק מוודא שבמקרים בהם המשתמש טעה, המערכת תאפשר לו לחזור לאחור ולתקן את הטעות. לעומתם, מורכבות האפיונים גורמת למפתחים להתמקד באפיון המערכת ובמה שאמור להתרחש בה כשהמשתמש מבצע פעולה בצורה תקינה.
|
|
|
|
כתוצאה מההבדלים בגישות, לעיתים קרובות בודקים יתייחסו לתקלות במערכת במונחים של רמת החומרה עבור המשתמש. לעומת זאת, מפתחים המתמקדים באפיון יגיבו לעיתים בביטול התקלה ("למה שמישהו יעשה דבר כזה?!") או ישקיעו משאבים בתקלות מעניינות, גם אם השפעתן על המשתמש זניחה. פעמים רבות מפתחים לא מבינים את החשיבות של חלק מהבדיקות המתוכננות. ייתכן שהסיבה לכך היא שמדובר בבדיקות שמנקודת מבט של האפיון הן חסרות ערך, אך מנקודת המבט של המשתמש, הן מכסות תרחישים שהוא צפוי לבצע.
|
|
|
|
הבודקים נדרשים לבחון את המערכת מנקודת מבטו של המשתמש, ולכן אין לראות בהם עוזרים של המפתחים. יש לעודד את הבודקים להבין את צורכי המשתמש, ומומלץ להפגיש בין הבודקים לבין הלקוחות ואנשים בחברה העובדים ישירות עם הלקוחות.
|
|
|
|
בודק טוב
|
מפתח טוב
|
|
מוכוון להתנהגות המשתמש
|
מכוון לאפיון המערכת
|
|
מתמקד ב"מה עלול להשתבש"
|
מתמקד ב"איך זה אמור לעבוד"
|
|
מתמקד בחומרת התקלה עבור המשתמש
|
מתמקד בבעיות טכנולוגיות מעניינות
|
|
|
|
|
לחשוב בצורה אמפירית
|
|
בדיקה טובה של מערכת נשלטת על ידי המודל המדעי. ה"תיאוריה" הנבדקת היא אם התוכנה עובדת. בודקים מתכננים ניסויים המנסים להפריך את התיאוריה וחושבים בצורה אמפירית במונחים של התנהגות נצפית, ולכן רקע של לימודי מדעים יכול לשרת אותם. פיתוח תוכנה, לעומת זאת, דומה לפיתוח תיאוריה. פיתוח תוכנה כולל קביעה של חוקים ויישום של כללים. מפתחים טובים חושבים בצורה תיאורטית והם יכולים להפיק תועלת רבה מלימודי מתמטיקה. מפתחים שמתמקדים בתיאוריה שלהם לגבי דרך הפעולה של התוכנה, עלולים להתייחס בזלזול לתקלה הנובעת מהתנהגות משתמש שאינה מותרת בתיאוריית התוכנה שפותחה ("לא יכול להיות שהתקלה הזו קרתה!"). בודקים טובים מתמקדים במה שקורה בפועל ("עובדה שזה קרה – התקלה מתרחשת בנסיבות האלו:..."). בודקים טובים הם אנשים סקפטיים. מפתחים טובים הם אנשים מאמינים.
|
|
|
|
בודק טוב
|
מפתח טוב
|
|
בעל חשיבה אמפירית
|
בעל חשיבה תיאורטית
|
|
חושב איך המערכת מתנהגת
|
חושב איך המערכת אופיינה
|
|
אדם סקפטי
|
אדם מאמין
|
|
|
|
|
לומדים לקבל את המונוטוניות
|
|
בודקים טובים מבינים שבדיקות תוכנה עלולות להיות מונוטוניות - הם פשוט לומדים לקבל את זה. מפתחים רבים אינם אוהבים עבודה שחוזרת על עצמה – הם טובים בלחשוב על דרכים לבצע בדיקות בצורה אוטומטית. מפתחים שמתבקשים לבצע בדיקות ידניות משקיעים לעיתים זמן באיתור דרכים לבצע את הבדיקות בצורה אוטומטית, במקום לבצע את הבדיקות ולאתר את התקלות. ביצוע בדיקה מונוטונית היא מאתגרת, אבל יכולה להיות חשובה וחיונית. בודקים טובים נדרשים לשמור על ערנות, גם כאשר הם מריצים את אותה בדיקה בפעם ה-14.
|
|
|
|
קונפליקט הוא חלק מהמקצוע
|
|
בודקים טובים לא יכולים לחשוש מויכוח. העבודה שלהם היא לבשר בשורות רעות ולדווח על תקלות. לכן בודקים טובים אינם יכולים לחשוש מתגובותיהם של אנשים המקבלים בשורות רעות. לעומתם, מפתחים נדרשים לעיתים להמנע ממעורבות רגשית שעלולה לפגוע בריכוז שלהם. מפתחים שהתבקשו לבצע בדיקות עלולים להתעכב יתר על המידה על אבחון מקור הבעיות שמצאו לפני שידווחו עליהן. בודקים טובים מדווחים על תקלות ברגע שהם מצליחים למקד אותן ולשחזר אותן.
|
|
|
|
בודק טוב צריך להראות יש לו אמונה בנקודת המבט שלו, ושהוא יכול להמשיך לעבוד גם כאשר מתעורר קונפליקט. במהלך ראיון עבודה, לדוגמה, בודק טוב יידע לספק תשובה לשאלה: "איך אתה מגיב כשמפתח דוחה את התקלה עליה דיווחת, ומכריז עליה as designed"? מועמדים בעלי כישורים טכניים טובים שמרגישים לא בנוח במצבי קונפליקט, לרוב לא יהיו בודקים טובים.
|
|
|
|
בודק טוב
|
מפתח טוב
|
|
מקבל את המונוטוניות
|
מחפש פתרונות אוטומטיים למונוטוניות
|
|
חי בשלום עם הקונפליקט
|
נמנע מקונפליקטים
|
|
מדווח על תקלות
|
מנסה להבין תקלות
|
|
|
|
|
לסיכום
|
|
הבנת ההבדלים בין מפתחים לבין בודקים חשובה ליצירת צוותי עבודה פרודוקטיביים. גישות שונות עוזרות במציאת פתרונות, וכבוד הדדי מסייע בפתרון בעיות באופן קבוצתי. אין לבחון או לשפוט בודקים לפי הקריטריונים של מפתחים. חשיבה אמפירית היא נכס לבודק ואין להבין אותה במונחים של חוסר יכולת לבדוק בצורה תיאורטית. יש להעריך בודקים היודעים "קצת מהכול" ולא לבקר אותם על אי - היותם מומחים בתחום מסוים.כדי לעמוד בתחרות בתעשיית התוכנה כישורים וגישות של בודקים עשויות לעמוד בניגוד מוחלט לכישורים וגישות שאנו מחפשים במפתחים. כאשר מגייסים בודקים, יש לחפש ולטפח כישורים וגישות אלו, ואין להסתפק במפתח צעיר. צוותי עבודה פרודוקטיביים הכוללים מפתחים ובודקים זקוקים לשני סוגי הכישורים והגישות. חשוב להטוות לבודקי תוכנה מסלול קריירה ברור בתחומם, בדיוק כמו לאנשי פיתוח. חשוב לזכור כי עלינו לטפח באופן דומה את כישוריהם של המפתחים ואת אלו של הבודקים.
|
|
|
|
|
