יום ראשון, 29 ביוני 2008

שיפור תהליך הפיתוח והבדיקות - היכן היה אפשר למצוא את הבאג

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

אבל לא פחות חשוב לדעת אילו באגים "ברחו" גם בנקודות אחרות של התהליך:
  • מסמכי שיווק;
  • מסמכי מהנדס מערכת;
  • מסמכי פיתוח;
  • Unit tests;
  • Private Integration;
  • Integration Tests;
  • וכמובן שלבי הבדיקה:
    Sanity;
    פרוגרסיות;
    רגרסיות;
    ועוד.
הערה: ברור שלא בכל חברה יש כל השלבים, ואני מניח שיש חברות שיש להם שלבים שלא מניתי. העיקר כאן הוא העקרון.

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

בכדי לבדוק את הנושא יש לאסוף ממערכת ניטור הבאגים באגים של גרסה אחת או יותר ולמיין אותם לפי השלבים בהם הם היו אמורים להתגלות.

ההמשך הוא בהתאם לתוצאות: אם למשל הבעייה ב-Unit tests יש לבצע הערכה:
אילו איזורים חסרים? האם צריך לעדכן את כל הבדיקות או יש פערים מסויימים? האם אפשר לוותר על חלק מהבדיקות כי אין יותר סיכון בקוד הנ"ל? במקרה זה כדאי שהבודקים יעשו review על בדיקות ה-unit test ובכלל יעבדו צמוד עם הפיתוח.
אם אלו מסמכי מהנדס המערכת או השיווק: האם יש review מסודרים? האם אנשים באים מוכנים? אולי יש צורך לעזור לאנשים למצוא באגים במסמכים (זה לא קל)?
וכן הלאה.

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

לקבל או לא לקבל גרסה פגומה לבדיקות?

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

לכאורה מצב ברור של "No Go". אבל נשאלת השאלה מה טוב יותר למוצר, או לחברה: לקבל בכל זאת את המוצר כפי שהוא או לחכות?

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

מה בעד קבלת הגרסה?
  1. שתהיה תעסוקה לבודקים.
  2. שיכירו את המוצר או את הפיצרים החדשים, יעדכנו את מסמכי הבדיקות. כך יהיו מוכנים יותר לסבב השני.
  3. ימצאו בעיות שאינן ידועות ולא היו נפתרות בסבב הזה.
  4. תהיה למקבלי ההחלטות תמונה טובה יותר של כלל הבעיות במוצר.
מה נגד (בהתאמה לסעיפים למעלה)?
  1. הבודקים עלולים ל"הישרף". אם המוצר מלא בבעיות או נופל כל 10 דקות, הבודקים יחושו שהם עובדים לחינם, והמוצר עלול באופן טבעי להימאס עליהם.
  2. הכרת המוצר מוטלת בספק כיוון שאולי משהו עובד בדרך X כיוון שיש בעייה Y. אם חושבים ש-Y זה בסדר הבודקים יוסיפו TC שגויים וכו'.
  3. נניח שהפיתוח מודע ל70% מהבעיות, ומה-30% הנותרים יש באגים שהם קריטיים וכאלה שלא. מה שיקרה הוא שהתהליך יעצר עד שיפתרו נניח 70% מהבעיות הידועות (עם השאר אפשר לחיות). אז בשלב ה-Unit tests או ה-Sanity יתגלו הבאגים הקריטיים ואז הגרסה תחזור לפיתוח. שום זמן לא בוזבז. העניין היחידי הוא שבמקום לפתור בעיות מינוריות יחסית הפיתוח היה פותר בעיות קריטיות יותר.
  4. זה נכון, למרות שכבר די ברור שיש בעייה רצינית (מוצר כה גרוע שהבדיקות סרבו לקבל).
סיכום ביניים הוא שלפי סעיף 3 אולי היה נחסך זמן ולפי 4 היינו יודעים יותר על המוצר.
אבל ברור שלכל סעיף יש ניקוד או משקל שונה.

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

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

כמו תמיד יש מקום לשיקול. אם יש אפליקציית שרת-לקוח שהשרת מוכן וניתן לבדוק אותו כשלעצמו ואילו ה-client אינו מוכן - ניתן לקחת את השרת. אבל ככלל אני ממליץ בחום לא לקבל.

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

יום חמישי, 5 ביוני 2008

אי-התאמה של עובד

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

זה נכון שמדברים בנושאי עבודה על בסיס יומיומי, אבל זה יותר ברמה נקודתית ולא ברמת מטרה שעל העובד להתפקס עליה.

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

כמובן שמעבר יש לתת לו הדרכות מסודרות והסברים עד לרמת התלושים לאוכל וקריאה לתמיכה של טכנאי המחשב, אבל זה לא הנושא.

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

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

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

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

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

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

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

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

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

לגבינו כעובדים, אני מציע לערות שיחות תיאום ציפיות עם המנהלים גם אם הם אינם יוזמים זאת. יכול להיות שיש דברים מסויימים שיעלו מאוד את ערכנו בעינייהם ואנו לא יודעים זאת.

יום שלישי, 3 ביוני 2008

שיפור הבדיקות 4: הפקת לקחים - Lesson Learn

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

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

----

יש שתי רמות ל-lesson learn : רמת חברה ורמת מחלקה. זה שברמת חברה נוגע לא רק בבדיקות אלא גם בבעיות של גרסה, ניהול מוצר, פיתוח ועוד. בעצם כל קבוצה לדעתי צריכה לעבוד על התחקירים שלה ולהציג בנפרד למנהל הגרסה תוך דסקוס, ואז להיות חלק מהמצגת הסופית שתתעד מה היו האירועים ומה נלמד לקראת הגרסה הבאה. את התהליך הזה מומלץ לבצע לאחר כל גרסה.
ברמת מחלקה אפשר לעשות את זה תדירות גבוהה יותר, מבחינת המבנה התהליך זהה לחלק של הבדיקות בתהליך כולל.

בכדי להיות מדייק יותר על מנהל הבדיקות, למשל, לפרט מקרים ברמת צוותים וגם ברמת מחלקה.

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


לדוגמא:
מצב חיובי. תיאור:
לא היו מקרים של החזרת build לפיתוח כיוון שלא היה ראוי לבדיקות.
אנליזה:
העבודה הצמודה בין הבדיקות לפיתוח, תיאום ציפיות ומסמך בדיקות sanity שהבדיקות ביקשו שהפיתוח יערוך גרם לגילוי מוקדם של בעיות.
פירמול:
לקראת מסירה של build לבדיקות, הבדיקות יהיו מוחנים עם מסמך sanity אותו יעבירו לפיתוח. בנוסף יהיה דיון בקבלת המוצר על הבעיות שהתגלו בשלב הפיתוח, מה שלא מומש וכד'.

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

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

רשומות פופולריות