יום שבת, 20 בדצמבר 2008

הקדמה: מיהו דורון בר ומהי מטרתו

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

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

אנסה להכניס כמה שיותר "סיפורים מהחיים" כדוגמאות ממחישות.





View Doron Bar's profile on LinkedIn

ויקיפדיה: הצד המכוער של האנציקלופדיה החפשית

בשנת 2001 פרוייקט הויקיפדיה יצא לדרך, בהקמה של לארי סאנגר, ג'ימי ויילס ובן קוביץ, ומאז באמת השאר הוא היסטוריה. אין ספר שזהו הפרויקט הקהילתי המצליח והגדול ביותר, שבו התכנים אינם אישיים אלא תרומות כמעט אנונימיות למצבור הידע האנושי. מאז כל מי שרוצה לקבל מבוא פשוט וברור לנושא מסוים פשוט מחפש ולעתים מוצא – אותו בויקיפדיה.
אין ספר שהלב מתרחב לנוכח עבודת נמלים אלטרואיסטית שמטרתו היא אכסון כל הידע האנושי, שכן זוהי, לדעתי מטרת האנציקלופדיה באשר היא; הרעיון הוא להכיל את כל המידע האנושי, מהנויטרון עד החמור, מערכים של מקצוע בדיקות התוכנה עד לסיפור חייו של קליגולה, הקיסר הרומאי הנחמד.
וכאמור היופי הוא בכך שאין היררכיות, גם אני, גם את, כל אחד יכול לתרום. האומנם?
ככה זה עם פרויקטים כבירים. כך היה עם הדת. ישו אמר שהסיכוי שעשיר יגיע לגן העדן הוא הסיכוי שגמל יעבור בקוף המחט. תזכירו את זה לנציגו עלי אדמה, האפיפיור, השולט על אימפריה כלכלית משגשגת. פעמים הרבה עומד בתחילת מהלך אידיאליסט שהרעיון מושך אותו, אנשים באמת דגולים. ותמיד אנשים קטנים ואינטרסנטים מחליפים אותו, והדרך הופכת למטרה, והדת לכלי לצבירת כסף (לפחות ארגונים כלכליים שקופים במידה זו או אחרת – הם רוצים כסף).
ומה הקשר לוויקי? הקשר לצערי הינו ישיר.
הרעיון היפה עבד קצת, ואז הבינו שיש למנות שוטרים למדינה האידיאלית. לשוטרים קוראים מפעילי מערכת. הם ישפטו את הערך שכל אחד יכול למלא, וגם יהיו הזרוע המבצעת – יקצצו במה שלא נראה להם. לא ברורים הכישורים הנדרשים למשרה, פרט ל"מישהו המתמצא היטב בשימוש בוויקי ומכיר את הנהלים העקרוניים של האתר". הם פועלים כמו כולם בעילום שם בדרך כלל, ופעמים רבות קובעים את גורל הערך מבלי שיהיו בעלי ידע פורמלי בנושא, או ידע בלתי פורמלי, או בכלל.
מעל למפעלי המערכת יש "ביורוקרטים", אלוהי המערכת. רובם (2 מתוך 3) כמו תולעים תחת אבנים מסתתרים מאחורי כינויים. איך נהיים "ביורוקרטים"? לאלוהים הפתרונים. האם זוהי משרה המוקצבת בזמן? האם יש פיקוח עליהם? מהם כישוריהם? שוב – אלוהים בוודאי יודע, אנחנו לא.
די בזה לבדו בכדי להעכיר את אווירת החופש והנאורות, שכן שקיפות בכל מוסד ובמיוחד כאן היא הכרחית ומכובדת. שכן מי ישמור עליהם שאינם (ואינני טוען שהם כן) אינטרסנטים? מקבלי שוחד (ואינני טוען שהם כן)?
יש "דייל" שהוא אבי האלוהים. וזה כל מה שכתוב עליו: "דייל בוויקיפדיה הוא משתמש שביכולתו להגדיר ולבטל הרשאות מפעיל מערכת, ביורוקרט, בודק, בוט ועוד בכל מיזמי קרן ויקימדיה". שימו לב שככל שעולים בדרגות המידע מתמעט והולך.
טוב, אולי צריך משטרה כי בכל-זאת העולם אינו מושלם ואינטרסנטים עלולים להתערב ולמשל בערך על מצגות יכניסו את שם החברה שלהם שמתמחית בתחום. נכון, העניין הוא שאינני יודע מי הם אלה שכן מחליטים בסוף.
ואם אתם חושבים שבעלי התפקידים או הכותבים הוותיקים מסכימים ביניהם? אם לא – אתם צודקים. לעתים תכופות אפשר לראות ויכוחים רבים והשתלטויות שרירותיות של בעלי התפקידים.
למשל בערך "הסוד" בלשונית השיחה (מי שרוצה לדעת יותר על "מאחורי הקלעים" של הערך ואיך הוא נכתב מוזמן להציץ בלשונית הזו – לא בטוח שזה יויף כבוד לויקי). מתלוננת הכותבת שטענו נגדה שהמידע אינו מדויק, והיא שואלת מדוע. איש לא טרח לענות לה. בנוסף מישהו הוסיף קישור לבלוג ב"תפוז". "לא נראה לי שזה הולם" טוען ה"שוטר", "אלא אם כן יש איזושהיא [יש כזו מילה? יש איזושהי ואיזו שהיא דב] הוכחה שהבלוג הזה הוא בלוג נחשב בעולם הביקורת הספרותית.".
הנה עוד תלונות:
"פאקמן חסם אותי היום לאחר שערכתי את בנימין נתניהו. לא הוזהרתי (למרות שזו הפעם הראשונה שאני מנסה לערוך ערך כל שהוא), לא נתנו לי להתגונן וחסמו אותי גם בפני פתיחת חשבון ותגובה בדף השיחה". אתם מבינים –פאקמן , כן פאקמן, חסם אותו. למה? כי בא לו. עוד ממשיך הכותב "והכי גרוע זה שהוא לא התייחס כלל לטענות הקשות שהעלתי בדבר חוסר האובייקטיביות המשווע שיש בערך הנ"ל"...
רגע, אני מבולבל... הלא כתוב בעמוד ה"ברוכים הבאים" של וויקי ש"ערכי ויקיפדיה נכתבים בהתנדבות על ידי כל מי שמעוניינים להוסיף, לתרגם מוויקיפדיה בשפה אחרת, או לשנות תוכן קיים" [הדגשה שלי דב]. זוהי המהות שלה – לא? שכל אחד יכול להשתתף... לא, טוען הבחור מלמעלה והוא בסה"כ תסמין, לא משנה מה התוכן של הבלוג, כל עוד לא מדובר בסלב, אין להכניסו. ייתכן שמדובר במנחם פרי הבא, או בירון לונדון תחת שם בדוי, ויקי סגורה לכם.
והנה מניסיוני. כתבתי שני ערכים בויקי: על מארי ארנה (סופרת עכשווית אמריקנית) ועל "צלופן" – שם ספרה. למותר לציין שאין לי שום אינטרס כלכלי או אחר בנושא, אלא הרצון להעשיר את האנציקלופדיה. אין אלו ערכים חשובים, אבל האנציקלופדיה צריכה להכיל הכל – לא היא תשפוט מה יכנס ומה לא. אם הערך נידח – אדרבה לא יכנסו אליו.
לאחר זמן נודע לי במקרה שמחקו את הערכים האלה – שם הודעה לא הגיעה אלי לא מתוך ויקי ולא למייל. את הערך על הסופרת כיוון ש"השוטר" לא הכיר אותה (ממש אין לי מה לומר כאן ומה שיש לי לא אומר) ואילו לגבי הספר, מחקו "כי יש לכותב אינטרס כלכלי" (לא ציטוט מדויק – אינני מוצא ברשומות את הסיבה).
יש אחד, כפי שנודע לי, ש"שגורש מוויקיפדיה העברית משום שרצה להכניס ערכים על שחקניות פורנו." ומדוע שלא יהיו שחקניות פורנו שם? הן חלק מהתרבות... זה כמו לא להכניס את הביטלס לארץ כי הם "יקלקלו את הנוער". ובכן, זהו ה"נוער" ואתם לא שופטיו, והם לא ירוצו להיות שחקניות פורנו בגלל שיש ערך זה או אחר, לידיעתכם.
אני מאמין שלאנציקלופדיה חופשית יש מקום בעולם הוירטואלי, ואני מאמין שהיא זקוקה לניהול. רק שיש לבחור בכאלה שמבינים דבר אחד או שניים.
וזו הפעם הראשונה שאני מצטער שאין לי יותר קוראים והשפעה. חבל עליה, על ויקי.

מנהל סמכותי

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

יום ראשון, 28 בספטמבר 2008

בדיקות קומפוננטה

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

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

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

יום ראשון, 21 בספטמבר 2008

ביקורת קוד, Code Review

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

הגדרה:
* בדיקה מתודית והבנת הפעילות של הקוד.

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

מתי?
ה- Code Review הוא חלק מבדיקות ה-Unit Test, ויכול לבוא לפני הבדיקות הכוללות את הרצת הקוד, אחרי ואחרי תיקונים משמעותיים. בכל אופן זה בא אחרי קימפול מוצלח.

מומלץ להשתמש לפני ה- Code Review בכלי ביקורת קוד אוטומאטי, למשל QACPP.

למי?
על כותב הקוד להציג אותו בפני חברי הצוות ו/או ראש הצוות, סמכות טכנית וכד'.

צ'ק ליסט לדוגמא:
* האם יש שימוש בכל הארגומנטים?
* האם יש ארגומנט של אאוטפוט שאינו נוצר?
* האם יש משתנים שאינם מוגדרים היטב ביחס למטרתם?
* האם יש שימוש במשתנה לפני האתחול שלו?
* האם הקוד עקבי עם הדרישות?
* האם הקוד הוא לפי הסטנדרטים?
* האם יש הודעות שגיאה בלתי ברורות למשתמש?

חלק משאלות אלה ימצאו פתרון ע"י שימוש בכלי אוטומאטי.

יום שלישי, 22 ביולי 2008

Orthogonal Defect Classification - ODC - חלק שני

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

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

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

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

נניח ש-80% מהגרסה, וזה מצב הבאגים שנפתחו מבחינת ה-impact:


1. Installability : 18/2
2. Serviceability: 23/13
3. Standards: 4/0
4. Integrity/Security: 6/0
5. Migration: 15/2
6. Reliability:30/11
7. Performance: 2/1
8. Documentation: 9/2
9. Requirements: 13/3
10. Maintenance: 1/1
11. Usability: 4/2
12. Accessibility: 8/0
13. Capability: 38/8
למשל בעיות התקנה: 18 דיווחי באגים נפתחו, 2 עדיין פתוחים.
אפשר לראות ששלושת הבעיות העיקריות שהתגלו היו ב- Capability, ב- Reliabilityוב- Serviceability.
עכשיו אפשר לפרק ולהצליב עם מידע כמו הקומפוננטות הרלוונטיות בהן יש יותר בעיות מהסוגים הנ"ל, לשאלה אם הבעיות הן בקוד חדש או ישן וכד'. מכאן התובנות צריכות להיות שלכם.

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

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

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

יום רביעי, 16 ביולי 2008

Orthogonal Defect Classification - ODC - חלק ראשון

המאמר המקורי מכאן.

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

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

תהליך הישום של ה-ODC:
  1. התחייבות ההנהלה ליישום התהליך והלקחים שינבאו ממנו.
  2. המיון חייב להיעשות על-ידי הצוותים הטכניים ולהישמר בבסיס נתונים קל להפעלה.
  3. הבאגים הממוינים מאומתים על בסיס קבוע בכדי להבטיח עקביות ונכונות המיון.
  4. הערכה של המידע הנ"ל צריך להתבצע במחזוריות קבועה. שוב – איש טכני המכיר את המוצר צריך לעשות זאת. כלי ויזואלי חייב להיות לרשותו.
  5. יש לתת לממיינים פידבק על המיון, ועל התוצאות שלו – בכדי שימצאו צעדים לשיפור.
  6. יש לעשות פריוריטיזציה של הטעון שיפור, ולהמציא צעדים לתיקון.

מיון ואימות של הבאגים
ישנן שתי נקודות של מיון.

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

השנייה היא בעת תיקון הבאג. המאפיינים הם המטרה (target), סוג הבאג (type), המתאר (qualifier), מקור (source) וותק (age).
  • מטרה היא הזיהוי במישור הגבוה (בעיית דיזיין, קוד וכד') של הישות המתוקנת.
  • הסוג מתייחס לטבע התיקון של הבאג.
  • מתאר: האם התיקון הוא בגלל קוד או אינפורמציה חסרים, לא נכונים או חיצוניים.
  • מקור: האם הקוד הוא פנימי של הפיתוח, שימוש חוזר מספריה, מיובא מפלטפורמה אחרת, אאוטסורס או ונדור.
  • ותק: האם הקוד חדש – גרסה אחרונה? ישנה? שנכתב מחדש או מתוקן?
למידע נוסף לחצי כאן.

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

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

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

יום שישי, 11 ביולי 2008

סמכות מול מנהיגות והשטחים האפורים

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

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

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

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


מסקנה: צריך לא רק לדעת איך להרשים, אלא גם את מי.

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

העבודה מול הפיתוח

העמדה של קבוצת הבדיקות היא בעייתית. יש לה בעצם זכות קיום בגלל טעויות של אחרים, או בלשון אחר, בעולם מושלם היינו מובטלים (סליחה מראש על אי-העקביות). מול מרבית אנשי מקצוע בכלל אין פיקוח של צד שלישי, אלא של המנהלים שלהם. וגם במקרה האחרון המנהלים עשויים למנוע ביקורת מסיבות אישיות (חברות למשל) או פוליטיות. גם במקומות שיש שם מבקר, הוא עומד מול כל החברה ולא ספציפית מול גורם X, וגם כאן שיקולים שלא מן העניין עלולים להתערב.
לעומת זאת אנחנו אנשי הבדיקות מבקרים בעיקר את אנשי הפיתוח ביום יום. כל באג שנפתח זו בעצם אמירה שמישהו פישל, ואי-אפשר לטאטא את זה כי זה יפגע בחברה עצמה. למנכ"ל "מותר" לטעות, כך גם לאנשי השיווק (לא שהם אינם פגיעים אלא לא באופן כזה חד-חד ערכי). אבל מפתח שטעה – יקבל באג.
אני מתחיל בזאת כיוון שזה הרבה פעמים עומד בבסיס מערכת היחסים של הבדיקות-פיתוח. לא רק בעבודה הפרונטאלית אלא גם מאחורי הקלעים, המנהלים שלהם מודדים אותם בין אם פורמאלית ובין אם לאו לפי כמות הבאגים שנפתחים להם. הלחץ עליהם כפי שאפשר להבין לא קטן, וזה גורם למתח מתמיד בין הקבוצות. אפשר להקצין ולומר שהצלחה של הבדיקות = כשלון של הפיתוח.
עכשיו יש שתי אפשרויות: לקחת את המתח הזה למקום לא טוב: הבודקים הם ה"רעים" יאמרו המפתחים; הפיתוח סנובים וחסרי הבנה בסיסית של תהליכים, יענו הבודקים.
אבל אפשר לקחת את המתח ולעשות לו סובלימציה לכיוון של מקומות טובים: להתמקד על המטרה (מוצר איכותי שיצא בזמן) כקבוצה אחת וללא משחקי אגו, כשההצלחה (והכישלון אם יהיה, אבל באווירה כזו הוא נדיר) היא של כולם.
לכן חוק מספר אחד: תפקיד הבדיקות הוא להוציא מוצר איכותי ולא למצוא כשלים של מפתחים. אני מקווה שהניואנס ברור. בכל אופן הוא לא סמנטי אלא מהותי: אנו עובדים עם הפיתוח להוציא מוצר כמה שיותר טוב. אנו שמחים למצוא בעיות אבל לא קופצים במשרד בקריאות שמחה, ולא מאשימים. אנו מודאים את שורש הבעיה וחומרתה, ורק לאחר מכן מדווחים עניינית וללא שמחה לאיד. ואם זה show stopper אפשר להסתנכרן עם הפיתוח קודם להודעה.
אבל רצון טוב זה לא מספיק. בכדי שנוכל לעזור ובכדי שהמפתחים (וכלל החברה) יעריכו אותנו עלינו להיות מקצוענים ומקצועיים לעילא ולעילא. אלו חלק מהדברים ששמעתי מאנשי פיתוח שהפריעו להם בעבודה מול הבדיקות:
· הם לא מכירים את המערכת עד הסוף.
· כל פעם אני מסביר לבודקים מחדש על הפיצ'ר הזה שוב ושוב.
· לא ברור בכלל מדיווחי הבאגים מה הבעיה, אין לוגים וכד'.
וזה מביא אותי לחוק מספר שניים: קבוצת בדיקות חזקה ומקצועית (כלומר גם כבודקים וגם בטכנולוגיה) לעולם תזכה לכבוד והערכה מקבוצת הפיתוח. וזה דבר בסיסי, וזה כולל עמידה על הרגליים האחוריות אם צריך.
אני מאמין ששני החוקים שלעיל הם בסיס לשיתוף פעולה פורה.
לא תמיד אנשי הפיתוח מבינים את המבנה הנכון של התהליך ולמה בודקים מתרעמים על אי-נכונות של מסמכי ההתקנה (בהנחה שזה תפקיד הפיתוח להוציא אותם), ויש כאלה שחושבים שאנחנו פשוט מקבלים מוצר ומתחילים לבדוק ספונטאנית, או שהם לא מבינים מדוע הם צריכים לעשות בדיקות Sanity לפני מסירת המוצר לבדיקות – הרי הם (אנחנו) "בדיקות", לא? זה לא בהכרח נובע מזלזול או עצלנות, אלא מבורות. לכן חוק מספר שלש הוא: הסבר להם את תהליך הפיתוח כמו שאתה רואה אותו וסגור אתם על משהו שמתאים לחברה שלך, מבלי לוותר על עקרונות המקצוע.
לאחר מכן ארגן לחברה פרזנטציה של תהליכי הפיתוח והבדיקות. גם כדי לסגור את הנושא, גם למען השקיפות. בנוסף ברור לנו שאנחנו מקצועיים, צריך לשדר את זה הלאה כי אנשים פשוט לא יודעים. כדאי גם מדי פעם לאסוף את האנשים הרלוונטיים ולספר להם על התקדמות איכות המוצר, בעיות וכד'.
מעבר לזה, דבר עם הפיתוח באופן קבוע, נניח פעם בחודש. תבוא מוכן עם דברים שמפריעים לך, והם יבואו עם מה שמפריע להם. חוק רביעי: ערוץ פתוח וכן עם הפיתוח.
וכל זה כמובן מבלי לוותר על שום דיווח על תקלה ("לא צריך משה בחייך 2 דקות ואני פותר את זה, סמוך על יוסי אחיך". אח"כ כשזה לא יכנס לגרסה זה לא יהיה נעים לא למשה ולא ליוסי), מבלי לוותר למישהו כי "ככה זה עובד יותר טוב" וכו', ואם יש בעיה קריטית אל תמנע מלדווח עליה. הרעיון הוא לא לומר: "מסכנים המפתחים הם בביקורת תמידית", אלא "בואו ונעזור להוציא מהפיתוח את המיטב".

יום חמישי, 3 ביולי 2008

Unit Tests

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

Unit Tests
הגדרה: ה-UT אמור לבדוק יחידה אינדיבידואלית על-ידי הפיתוח. זוהי היחידה הקטנה ביותר שניתנת לבדיקה, או אפילו חיבור לוגי של כמה יחידות. זו יכולה להיות תוכנית פשוטה, פונקציה, פרוצדורה, מתודה או מודול. למשל יחידה שמקבלת שם משתמש, שולחת לבסיס הנתונים, מקבלת אישור או דחייה ומעבירה את התוצאה הלאה.
אחריות וביצוע: פיתוח.
בד"כ בדיקות אלה אוטומאטיות, יכולות להיות "קופסא לבנה" וגם "קופסא שחורה". כמו כן בדיקות אלו יכולות וצריכות להיות פרוגרסיביות ורגרסיביות.
מומלץ לכתוב את ה-UT לפני כתיבת הקוד עצמו.
מטרות:
  • שליחידה יש היכולות הנדרשות;
  • מקבלת ומוסרת את הנתונים הנכונים;
  • מתממשקת נכון;
  • זיהוי של בעיות שניתן לגלות רק ברמה הזו. למשל אני מכיר מקרה שהתשובה שהיחידה סיפקה היתה נכונה אך כפולה. בבדיקות של המוצר היה קשה מאוד לגלות זאת, אבל ייתכנו מקרים מסוימים אצל הלקוח שהפארסינג היה פשוט נפסק כתוצאה מכך.
ולבסוף: שהיחידה מוכנה (לאחר תיקון כל הבאגים) לאינטגרציה.
יש לזכור את היתרון העצום של מציאת בעיה בשלב זה: החיסכון בזמן. זיהו בעיה בשלב זה כשרק אדם אחד מעורב, ובנוסף ברור מיידית מעיין נובעת ההתנהגות הבלתי רצויה. במקרה של קבלת מוצר שיש בו באג (כמו מה שקורה בחדר הבדיקות) האנליזה עלולה להיות ממושכת לא רק באפיון מדויק של התקלה שהבודקים עושים, אלא גם באנליזה של הפיתוח לגבי מקורה של הבעיה הנ"ל.
בדיקות טובות של UT הן:
  • אוטומאטיות;
  • קלות לניהול;
  • קלות להרצה;
  • שומרות לוגים;
  • מייצרות סטטיסטיקות;
  • כוללות בדיקות שליליות, טיפול בבעיות;
  • ערכי קצה וערכי default;
  • ארגומנטים לא ואלידיים (טקסט במקום מספר).
כמו תמיד, יש לעשות review על כל בדיקה ומידי פעם על ה-scope של הבדיקות, כיסוי האזורים וכד'. שני הדברים האחרונים – בתיאום עם מחלקת הבדיקות.
נקודות נגד:
מאריך את זמן הפיתוח, לא תמיד קל ליישום.
הערה: נעזרתי בויקי באנגלית: http://en.wikipedia.org/wiki/Unit_test שם יש חלק נוסף הקושר בין ה-UT ל-Extreme Programming.

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

יום שישי, 23 במאי 2008

ad hoc testing או: exploratory testing, מבוא

סיכום מאמר:
Ad hoc testing, Chris Argus & Bob Johnson
זהו מאמר ראשון שלי מתוך כמה שיבואו בעתיד בנושא ה-exploratory testing. המאמר שאני מסכם יכול לשמש כמבוא טוב שייתן מושג מהן בדיקות אלה. זה אינו מאמר חדש, וחסרונותיו עמו:
  • שימו לב שהמילה "פרוגרסיה" אינה נזכרת בשום מקום.
  • האם באמת "אד הוק" שווה תמיד ל"חד פעמי"?
  • האם באמת זה עניין לבודקים מיומנים?
  • איך אפשר ללמד את צוות הבדיקה לעשות את זה?
  • האם בכ"ז ניתן לתת guidelines לבודקים שהוא יותר מפורט ממה שרשום כאן אך עדיין פתוח דיו?
  • הערות נוספות בגוף המאמר. כל מה שכחול – שלי.
המאמר אינו טוען שבדיקות אלו אמורות להחליף את הרגרסיות. אשתדל בהמשך להביא דעות שונות ואז את דעתי הנובעת מניסיון.
בגדול אני חושב שכל הנושא הזה הוא נושא חשוב ומרגש ויכול למלא את ייעודו (למצוא באגים, ללמד על התוכנה, לתת סטאטוס מהיר לגבי מצב הגרסה וכד') כמו גם להביא עניין חדש לצוותי הבדיקה.
הקדמה:
נשאלת השאלה מדוע לשים דגש על הרעיון של סט בדיקות ספציפי (מהסוג של אד הוק) שבסופו-של-דבר מבוצעות רק פעם אחת. התשובה היא שזה מבדיל את בדיקות האד-הוק מבדיקות אחרות פורמאליות ששמות את הדגש על החזרה עליהן, כמו רגרסיות ו-acceptance tests. הרעיון של הערך הקיים בבדיקות אד-הוק סותר לכאורה את ההיגיון ששם דגש על חזרה ובדיקות אוטומאטיות. רוב התעשייה מעדיפה את החזרה על בדיקות מאשר יצירת בדיקות חדשות. נשאלת השאלה מדוע להריץ שוב ושוב בדיקות ישנות כשיש לנו האפשרות להריץ בדיקות חדשות שלא הורצו מעולם?
למען ההגינות יש לציין שזה תלוי הקשר: במערכות שתלויים בהן חיי אדם יש לשים דגש חזק על בדיקות רגרסיה. מעבר לזאת אנחנו נרוויח אם נמצא שילוב מנצח של בדיקות חד-פעמיות ורגרסיות. נחזור לזה, אך כעת נראה מה נאמר כבר על הנושא.
בעצם ה-exploratory testing צמחו מבדיקות האד-הוק ואוזכרו לראשונה בשנת 1988 על-ידי קאנר (ניתן לראות מקור במאמר עצמו). שם נאמר שבזמנים "מתים" אפשר ורצוי להמשיך בבדיקות, מבלי לבזבז זמן על הכנתן או הסברתן. כל מה שצריך זה לסמוך כל האינסטינקטים שלכם.
ואילו באתר הזה http://www.testingcraft.com/exploratory.html מוזכרים כמה אלמנטים של ה-exploratory testing:
  • שזירה של תכנון וביצוע בדיקות בניגוד לתכנון קודם, ביצוע אח"כ.
  • הרעיון שבודקי התוכנה לומדים עליה בזמן הבדיקות.
  • דגש על יצירתיות וספונטאניות.
  • ציפייה לעתים שה-exploratory testing ישנו את ההקצאה של המאמץ. כלומר ביצוע הבדיקות יקדים את התכנון.
ג'יימס באך טוען שתוצאות של בדיקה אחת משפיע על התכנון של הבדיקה הבאה.
אז מה הקשר בין בדיקות אד הוק ל-exploratory testing? אד-הוא הוא מקרה פרטי של exploratory testing. בזמן עריכת exploratory testing , TC רבים יהיו אד הוק (חד-פעמיים) והשאר - לא. דרך אחת להבחנה היא להתבונן בהערות שיש לנו בנוגע ל-exploratory testing. באופן כללי ל-exploratory testing יהיה מעט תיעוד או בכלל לא, אך כתוצאה מכך יהיו הערות בלתי-רשמיות. אם ההערות מפורטות דיין בכדי שיהיה אפשר לחזור על הבדיקות אזי סביר שאלו אינן בדיקות אד הוק. מצד שני אם אין הערות או שהן בעלות גוון של הדרכה כללית, סביר שאלו בדיקות אד הוק. אז מה הן exploratory tests שכתובים מראש?
בד"כ יש ספקנות מצד מנהלים לגבי בדיקות אד-הוק . הרעיון שבודקים מיומנים ויקרים "יבזבזו" את זמנם על הרצת בדיקות חד-פעמיות וזניחתם לאחר מכן גורם לאי-נוחות למנהלים אלה. אבל לexploratory testers מיומנים אין בעיה להצדיק את העניין. כמות וחומרת הבעיות המתגלות בדרך זו היא מדהימה. המאמר הזה ינסה לתת הקשר מועיל לתבנית בדיקות אלה.
בדיקות אד-הוק מול רגרסיות
אחת המטרות של האתר היא לתת הגדרה טובה יותר לבדיקות אד הוק. ההגדרה הסטנדרטית היא שאלו בדיקות "למטרה מסוימת וללא התחשבות במערכת כולה". בהסתמך על כך אנו מתארים בדיקות אד הוק כמקרה חקירתי שמצופה שתריץ רק פעם אחת, אלא אם התגלה באג. יש כאלה המתנגדים להגדרה זו של בדיקות אד הוק, ואלו מוזמנים להחליף את הביטוי "חד-פעמי" ב"אד-הוק". אנו ננסה להכניס את בדיקות האד הוק לפרספקטיבה ע"י השוואה לצורות בדיקה אחרות. בפירוט, לכל שיטה יש את החסרונות והיתרונות שלה במימד הקריטי של כח מציאת הבאגים ובבניית רמת האימון. מטרה עיקרית בבדיקות האד הוק היא לגלות באגים חדשים במוצר. בידיו של בודק מיומן, בדיקת האד הוק עשויה להיות מועילה ביותר בגילוי בעיות כאלה. בהעלאת רמת האימון, בדיקות האד הוק הן יחסית חלשות, בהשוואה לבדיקות רגרסיה, בייחוד אם אלה האחרונות יסודיות מאוד.
הגדרה של רגרסיה:
1. בדיקה של באגים שתוקנו.
2. שקוד חדש גרם לחזרה של באגים שתוקנו.
3. שקוד חדש לא הרס פונקציונאליות ישנה.
הדגש כאן הוא על הוכחה שיש באגים בקוד, וכך מחזקים את הטענה על חוזק כח מציאת הבאגים שיש לרגרסיות. לעומת-זאת בהגדרה אחרת הרעיון הוא שהתוכנה עובדת וכך שמים דגש על העניין של אימון:
"בדיקות רגרסיה הוא תהליך של בדיקת שינויי תוכנה בכדי לוודא שהקוד הישן עדיין עובד ביחד עם השינויים החדשים... לפני שחרור גרסה חדשה הTC הישנים מורצים מולה בכדי לוודא שהיכולות הישנות עדיין קיימות ולא הושפעו לרעה מכניסת קוד חדש."
במאמר זה נשים דגש על ההגדרה השנייה כיוון שהיא נפוצה יותר.
אנו גם נרחיב את ההגדרה: משתמע ביצירת מערך בדיקות הרגרסיה הרעיון שהבדיקות יורצו יותר מפעם אחת, אחרת אין טעם ליצירת המערך מלכתחילה. יתר על כן, חברות רבות מבצעות אוטומטיזציה של בדיקות הרגרסיה, כך שיורצו מהר יותר, זול יותר ולעתים קרובות יותר. במובן הזה בדיקות רגרסיה הן ההיפך מבדיקות אד הוק.
בדיקות רגרסיה ואד הוק משלימות האחת את השניה. אם מוצאים באג באחת משתי הצורות זקוקים לצורה השנייה: למשל במציאת באג בעת רגרסיה נשתמש בבדיקות אד הוק בכדי לנתח ולבודד את הבעיה ולהקטין את מספר הצעדים בשחזור שלה: ייתכן שתרצי "לחקור מסביב" לראות אם יש עוד בעיות. מצד שני אם יימצא באג בבדיקות האד הוק, נכניס אותו למערכת ניטור הבאגים כך שיהפוך לבדיקה רגרסיבית לאחר שיתוקן.
שאר הבדיקות הקיימות ממוקמות איפה שהו בין הבדיקות האלה.
אנו בטוחים שבמרבית המקומות ירוויחו מהשילוב בין שתי תורות הבדיקה האלה וזו האופטימיזציה הטובה בין מציאת באגים לרמת האימון במערכת.
הגשר המטפורי
הספקטרום שבין בדיקות רגרסיה לבדיקות אד הוק יכולות להיות מתוארות כגשר וכך יקל עלינו לתאר את המעבר מבדיקות רגרסיה לבדיקות אד הוק. להמחשה יש לראות תמונה בעמ' 4 במאמר.
בדיקות מאולתרות
גישה אחת לבדיקות אד הוק היא לראות בהן אלתור על נושא מסוים. כמו בג'אז כשמתחילים ע"פ תווים בודק יכול להתחיל סבב בבדיקות מסודרות ומתועדות. לאחר מכן נגן הג'אז עובר בד"כ לאילתורים, ולקראת סוף המנגינה הוא חוזר למלודיה המקורית.
דמיון נוסף לג'אז הוא שנגנים מנגנים ביחד, ואז כל אחד מנגן סולו. בצורה מעניינת זה דומה לדרך טובה בה כדאי לבדוק בבדיקות מאולתרות: איסוף של שניים או יותר בודקים מאומנים בחדר ומבקשים מהם לשתף פעולה בנוגע לבדיקות המאולתרות. וזה גם שיתוף ועבודת "סולו". אפשר להתחיל ממסמכים פורמאליים כמסגרת ול"הפליג" משם לבדיקות נוספות. למשל בדיקות של תוכנת עריכת מדיה דמיונית בשם "פנורמה" שמצרפת כמה תמונות לתמונה פנוראמית אחת.
נניח שיש לך סדרת בדיקות מתועדות שיובילו אותך בצורה מסוימת דרך הצעדים הללו:
1. פתח את התוכנה.
2. הטען 8 תמונות שביחד מכסות 360 מעלות.
3. הפעל את הפיצ'ר שמאחד את התמונות.
4. ודא שהתהליך הסתיים ללא שגיאות.
5. ודא שהתמונה אכן מאוחדת ומציגה 360 מעלות.
6. אם חלק מהחיבורים אינו מושלם הפעל פיצ'ר האיחוי הידני.
7. סדר ידנית את האיחוי.
8. הפעל את פיצ'ר האיחוי הסופי.
9. ודא שהתהליך הסתים ללא שגיאות.
10. ודא שהתמונה הפנוראמית נראית טוב.
ברור שבמקרה זה יהיה קשה להפוך את הבדיקה לאוטומאטית. יש כמה תוצאות שנוכל לקבל כ"עוברות" וזה עניין אסתטי. אם נניח שאת מריצה את הבדיקות האלה בצורה ידנית, אילו שינויים בהרצה תוכלי ליישם?
ניתן לראות תבנית בצעדים למעלה: 3 ביצוע ושניים של וידוא וחוזר חלילה. בודקים נופלים לעיתים לתבנית כזו מבלי להבין שזה מצמצם את סוגי הבדיקות שלהם. מכאן שצורת שינוי אחת היא שינוי תבנית. ניתן לעשות זאת המספר דרכים כמו למשל הכנסת צעדים נוספים ל-TC שעשויים לשנות את התוצאות. למשל:
· להריץ את צעד מס' 3 כמה פעמים לפני המעבר לצעד מס' 4.
· להריץ שינויים ידניים קודם ואוטומאטיים אח"כ.
· בין כל שני צעדים לשנות את עומק הצבע ולהחזיר מספר פעמים.
כמו שניתן להבין יש אינסוף אפשרויות. אבל מה שהופך את העניין למומחיות הוא הניסיון לצמצם את צעדי הבדיקות לאלו שיש את מרב הסיכוי למצוא בהם בעיות. כאן הניסיון עושה את כל ההבדל.
טכניקת האלתורים טובה גם בוידוא תיקון של באג. במקום רק לוודא שחזרה על הצעדים אינה מסתימת בשגיאה, הבודק יכול לחקור מסביב לתיקון, להמציא שינויים בצעדי השחזור וכך להעמיק את הוודאות שהבאג תוקן לגמרי. דוגמא לזה יכולה להיות כזו: מצאנו באג בתוכנת המדיה שבכל פעם שאתה מעדכן ידנית את האיחוי כל התמונות מצד שמאל הופכות להיות בלתי-מיושרות. לאחר התיקון אתה מוודא שכל התמונות מצד שמאל נותרות מיושרות. בנוסף אפשר לאלתר עוד כמה בדיקות, למשל וידוא שהתמונות גם מצד ימין נותרות מיושרות. אני חושב שדוגמא זו פשוטה מידי – בכל מקרה הייתי מצפה מהבודק שיבדוק את תסריטי הבדיקה של איחוי ידני בקצרה. אני הייתי מוסיף איחוי, שמירה, רפרוש וכד' – ואז לוודא שכל הצדדים נותרים מיושרים.
אם נחזור למטאפורת הגשר, אלתור בדרכים אלה זו דוגמא לחציית הגשר מהפורמאלי לפחות פורמאלי. בואו נניח שממסמך הבדיקות הקיים את ממציאה 10 וריאציות לTC קיים דרך אלתור. מתוך העשרה, אולי אחד יגלה באג חדש, שמונה יורצו חד-פעמית ואחת את מחליטה להוסיף למסמכי הבדיקה. שני מקרי בדיקה – הבאג וה-TC שנוסף לרגרסיות – את מעבירה בגשר מהפחות פורמאלי לפורמאלי.
כיצד מחליטים איזה סנריו מבדיקות האד-הוק יהפכו לחלק מהרגרסיות? זה מאוד תלוי בהקשר שלך, אך הנה כמה נקודות למחשבה. נניח שכבר הרצת את הבדיקה פעם, והיא עברה. כעת עליך לתת ניחוש מושכל מהו הסיכוי שבאגים חשובים ימצאו בהרצות חוזרות. חלק מנקודות המחשבה האלה הן:
· האם הפיצ'ר הזה ממוקם בחלק בלתי יציב של המערכת?
· האם קל להפוך את הבדיקה לאוטומאטית, כך שיורץ בעלות נמוכה?
· אם הבדיקה תכשל, מה תהיה חומרת הבאג?
מהדיון הזה אפשר ללמוד מהו השוני בין בדיקות מאולתרות לבדיקות אד-הוק "רגילות". בבדיקות אד הוק אין ציפייה לחזור עליהם אלא אם ימצא באג. לעומת זאת בבדיקות מאולתרות אנו מחפשים ממש סנריו שניתן להוסיף לרגרסיות. בשל כך נשים את הבדיקות המאולתרות לאמצע הגשר בין רגרסיות לאד הוק. לדעתי ומהמשך המאמר אין בפועל הבדל בצורת הבדיקה, בצעדים, אלא במטרה.
מתי בדיקות אד הוק אינן מומלצות?
למשל לא ב-acceptance tests או sanity. ככלל: אם יש בדיקות מחזוריות עלינו לתעד אותן ולהפוך אותן לאוטומאטיות.
מקום אחר שאינו מומלץ, זה בזמן של monkey testing בו כל החברה מנסה "לשבור" את המערכת. שלב זה עדיף להיערך בתום הבדיקות, כולל האד הוק, בכדי שלא ימצאו באגים שכבר היה אפשר לגלות אותם.
הכח של בדיקות אד הוק
יתרון חשוב של בדיקות האד הוק הוא הגילוי. קריאת הדרישות רק לעתים נדירות נותנות תחושה טובה של איך המוצר אמור להתנהג. אפילו מסמכי המשתמש לא תמיד נותנים את ההרגשה של הרצת המוצר. בדיקות אד הוק יכולות למלא את החורים במסמכי הבדיקות, ויכולות לחשוף יחסים בין תת-מערכות (subsystems) שאחרת עלולות להיזנח. כאן זה עשוי להיות כלי הבודק את שלמות הבדיקות שלך. בדיקות חסרות יכולות להתווסף לרגרסיות.
גילוי באגים בעת בדיקות אד הוק עלולות להיות סימן שיש סוגים שלמים של בדיקות שלא ביצענו.
שימוש נוסף בבדיקות אד הוק הוא קביעת הדחיפות של שאר הבדיקות. בדוגמא של תוכנת המדיה, אם בבדיקות האד הוק אנו רואים שפיצ'ר מסוים, כמו סידור התמונות, עובד כראוי, אפשר לדחות את הבדיקות הפורמאליות של פיצ'ר זה לסוף, וגם להיפך.
בדיקות האד הוק הן גם דרך יעילה להגדלת כיסוי הקוד. הוספת בדיקות לאלו הפורמליות דורשות מאמץ רב בדיזיין, במימוש הבדיקות ולבסוף בהבנה של שיפור הכיסוי. גישה זורמת יותר כרוכה בשימוש איטרטיבי של בדיקות אד-הוק בכדי להבין אם אנו מוסיפים לכיסוי. אם זה הוסיף את הכיסוי שרצית מן הסתם תרצה להוסיף אותם לבדיקות הפורמאליות. אם לא תבטל אותן כבדיקות חד-פעמיות.
יש שני סוגים כלליים של פונקציות בקוד שיוצרות את רוב התוכנות: פונקציות התומכות בפיצ'ר מסוים, ופונקציות בדרגה נמוכה של תחזוקה (Housekeeping). לבדיקות ה- Housekeeping בדיקות האד הוק טובות במיוחד, כיוון שפונקציות רבות כאן אינן קימות בדרישות או במסמכי משתמש. צוות הבדיקות אולי אפילו אינו מודע להן. להלן כמה שיטות לשימוש באספקט הזה של בדיקות האד הוק.
טכניקות לבדיקות אד הוק
קשה לתאר את התהליך כיוון שהתכונות העיקריות שלו הן חוסר במבנה ברור והחופש לבחור בדרכים אלטרנטיביות. הרבה ממה שבודק מיומן עושה הוא אינטואיטיבי. למרות זאת הנה כמה דרכים לעשות את בדיקות האד הוק אפקטיביות יותר.
התחילי מאזורים שאינם מכוסים היטב במסמכי הבדיקות. לפי מיטב ניסיונו (וניסיוני) מסמכי הבדיקה מכסים פיצ'רים ספציפיים עם פחות ההסתכלות לאינטראקציה בין פיצ'רים. חלק גדול מאינטראקציה זו מתרחשת ברמת ה-subsystems, כיוון שהם תומכים בפיצ'רים רבים. דמייני אינטראקציה פוטנציאלית שעלולה להשתבש, ואז צאי ובדקי את התיאוריה שלך בבדיקות אד הוק. בתוכנת הדוגמא זה יכול להיות בין פיצ'ר האיחוי וייבוא התמונות. האם אפשר לאחות ואז להוסיף תמונות? מה הן כל האפשרויות של האינטראקציה בין שני הפיצ'רים האלה?
לפני תחילת הבדיקות, רשום מה אתה הכי מעוניין ללמוד על התוכנה במהלך הבדיקות. הייה ספציפי – רשום בדיוק מה אתה מתכוון ללמוד וכמה זמן אתה מתכוון לעבוד על זה. אח"כ עשה רשימה קצרה של מה עלול להשתבש ואיך אתה מתכונן למצוא את הדברים האלו.
אח"כ התחל את התוכנה (SUT) ותרגל את הפיצ'רים שאתה מודאג לגביהם. זכור שאתה מעוניין הפעם להבין טוב יותר את התוכנה, לכן טיולים צדדיים לחקירת רוחב ועומק רצויים מאוד.
לדוגמא, נניח שאת רוצה לבדוק את ה-garbage collector (אחראי לניקוי ה-RAM). ממסמכי הדרישות יהיה לך קשה להבין אם יש צורך בבדיקה כזו. למרות שתוכנות רבות משתמשות בשיטה זו זה בד"כ אינו מתועד. בדיקות שיטתיות של ה- garbage collectorדורשים זמן רב. למרות זאת, בבדיקת אד הוק של יום אחד בודק מיומן יכול לוודא אם ה- garbage collector בסדר או שיש בעיות מסוימות או שהוא פשוט עובד גרוע. עם המידע הזה מנהל הבדיקות יכול להחליט על כמות הבדיקות בתחום זה בעתיד. דוגמא לא לגמרי טובה – בד"כ עומסים ימצאו את זה ודווקא בדיקות ידניות לא.
יש מאות של פונקציות תחזוקה מעיין אלה, שבד"כ ממוחזרות לתוכנות חדשות ומועד לטעויות דיזיין ותכנות. אזורים אחרים שכדאי לקחת בחשבון הם:
  • מיונים.
  • חיפושים.
  • Two phase commit (אלגוריתם הנותן כל ה-nodes במערכת מבוזרת הוראה לביצוע טרנסקציה).
  • Hashing . בבילון: פונקציה חד כיוונית (בלתי הפיכה) ההופכת נתוני קלט לקוד מספרי ייחודי (נמצאת בשימוש גם באבטחת מידע כ-"חותמת ספרתית" המזהה את השולח ומאמתת וכן ההודעה).
  • שמירה לדיסק.
  • ניווט תפריטים.
  • ניהול זיכרון.
  • Parsing.
בודק אד הוק טוב צריך להבין את המטרות והדרישות של הדיזיין לפונקציות אלה. אילו בחירות עשה צוות הפיתוח ומה החסרונות שלהן? –כבודקים אנו פחות מודאגים מהבחירות הנכונות של הפיתוח. בדיקות האד הוק יכולות להיות בדיקות קופסה שחורה. אבל זה אומר שעלייך לבדוק את כל תבניות הדיזין בהן השתמשו. עבודה עם הפיתוח בכדי להבין את הבחירות שלהם מביא אותך קרוב יותר לבדיקות קופסא לבנה. זה עוזר לך בצמצום הבדיקות.
קרא את דיווחי הבאגים גם מפרויקטים אחרים. זה אולי יעלה לך רעיונות חדשים לבדיקה.
השתמש בדיבאגרים שונים בכדי לעלות על באגים לא ויזואליים.
מהו המיקום של בדיקות האד הוק במחזור הבדיקה?
לכל האורך. בתחילת הפרויקט זה נותן לבודק הבנה על המוצר (זה בדיוק פרוגרסיה), באמצע הפרויקט זה עוזר לעשות פריוריטיזציה נכונה ולוחות זמנים. קרוב לסוף הפרויקט זה עוזר לבדיקות עמוקות יותר של תיקוני באגים.
האם אפשר להפוך בדיקות אד הוק לאוטומאטיות?
אפשר לקרוא במאמר. בעיקרון – לא.
* עם ההסתייגויות הרגילות: זהו סיכום ולא תרגום, למטרות אישיות, ואינני אחראי למה שכל אחד יעשה איתו.

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