מנהיגים ברשת שולחן העבודה למנהלים בישראל
מאת: מיכאל שורץ *
הגדרת שלב הבדיקות
קשה מאוד להגדיר מהו "שלב הבדיקות". לצורך המחשת הרעיון המובא במאמר זה, "שלב הבדיקות" יתייחס לשלב בו מתחילות להתבצע בדיקות מקיפות על תוצרי הפיתוח (בד"כ ע"י אנשי בדיקות ייעודיים). לצורך הדיון, בדיקות מקיפות מתחילות החל משלבי האינטגרציה (של גופי פיתוח שונים העובדים על הפרוייקט) ועד לשלבי בדיקות מערכת מלאים. רבים מכנים שלב זה כ"שלב ה-QA". בשל מרוכבותו של המושג "QA" ורוחב היריעה – המאמר ידבוק במושג "שלב הבדיקות".
מטרתו של שלב הבדיקות
לפני שבוחנים את תרומותיו של שלב הבדיקות לפרוייקט, חשוב להבין מהי מטרתו המוצהרת של שלב הבדיקות. התשובות המקובלות לשאלה זו:
* "לאפשר לבעלי העניין במוצר לקבל מדד לאיכותו ועמידתו בדרישות שהוצבו לו"
* "להוכיח שהתוכנה עושה את מה שהיא אמורה לעשות" (הגדרה חלקית ובעייתית)
* "למצוא את הפערים בין מה שהתוכנה אמורה לבצע/לא-לבצע, לבין מה שהיא בפועל מבצעת/לא מבצעת" (הגדרה קצת יותר מלאה)
ואכן, זוהי המטרה העיקרית של שלב הבדיקות. שלב חשוב וקריטי להצלחת הפרוייקט.
אך האם זוהי המטרה הבלעדית? האם בכך מסתכם תפקידם של הבודקים?
במרבית המקרים התשובה היא חיובית, ללא הרבה היסוס. תפקידו הממוקד לסמן "V" על איכות המוצר, כפי שהוא נתפס בעיני רבים, גורם לחוסר בתשומת לב ניהולי. עיקר הפוקוס בפרוייקט, כמו גם ההתלהבות הניהולית, נתונים לשלב הפיתוח (במובנו המסורתי: העולם של מפתחי התוכנה).
ראייה לכך, מנהלים נוטים להקל ראש בתכנון שלב הבדיקות בשלבי תכנון הפרוייקט, ועל כן רבים מטיפים להסיט תשומת לב רבה לשלב זה (והם אכן צודקים). אבל דווקא ההטפה הזו מעידה על כך שזה לא טריוויאלי. אחרת – לא היה צריך להטיף…
רבים ממנהלי הפרוייקטים נזכרים בשלב הבדיקות רק ברגע האחרון. מעטים מערבים ומשלבים אותם עוד בשלבי התכנון, ורק ה"מחמירים" מתייחסים לתכנון הבדיקות כחלק אינטגראלי מתכנון הפרוייקט עצמו.
תפקידים נוספים של "שלב הבדיקות"
הניסיון בשטח מראה, שההתייחסות הפשטנית אל שלב הבדיקות ממעיטה את תרומותיו לפרוייקט. שלב הבדיקות טומן בחובו ערך רב עבור מנהל הפרוייקט בפרט, והחברה בכלל:
א. שלב הבדיקות כתמונת איכות – בראש ובראשונה, ובהתאם למטרתו המוצהרת, שלב הבדיקות נותן את תמונת איכות התוצר של הפרוייקט. זוהי התרומה הקלאסית והמובנת מאליה ע"י המנהלים המעורבים. כבר לאחר סבב בדיקות ראשון, תחושות הבטן של המעורבים מתחילות להיעלם ומתבססות על הערכות יותר מדעיות. יש תמונת מצב שמתחילה לראשונה להתבהר, ועימה, מתאפשרת למנהל הפרוייקט ההזדמנות בפעם הראשונה לנשום לרווחה (אפילו קצת), או לחילופין להתחיל לדאוג (אבל הפעם מתוך ידיעה…).
ב. תוכנית בדיקות מוקדמת, פחות בעיות בהמשך – כבר בתחילת הדרך, בשלב כתיבת תוכנית הבדיקות (עוד לפני תחילת הבדיקות) צצות בעיות רבות במסמכי האפיון: דו-משמעות, טיפול במקרי קצה, אי-בהירויות וכדומה. הדבר נובע מהזהירות הרבה, הדקדקנות והיסודיות המאפיינת את אנשי הבדיקות. החינוך שלהם ואופיים הם שדוחפים אותם לשאול שאלות (לעומתם, לאנשי הפיתוח קיימת נטייה גדולה יותר לפרש באופן סובייקטיבי). בד"כ המחיר של מציאת בעיות אלו בשלב מאוחר יותר, אם בכלל, גבוה הרבה יותר.
דוגמא להמחשה: בפרוייקט שתוכנן להימשך כ-3 חודשים (שבועיים אפיון, חודשיים פיתוח, שבועיים בדיקות ושבוע התקנה), כתיבת תוכנית הבדיקות נדחתה לשבוע לפני תחילת הבדיקות. במהלך הכתיבה (תוך בחינת מקרי קצה רבים), איש הבדיקות הציף מס' שאלות הנוגעות לסוגיות לא ברורות באפיון. שאלות אלו גרמו לשינוי בסיסי באפיון ובעקבותיו פיתוח. סה"כ, נגרם עיכוב של שבועיים בפרוייקט. אף אחד מלבד איש הבדיקות לא שם לב למקרים אלו מקודם.
ג. שלב הבדיקות – איתור בעיות אינטגרציה – המעבר משלב הפיתוח לשלב הבדיקות מתאפיין לרוב בקשירת קצוות שונים של תוצרי הפרוייקט. במקרים רבים, עובדים על התוכנה מספר מפתחים במספר גופים שונים. לעיתים מקדישים לבדיקות האינטגרציה שלב בפני עצמו, ולעיתים שלב הבדיקות מהווה את ההזדמנות הראשונה לראות את כל המרכיבים השונים "מנגנים ביחד". זהו הרגע בו חופרי המנהרה משני צידיה – נפגשים. לפעמים, רק בשלב הזה נסגרים הפרטים האחרונים של הממשקים והפרמטרים השונים.
דוגמא להמחשה: בפרוייקט מול לקוח מסויים, נדרשה קונפיגורציית מערכת מסויימת, המגדירה מס' פרמטרים שונים. בזמן הפיתוח, נבדקה התוכנה עם מגוון פרמטרים ללא קשר להגדרה הספציפית של הלקוח. בזמן הבדיקות, התעקשו הבודקים לבדוק גם את דרישות הלקוח הספציפיות – והבדיקה גילתה התנגשות פונקציונאלית דווקא במקרים אלו.
ד. חשיבות ההתקנה לבדיקות – בהמשך לסעיף הקודם, שלב הבדיקות מתחיל מהתקנה (אולי לא בהכרח הראשונה – אבל בהחלט משמעותית) של התוכנה ו/או המוצר. פעם ראשונה שהמוצר עצמו עובר ידיים (ולא רק מסמכים). קיימים שני מעברים:
- מעבר טכנולוגי: המעבר מסביבה אחת (סביבת הפיתוח) לסביבה אחרת (סביבת הבדיקות). ניתן להתייחס לפעילות זו כחזרה ראשונה להתקנה מבצעית, ולבחון את האיכות של תהליך ההתקנה עצמו.
דוגמא להמחשה: באחד מן הפרוייקטים, ההתקנה של המוצר במעבר משלב הפיתוח לבדיקות נמשכה כיומיים. תוכנית ההתקנה המבצעית איפשרה חלון זמנים של 6 שעות בלבד. כתוצאה מההתקנה הממושכת, נאלצה החברה להקדיש שבוע נוסף להקטנת זמן ההתקנה. הפרוייקט התארך בשבוע, אך נמנעה הפתעה מצערת בליל ההתקנה המבצעית…
- מעבר ידע: המוצר הוא יותר מאשר הטכנולוגיה שלו. המוצר משלב בתוכו תהליכים, ממשקי משתמש, טרמינולוגיה ועוד. בעולם אוטופי, אנשי הבדיקות לא צריכים את המוצר כדי להכיר אותו (הם מעורבים כבר בשלבי האפיון). בפועל, המצב לא כך. שלב הבדיקות צריך להתחיל בהדרכה מסודרת לאנשי הבדיקות. הדרכה זו מהווה בסיס ראשוני לחומרי ההדרכה של המוצר. לפיכך, העברת הידע מהווה אינדיקציה ראשונה לתהליכי ההדרכה וההטמעה הנדרשים.
דוגמא להמחשה: בפרוייקט המכיל ממשקי משתמש רבים, תוכנית ההדרכה התבססה רבות על נתונים והפקת לקחים שנמסרו ע"י אנשי הבדיקות (בהתבסס על החוויה האישית).
ה. שלב הבדיקות אינו שלב הומוגני רציף. מטבעו, זהו שלב מחזורי המתנהל בסבבים (ללא קשר למתודולוגיית ניהול הפרוייקט כולו). בסבבים אלו משתתפים שחקנים חשובים: מנהלי המוצר, אנשי הפיתוח ומנהל הפרוייקט. המתח הארגוני הנוצר בין ה"בודק" ל"נבדק", הצורך בקבלת הרבה החלטות קטנות (לעיתים גם גדולות) גורם ליצירת תקשורת פנים-ארגונית עניפה: "מהו באג? מהו השינוי? מה קריטי? מתי לתקן? האם לתקן?". תקשורת זו משפרת את תפקוד צוות הפרוייקט גם בפרוייקטים נוספים, ובכך תורמת לשיפור תהליכים בחברה. לא בכדי הכלים לניהול באגים/שינויים הם מהראשונים, שהוטעמו בתהליכי ניהול הפרוייקטים, על מנת לשפר את יכולות התקשורת והארגון.
דוגמא להמחשה: בפרוייקט פיתוח המשותף לשתי חברות, הכולל מספר מחזורי פיתוח ובדיקות, היו קצרים בתקשורת בין שתי החברות. שלבי האפיון והפיתוח סבלו מפערי הבנה ומתודולוגיות עבודה. בשלב הבדיקות המשותף, בשל אופי התקשורת הנדרשת – המצב הוביל לכמעט עצירה מוחלטת של הפרוייקט. לאור זאת, הושקע מאמץ ניהולי רב על מנת להגדיר תהליכי עבודה ותקשורת המתבססים על תו"ל עבודה מוסכם וטכנולוגיה תומכת. תהליכים אלו, שהוגדרו בשלב הבדיקות עזרו לכל שאר המחזורים בפרוייקט.
ו. תהליך הבדיקות מכיל תרבות מובנית של מדידה: סטטיסטיקות על באגים, אחוזי בדיקה, מדדים פונקציונאליים של המוצר, והרבה מאוד מדדים לא-פונקציונאליים שלו. ללוח השעונים של מנהל הפרוייקט מתווספים בבת אחת אינדיקאטורים רבים, המקטינים את אי-הוודאות ומשפרים את יכולתו לתכנן את המשך הפרוייקט.
דוגמא להמחשה: בפרוייקט חריג מסוגו בחברה, ניתנו הערכות זהירות לזמן הבדיקות (עקב החדשנות בפרוייקט: ממשקים חדשים ושימוש במוצר מדף חדש). בתחילת שלב הבדיקות, גוף הבדיקות החל לפרסם באופן יומי סטטיסטיקות על תוצאות הבדיקות: באגים ואחוזי כיסוי (coverage). ניתוח התוצאות לימד על קצב הבדיקות וסיפק כלי אובייקטיבי לתכנון המשך הפרוייקט.
ניצול הפוטנציאל הטמון ב"שלב הבדיקות"
מכל האמור לעיל, עולה שתהליך הבדיקות מהווה מסגרת חשובה למנהלים. עבור מנהל הפרויקט זהו כלי מרכזי בבקרה על הפרויקט כולו (ולא רק על איכות המוצר). עבור שאר המנהלים – זהו כלי טוב לבקרה על החברה, ויותר מכך, הזדמנות ללמוד, לשפר ולהטמיע תהליכים.
שלב הבדיקות מעיד על בשלות החברה, איכות תהליכי האפיון, תהליכי הפיתוח ועוד. תהליך אפיון טוב לא יעיד על תהליך בדיקות קלוקל. אבל להיפך – כן. מבחינה זאת, צודקים (בחסד ולא בזכות) אלו המתבלבלים בין המושגים "בדיקות המוצר" ו"הבטחת איכות" (QA). במובנו הרחב, המושג הבטחת איכות מתייחס לכלל תהליכי החברה, ולא רק לאיכות המוצר. והטענה היא, שאופן בדיקת איכות המוצר מעיד על איכות תהליכי החברה.
המסקנה המתבקשת היא להקדיש תשומת לב רבה יותר לשלב הבדיקות, ולספק את כל הסביבה הדרושה על מנת להבטיח את קיומו בצורה ראויה ותקינה – להקפיד על gating נכון: בהירות התכולה הנבדקת, הקפאת הקוד, דאגה לסביבת בדיקות ראויה ומתאימה ומעבר של כל השותפים בפרוייקט על תוכנית הבדיקות.
בנוסף, על מנהל הפרוייקט לערב בכל השלבים את אנשי הבדיקות באופן אקטיבי, ואף לנהל בקשיחות את אבן-הדרך של התחלת הבדיקות. אם ניתן, מומלץ להתחיל מחזורי בדיקות בשלב מוקדם ככל הניתן (אם כי, להתחלה מוקדמת הרבה חסרונות– וצריך לדעת לנהל אותם). שיתוף הפעולה בין מנהל הפרוייקט למנהל הבדיקות – קריטי.
ברמת החברה, יש לתת חשיבות לאיוש אנשי הבדיקות (ובעיקר מנהליו) – על מנת למקסם את פוטנציאל התרומה הכוללת לחברה, מעבר לאיכות התוצר עצמו.
לבסוף, ישנם מקרים בהם נכון להשתמש במתודולוגיות מעולם הבדיקות לתוך תהליכים נוספים בחברה, כגון שימוש במדדים. דוגמה קיצונית היא הכלת שלב הפיתוח בתוך שלב הבדיקות על מנת לאלץ מבנה Agile-י לפרוייקט, במידת הצורך (בעיקר כשהחברה לא מיומנת בכך).
דוגמא להמחשה: בפרוייקט של 4 חודשים, ובשל תנאים מסויימים (לחץ הזמנים ואופי הלקוח) – היה ידוע מראש שיהיו שינויים באפיון במהלך הפיתוח. החברה החליטה להתחיל סבבי בדיקות בשלב מוקדם ביותר. כל המנגנונים של סקירת באגים (bugs review) בתדירות גבוהה וניהול גרסאות פיתוח בהתאם שימשו כנקודות שינוי באפיון. בפגישות תכופות אלו (בתדירות של פעם ביומיים, בפורמט קצר) נכחו כל בעלי העניין: המאפיינים, המפתחים והבודקים ומנהל הפרוייקט. הפרוייקט "לבש" צורת ניהול Agile-ית באופן טבעי ומוכר, ללא צורך בהדרכה ספציפית. החלטה זו הבטיחה את הצלחת הפרוייקט.
סיכום
לשלב הבדיקות בפרוייקט מטרה עיקרית, חשובה ומוכרת. אך מעבר לכך, הוא מהווה כר נרחב של הזדמנויות לשיפור תהליכים בחברה, וטומן בחובו ערך רב למנהל הפרוייקט. המודעות לפוטנציאל זה בשלב ראשון וניצולו – יכולים לשמש כנכס אסטרטגי המבטיח הצלחה בפרוייקטים, וכמנוע ללימוד ולהתפתחות ארוכי טווח.
* מיכאל שורץ, מנהל פרוייקטים בחברת פרסונטה. בעבר, מפקד על גופים טכנולוגיים בצה"ל.
tweet[Google]
Follow @leadersnet
| מנהיגים ברשת |
| www.leadersnet.co.il |
| leaders@leadersnet.co.il |
| © כל הזכויות שמורות ל"מנהיגים ברשת" דצמבר 2005. החומר מותר לשימוש אישי בלבד. אין לעשות בחומר שימוש מסחרי/עסקי ו/או להפיצו בכל דרך שהיא (להוציא באמצעות יצירת קישור למאמר ספציפי ולעמוד הבית במקביל) מבלי לקבל רשות מפורשת בכתב מהנהלת האתר |
