יום שני, 28 באפריל 2008

שיפור הבדיקות 1: סיכום מאמר

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

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

התהליך מתמקד בבעיות בעלות חומרה רבה, שכילות ויקרות. מטרת אנליזת ה-escape היא:
  • הפרדת ה-escape לתוך קטגוריות בכדי להקל על אנליזת העומק.
  • הרצת סטאטיסטיקות על הקטגוריות הנ"ל.
  • על סמך הסטאטיסטיקות הנ"ל לזהות וליישם שינויים בתהליכים.
  • לזהות וליישם שינויי low level על סמך אנליזה של מקרי escape.
  • לעקוב ולהציג את תוצאות השיפורים.
איך:
יש לעקוב אחר הצעדים הבאים. יש לחזור עליהם בתקופות מוגדרות מראש, למשל פעם בחודש.

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

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

קטגוריזציה של escape
הצעד הראשון בתהליך הוא מיון לקטגוריות מועילות ובעלות משמעות. לצורך כך וכתנאי קודם יש להחזיק רשימה של כמה שיותר מפורטת של הבעיות. אח"כ יש להחליט אילו קטגוריות יהיו המועילות ביותר. לדוגמא:
  • Process step, כלומר היכן שהבאג היה אמור להתגלות:
    בשלבי הפיתוח (מה-review של שלב המרקטינג, של מסמכי הפיתוח, דרך קוד review, דרך ה-Unit test ועוד).
    בשלבי הבדיקות.
  • באילו קומפוננטות התגלו הבעיות.
  • ה-impact של הבעיות במחינת הלקוח (קריסה, בעיות של מידע, עומס, יוזביליות וכו').
  • גרסאות הקוד שבהן היו הבעיות.
  • פלאטפורמה.
  • חומרה.
  • גרסה בה התגלו הבעיות.
לאחר בחירת הקטגוריות יש להריץ סטאטיסטיקות עליהן.

אנליזה - כלי לניטור
יש להשתמש בכלי לניטור ותיעוד האנליזה, כמו lotus notes ואני מוסיף: אקסל כמובן.

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

אנליזה - שינויי היי-לבל בתהליך
על קבוצת אנליזת ה-escape להיפגש בכל פעם שיש אנליזה (כאמור יכול להיות פעם ברבעון) בכדי לדסקס את התוצאות. יש לזהות מגמות ולערוך סיעור מוחות על הממצאים ולמצוא שיפורים בהיי-לבל של תהליכי הפיתוח. לאחר מכן על הקבוצה לתת המלצות פורמליות לשיפורים ולערוך תוכניות לצעדי השיפור. יש לערוך ישיבות קבועות ולעקוב אחרי השינויים. בקיצור, יש לנהל את השינויים כמו ניהול של כל פרוייקט אחר. דוגמא לשינוי היא רכישה של חומרה זהה לזו של הלקוח.
אנליזה - שינויי ה-low level בתהליך
אם עובדים ברמת חברה עם כמה קבוצות, יש לבחור לקבוצת האנליזה נציג מכל קבוצה (קבוצות פיתוח, קבוצות בדיקה, הנדסת מוצר, תשתיות, מהנדס מערכת ועוד). יש להקצות escape לנציג המתאים, למשל escape שקוטלג לתהליך ה-Unit Test צריך להינתן למפתח שעורך UT להמשך האנליזה. על כל נציג קבוצה לקחת על עצמו את ה-escapes מהתחום שלו ולחזור עם הצעות שיפור. אם זה הבדיקות אז עליהם לחזור עם פעולות לשיפור שימנע את הישנות הבעייה ומקרים דומים. על תוכניות הפעולה להיות מלאות, מאושרות ואז מיושמות ויש לעקוב אחרי זה. יש להקצות תוכנית פעולה לכל escape. יש להדגיש שזה לא נועד לפתור באג ספציפי אלא לשפר תהליך. תוכנית השיפורים חייבת להיות כזו לתוריד את האפשרות לבריחת באג מאותו סוג. למשל: הוספת test case. יש לעודד יצירתיות.

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

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

בתמונה 2 ניתן לראות את טאב האנליזה של הפיתוח. יש קטגוריות שונות לקלסיפיקציה של הבאג. בדוגמא הספציפית הבאג "ברח" בשלב של ה-Design Review. בכדי לתקן זאת נוספה פרוצדורה חדשה. ייתכנות התפיסה (Capture Probability) נועדה להעריך את האפקטיביות של הפתרון. האחוז אמור לענות על השאלה: מהי הסבירות שבאג זה היה מתגלה אם היינו מיישמים את הפתרון המוצע כבר אז?
יש גם שדה לקביעת תאריך הסיום.

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

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

מדידות להנעת תהליכים
מדידת סה"כ בתוך כל קטגוריה שקטלגנו במידע ויצירת תרשים שיביא את השינויים לידי ביטוי. בהמשך יש כמה דוגמאות.
תמונה 4 מראה את האחוז מסך כל ה-escapes מכל קומפוננטה של קוד. ברור מצפייה בתרשים שארבע קומפוננטות מרכיבות כ-50% מהבעיות. זה יכול לעזור לקבוצה לגלות שיש לנקוט בצעדים על מנת לשפר את הקומפוננטות הנ"ל.

תמונה 5 היא לפי השפעות על הלקוח כמו קריסה וכד'. שוב יש לפעול לפי סדר של כמותי הבעיות הרבות יותר תחילה בשילוב עם החומרה של הבעיות.

מדידת יעילות של אנליזת ה-escape
מידע מדוייק ודיווח מתמשך הכרחיים למדידת השיפורים.

TFVUD = Total Field Valid Unique Defects
כלומר סך כל הבאגים הואלידיים והסגורים שהתגלו אצל הלקוח.

PDD = Post Development Defect
באגים שהתגלו לאחר הפיתוח אבל לפני השליחה ללקוח.

KLOG = שורות של קוד באלפים.

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

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

ג. ייתכנות התפיסה
למדידה זו יש להשתמש בשדה בעל שם זה הקיים בבסיס הנתונים בטפסי ה-escape. זה יעריך את יעילות השינוי אם נמנע escape של הסוגים הנדונים. אמנם זו רק הערכה, אבל היא יכולה לשמש בסיס טוב להצגת האפקטיביות.
ניתן לסכום את ייתכנות התפיסה ומציאת ממוצע בכדי להבין את היעילות הכללית של קומפוננטה מסויימת, השפעה אצל לקוח וכד'.
כתוצאה ניתן להציג הערכה של ירידה שלבעיות בשטח.
ראו תמונה 6. לקומפוננטה B ייתכנות התפיסה של הפיתוח או הערכת האפקטיביות היא 35%. ייתכנות התפיסה של הבדיקות ל-B היא 30%. כלומר אם היו לפיתוח 100 באגים הם ימצאו 35 מתוכם. זה יותיר 65 באגים לבדיקות. אם הבדיקות ייתפסו 30% מהבאגים, כלומר 19.5, זה ס"כ הבאגים שיתגלו יהיה 35 + 19.5 שהם 55 APARים או 55% מהמאה המקוריים. 55% אלו נקראים בשם "יעילות משותפת". הנוסחה של זה נראית כך:
D = ייתכנות התפיסה של הפיתוח
T = ייתכנות התפיסה של הבדיקות
(D+(1-D)(T
המקרה שלנו:
0.35+(1-0.35)(0.30)
דוגמא זו מבוססת על קומפוננטות, אך יכולה לחול על מאפיינים אחרים גם כן - ראו תמונה 7.

הצעד האחרון הוא לשקף את הכמות שבה ניתן להוריד את הבאגים אצל הלקוח. זה נעשה ע"י סכימה ועריכת ממוצעים של ערכי היעילות משותפת. תחילה יש לבחור קבוצה של escapes שיהיו קבוצת הפוקוס של היעילות משותפת. בדוגמא הזו קבוצת הפוקוס תכלול 76 escapes. אם ערך היעילות המשותפת של 76 באגים אלה תסוכם ויעשו לה ממוצעים לדוגמא מציור 7, התוצאה תהיה 52.5% יעילות ל-76 באגים, כלומר 40 escapes שלא יגיעו ללקוח. כלומר אם היו 250 escape בשנה 16% ימנעו.

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

יום רביעי, 23 באפריל 2008

דוח בדיקות יומי

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

איך הדוח צריך להראות:

דוח מצב של <מוצר> <גרסה> מיום dd/mm/yy

חלק ראשון: קיצור מנהלים.

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

הקטגוריות של הרמזור:
  1. לוחות זמנים: אדום/כתום/ירוק. אם אדום או כתום: הסבר קצר.
  2. איכות: אדום/כתום/ירוק. אם אדום או כתום: הסבר קצר.
  3. כח אדם: אדום/כתום/ירוק. אם אדום או כתום: הסבר קצר.
  4. חומרה: אדום/כתום/ירוק. אם אדום או כתום: הסבר קצר.

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

מצב נכון לכרגע:
build X בחדר הבדיקות.
תאריך ה-build הבא:
תאריך מעודכן של ה-build הבא:
תאריך סיום מקורי של סיום בדיקות העומס/מערכת...
תאריך סיום עדכני של סיום בדיקות העומס/מערכת...

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


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

יום שני, 21 באפריל 2008

Software Test Plan

ה-STP הוא מסמך תכנון הבדיקות. הוא צריך להיות סגור ברגע שיש תכולה ברורה ולוחות זמנים, ואמור להיות מתוחזק במשך כל זמן חיי הגרסה.
דבר אחד שלמדתי הוא: שאם אתה לא יודע איך למלא אותו, או שאתה לא סגור על המסמך, זה אומר רק דבר אחד: אתה לא סגור לגבי הבדיקות של הגרסה!
פתגם אפריקאי עתיק אומר שתכנון מציל מברבור
ממה מורכב ה-STP?
הערה: אני לא מתכוון להכנס לתהליכי כתיבת מסמך בכלל (רשימת שינויים, Reference וכו').
דבר אחר: כיוון שה-STP אמור להיות מתוחזק, אני מאוד ממליץ להוציא ממנו את הדברים שאמורים להשתנות (כמו למשל רשימת הריסקים) לקבצים חיצוניים והשארת לינק. את הקבצים החיצוניים אפשר לאחד ולהשתמש כחלק מדוח שבועי.
הסדר כראות עינכם.
וכמו כל דבר, ייתכן שבכל חברה יש דגשים אחרים. יש לראות אם ומה חסר או מיותר כאן.
  1. על המסמך עצמו: הסבר לגבי מהו מסמך זה, למה הוא מיועד, מה הוא אמור להכיל. זה ברמה גבוהה (high level) ויכול להכלל בתבנית.
  2. תיאור המערכת כפי שהיא קיימת היום.
  3. מבט על הגרסה הספציפית: האם היא גרסה ראשית, מה ברמה גבוהה התכולה העיקרית שלה, מי הם הלקוחות שלה, הבעיות העיקריות שלה (שינויי פלאטפורמה, זמנים קצרים במיוחד), ואיך אנו מתכוונים לפתור אותם. האם אנו משנים שיטה בבדיקות וכו'. מעיין תקציר של דברים שממליא יופיע אח"כ.
  4. רשימת הנושאים הפתוחים. מומלץ שזה יהיה לינק לאקסל. זה צריך לכלול את כל הנושאים הפתוחים, לפי העמודות האלה:
    מספר, קיצור, פירוט, שייכות (בדיקות עומס, מעבדה וכו'), אחראי, פריוריטי, תאריך סגירה מצופה, סטאטוס (בטיפול, טרם טיפול, טופל). אם שולחים את זה כדוח שבועי, אפשר להוסיף עמודה פנימי / חיצוני, כלומר אם זה פנימי לבדיקות ולא תריך לעניין גורמים חיצוניים, ואז להשתמש בזה כפילטר.
  5. אסטרטגיית הבדיקות:
    מה מטרת הבדיקות (לכסות את כל הדרישות וכד').
    שלבי הבדיקות: בדיקות מערכת, בדיקות עומסים וכד'.
    איך נקבע סדר הבדיקות.
    ועוד.
  6. כמות כ"א בהתאם לשלבי הבדיקה.
  7. מה לא יכלל בבדיקות. לא פחות חשוב. אם יש דברים שלא יכללו אבל ייבדקו ע"י גורמים חיצוניים - יש לציין ולתאם.
  8. סיכונים. קישור למסמך חיצוני. כתבתי על כך בעבר.
  9. המדידות שאנו מתכוונים לקיים. כתבתי על כך בעבר.
  10. לוחות זמנים. גם מסמך חיצוני, כלל ציוני דרך. לא חייב פירוט של גאנט, אפשר תחילה וסיום כל כל פיצ'ר, של רגרסיות וכד'. זה נועד לתת תמונת "על" בכדי להבין אם יש בעייה. סיום של פרוגרסיה יום לפני סיום הגרסה = בעייה.
  11. קישור לגאנט.
  12. רשימת הנפשות הפועלות בגרסה. תפקידים עיקריים.
  13. רשימת אינטרפייסים (מחלקות אחרות וכד').
  14. פירוט החניכות שיש לעשות לצוות הבדיקות לקראת הגרסה.
  15. חומרה ותוכנה שנזדקק להם.
  16. ניהול הגרסה מבחינת הבדיקות:
    אילו דוחות יונפקו, רשימת תפוצה ותדירותם.
    אילו ישיבות סטטוס יתקיימו, משתתפים ותדירותם.
  17. מסמכי הבדיקות והאחריות שלהם (ברמת תכנון, צ'ק ליסטים, דוחות).
  18. באגים:
    צפי של מספר באגים לגרסה מול פיצ'רים. יש להבין כמה צפויים, וכמה זמן לסגור אותם, ולהתחשב בזמן זה בתכנון הבדיקות.
    ניהול של הבאגים: מי מחליט מה יתוקן, תהליכים וכד'.
  19. טבלת כיסוי (Traceability Matrix).
  20. מטרות האיכות (למשל שהגרסה תצא עם 0 באגים של התקנה).
  21. צלילה לסוגי הבדיקות (למשל בדיקות פונקציונליות, ATP, עומס ועוד):
    איך נבדוק (תצורה כמערכות הפעלה ועוד ולפי איזו אסטרטגיה - למשל לפי כמות רוב משתמשי המערכת, באילו builds וכד').
    רשימת הרגרסיות.
    לוחות זמנים של הסוג הספציפי.
    האנשים שישתתפו (כולם).
    כלי הבדיקה.
    קונפיגורציית מעבדה.
    דרישות חומרה, רשת.
    מסמכים (כל מסמך בדיקות + תאריכים).
    תנאי כניסה לחדר בדיקות ותנאי יציאה.

יום שלישי, 15 באפריל 2008

מדידות עיקריות בניהול בדיקות תוכנה

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

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

אלו המדדים שאחריהם לדעתי חשוב לעקוב בקשר לבדיקות:
1. כיסוי הדרישות מול test case.
כמה דרישות מכוסות ב-test cases, וכמה לא, כמה test cases לדרישה (1 - לא הגיוני, גם 100 לא).

2. כיסוי test case מול הרצות.
במדידה #1 לעיל הזכרתי דרישות מול מסמכים. מדידה זו, #2, היא של מסמכים מול ההרצות בפועל.

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

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

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

תוספת לסעיף 4 בעקבות קריאת המאמר למטה:

אפשר לבנות את הגראף כך:
קו של תכנון מספר ה-TC פר יום / שבוע
TC שנבדקו בפועל
TC שעברו.
אם התכנון הוא על כמה TC יעברו, נניח 50, ואמנם בדקנו אפילו 55 אבל רק 45 עברו - אנו בבעייה.


5. התקדמות בבדיקות.
פרוגרסיות ברמת test case מתוכנן מול מצב בפועל
רגרסיות ברמת test case מתוכנן מול מצב בפועל
כנ"ל לגבי sanity, ATP ומה שלא יהיה שמתוכנן.

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

7. מספר באגים אל מול test case.
יעילות ה-test case.
בטווח הארוך אולי אפשר לוותר על בדיקות מסויימות או לקצר אותו, אולי לשפר אותו.

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

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

10. מספר הבאגים אל מול מספר דיווחי הבעיות מהשטח + באגים שהיו קיימים בגרסאות קודמות.
יעילות של בודקים.

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

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

13. כמות ה-rejected bugs.
לא "עליהום" אלא להבין למה. אם בגלל טעויות של בודקים - לשפר להם את הידע הטכני והקשור לבדיקות. אולי הדרישות אינן טובות דיין.

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

15. באגים לפי ההשפעה שלהם.
פונקציונלי, התקנה ועוד.

16. באגים לפי אפליקציה / שרת.

עוד חומר אפשר למצוא כאן (תודה לדנית):
S. H. Kan, J. Parrish, and D. Manlove, In-process metrics for software testing

יום רביעי, 9 באפריל 2008

סיבה ורעיונות לקידום מהנדסי בדיקות

הרשומה נועדה למנהל אך גם לבודק שמעוניין להתקדם.
הכוונה כאן היא לא לקידום למשרת ראש צוות, הליך פורמלי לכאורה, אלא קידום מקצועי. לקידום זה מספר מטרות:
  1. לקדם נושא בעייתי בקבוצת הבדיקות כמו שיפור תהליך לא תקין, מדידות חסרות, חוסר תקשורת עם ממשקים חיצוניים ועוד.
  2. לתת לבודקים מן השורה אחריות נוספת, דבר שיגרום להם ליתר גאווה ולסטטוס מיוחד בקרב חבריהם, ימקצע אותם ויתן להם עניין נוסף המקום עבודתם.
  3. כמנהל, נותן לי עוד נקודת ראייה לגבי מי משתדל יותר, מגדיל ראש, ומי בעל יכילות מקצועיות או ניהוליות טובות - לפי ניהולו את המשימה שלו.
  4. אפילו יש לבודקת מסויימת פוטנציאל לניהול צוות, "להפיל" אותה ללא הכנה אינו מתכון טוב לאף אחד מהצדדים. להתחיל לחלק לה משימות זהו רעיון טוב יותר. ברור שיש לעזור לה בניהול המשימות ולהכין אותה לתפקיד ניהולי.
הסוגים של הגדלת האחריות הכללית או המקצועית:
  1. אחראי תחום טכני. הכוונה או לטכנולוגיה מסויימת: למשל מומחה ללינוקס, לתצורה של מערכת וידאו, מומחה לרשת. או: מומחה לפיצ'ר או שרת מסוימים במערכת, מציאת ובדיקת טכנולוגיות חדשות (כלים אוטומטיים חדשים או חידושים בכלים הקיימים, add ons שיכולים לעזור ועוד). לא תמיד מומחה שבא מתוך תחום הבדיקות יהיה מומחה לרשתות, אבל הוא יהיה זה בעל הידע הגדול יותר אליו פונים לפני הפנייה למומחי הרשתות. דבר זה גם יגרום לגדילת ההערכה לקבוצת הבדיקות שתוצג כמקצועית שיכולה לטפל ברוב הבעיות לבד ולא פונה על כל בעיונת למומחים. ברור שיש לספק לאחראי את הכלים המתאימים: קורס, ספרות מקצועית וכד'.
    יש למפות את רשימת המומחים ולספק את המידע לכל קבוצת הבדיקות, כך שכל אחד ידע לאן לגשת במקרה של בעייה.
  2. טיפול בתחום הלוקה בחסר, למשל: מעקב וניתוח של באגים הבאים מהשטח, ממשק לקבוצות אחרות כמו קבוצת הבדיקות הפרוייקטליות, מדידות מסויימות, בעיות בניהול מידע, פורום של שיפור מחזור חיי הבאג, אפילו הכנת יום הכיף הקרוב.
בעיקרון, הרעיון אינו בהטלת משימה נוספת על הבודקים, אלא משהו שבא מהם ונועד לקדם אותם אישית, מול חבריהם ומול ההנהלה. אם זה מוסיף להם 10%-20% לעבודה לדעתי אין להוריד מהם חלק מהתפקוד הנוכחי שלהם. זה האינטרס שלהם לקחת פיקוד על נושא מסויים. מצד שני אם זה לוקח 50% משרה, יש להוריד מהם חלק מלחץ הבדיקות הקיים, ולתמרן.
בנוסף אין להתיל "להפיל" על בודקים ב"כח" מטלות כאלה. אם בודק הוא בודק טוב שאינו מעוניין בעוד אחריות אך עושה את תפקידו נאמנה - זה מספיק, וגם כאלה אין הרבה. מצד שני, איך אומרים בפרסומת? זה טוב, אבל לא מצויין.

צ'ק ליסט לכתיבת מסמך בדיקות (STD Checklist)

הרשימה הסופית כוללת תוספות רבות של קובי הלפרין כפי שהופיעו כאן.
Preparations and format:
01. Were all the requirements identified and listed while preparing the TD?
02. Does the traceability matrix exist as a part of the document or referenced from the TD?
03. Is every requirement covered by at least one test group in the TD?
04. Was the TD written in accordance with the template?
05. Was the TD written in accordance with the guidelines in the Test Approach document?
06. Are all the test groups and test cases uniquely identified?
07. Is the naming convention used consistent throughout the document?
08. Was the Doc Revision Change Control filled properly?
09. Are the Testing Gear properly identified?
a. Tool specifications.
b. Scripts and debug tools.
c. Information that should be found in logs.
10. Are some of the tests defined as being done not in a clean environmet to identify integration and other parts influances?
11. Are all related documents mentioned and linked?
12. Are there Definitions & Abbreviations to all the terminology in the document?
13. Are all the topics that will be tested and will not be tested defined in the document?
14. Is there any reference to documantation tests (Help windows, User Manual & Installation Manual)?
15. Are there any TBD issues?
16. Was the Speller run? Were all needed updated values updated (e.g. TOC)?
17. Does the document include diversity (users, ports, slots etc)?

Test groups:
18. Were all the test groups and test cases defined in accordance with system impacts (Installability, Integrity, Security, Performance, Maintainabilility, Serviceability, Update/Migration, Documentation, Usability, Standards, Reliability, Requirements, Capability?)
19. Were all the test groups and test cases defined in accordance with triggers (Functional, Startup/Restart, Recovery/Exception, Redundancy Failover, Hardware configuration, Software configuration?)
20. Does every test group contain at least one test case?
21. Does each test group test one specific requirement?
22. Is every test group verified under different conditions/inputs/scenarios?
23. Is the testing method described clearly for each test group (to the level that will enable the reviewer to understand how the test cases will be executed and how the results will be evaluated?)

24. Does the test method for each test group include criteria for
evaluating tests results?
Test Cases:
25. Are the test cases classified according to applicable test types (Positive Test Case, Negative Test Case - about 30%, Boundaries Test Case, End Cases)?
26. Are there tast cases designed to detect problems between the tested feature and other features / sub-systems of the system?
27. Does each test case include the purpose of the test?
28. Are the test cases for the same test group testing the same requirement under different conditions?
29. Are the test groups and test cases designed in bug revealing orientation (we are testing in order to find bugs and not to show that it works?)
30. Do the tests cases have priority based on the product (e.g. complexity) and version (e.g. feature X as milestome for a customer)?
31. Do the test groups include separate test cases for positive, negative, boundary checks?
32. Do the test groups include separate test cases for end cases?
a. Were test cases with
special input values (empty file, empty message, etc) defined?
b. Were test cases defined for testing functionality under
abnormal conditions (no communication between two components, temporarily no connection to data base, etc)?
c. Were test cases with
illegal input values defined?
33. Were complicated and not only trivial scenarios defined for test case execution (for example, several users performing actions or contradictory actions, like one user deposing a message, while the subscriber is deleted, or depositing a message while another message is deposit and causes exceeding the message quota)?
34. Are the test objectives described clearly for each test group?
35. Was test results evaluation defined (at least considered) by more than one method (for example, visual observation of user’s handset, activity log record and relevant log file record?)
36. Does every test case have preparations and setup (either stated implicitly or referenced to the test group or whole TD preparations and setup?)
37. Are issues of error handling addressed?
38. Were test cases with default input values defined?
39. Was test cases dependency eliminated (can each test case run independently and not dependent of execution of other test cases)?
40. For test cases that have specific preparations and setup, was a return to initial conditions defined upon end of execution (to eliminate dependency)?
41. Were test cases defined in order to check data integrity (data loss in case of errors, failures?)
42. Were test cases defined in order to check data consistency (in case of flow errors, for example?)
43. Were test cases defined to check rollback in case of flow error?
44. Were test groups and test cases that are relevant only for specific version identified and marked as such (the idea is to have one TD for a sub-system/service/feature for all versions and test cases that are not relevant for this version can be easily identified and not executed?)
45. Are the expected test results for each test case specific and unambiguous (you understand exactly what to expect from the test results and if everything works correct, you will always expect the same results?)
46. Where we use the same set of steps (e.g. checking text fields): is it written only once with reference?
47. Where we use the same set of parameters (e.g. checking configuration files): is it written only once with reference?
48. Do all test cases include running time estimation (before the first run it is a ragh estimation, will be updated if needed after the first run)?

Test Steps:
49. Are the actions (steps) in the test procedure specific and unambiguous?
50. Do the steps include only relevant actions for test execution and are not mixed with test preparations and setup?
51. Are the test procedures brief (5-10 steps. If not, you are probably testing several things at once?)
52. Wherever a range of values (including in the test gear) can be used - is it included in the tests?

יום שלישי, 8 באפריל 2008

נקודות להכנת מסמך בדיקות גנרי לאתרי אינטרנט

רוב המידע והרעיון הגיע מכאן.

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


חלון עצמו וגרפיקה נטו:
  • בדיקה של מערכות הפעלה, דפדפנים ורזולוציות מגוונים. כדאי להשיג מידע על התצורות היותר פופולריות.
  • לשחק עם גודל ומיקום החלון, הצגה במוד מסך מלא F11.
  • בדיקה של גדלי חלון שונים (במיוחד ברזולוציות גבוהות יותר) כשהמשתמש אינו במסך מלא.
  • פתיחת מספר חלונות וטאבים במקביל.
  • כותרת חלון הדפדפן / Tabים.
  • רענון הדף.
  • תאמה מדוייקת לסקיצות – פונטים, גודל, צבע, מיקום.
  • הדפסת דף.
  • בהוספה ל-Favorites לוודא כותרת המסמך כראוי.
  • מראה בשיטות encoding שונות.
  • לבדוק כשהדפדפן משתמש בהגדרות אחרות מברירת המחדל (גודל פונט, cache, קוקיס מכובים , sidebar פתוח, סרגלי כלים נוספים מותקנים וכו').
  • הצגת שעה / תאריך - ומבנה תאריך.

Usability:
  • דפדוף אחורה וקדימה באמצעות העכבר או Back-Space (ביציאה מ- session של משתמש מזוהה לא תתאפשר חזרה).
  • קישוריות – פתיחה של הקישור הנכון, חלון חדש או נוכחי, שדה שלא הוגדר כקישור לא יהווה קישור.
  • תיבות בחירה – התוכן מוצג ברצף הגיוני שמאפשר התמצאות (א"ב, סמנטי, או כל הגיון אחר, רק לא אקראי!).
  • פעולות עם העכבר:
    מעבר על קישור ישנה את צלמית הסמן בהתאם.
    לחיצה והזזה תביא לסימון הטקסט.
    במעבר על תיבת טקסט צלמית הסמן תשתנה.
    מופיע Alt-Text במעבר על תמונות, קישורים וכד'.
  • לבדוק התנהגות פירסומות - שמציקות במידה הנדרשת ולא חוסמות הגולשים.
  • לוודא בין הדפים השונים - Same Look & Feel (מיקום אחיד יחסית של תפריטים, כפתורים וכד').
  • אם האתר שולח מיילים למשתמשים: לוודא שלמשתמש קל להסיר את עצמו. לוודא שהדואר מגיע כמו שצריך ומוצג כמו שצריך ב-clients פופולריים (גם web based וגם תוכנות דסקטופ).
  • שינוי צבע הקישור לאחר ביקור בדף.
  • ניווט באמצעות המקלדת – ניתן לעבור מקישור לקישור בדף עם טאבים וחיצים ברצף הגיוני.
  • שימוש במקשי קיצורים.
  • מיקום סרגל הגלילה האנכי והתחתון.
  • עזרה נגישה.
  • הצגה דרך רשת איטית והצגה בסלולרי / PDA
  • גודל הדף - שלא יהיה כבד מידי (20k זה אידיאלי, אבל לא יותר מ-100k).

פונקציונליות בסיסית:
  • מומלץ להוסיף ולמחוק פריטים ולוודא שהם מוצגים / לא מוצגים בהתאם בתיבות.
  • תיבות טקסט – לנסות להציף עם כמות גדולה של תוים (כאלף ומעלה), תוים מיוחדים כגון גרש ותוי פעולות וכד'.
  • שדות חובה במקרה של טופס לשימוש הגולש – מסומנים (בכוכבית אדומה, למשל).
  • שמירת דף.
  • לשחק עם האפשרויות בתפריטי הדפדפן ולוודא תפקוד סביר.
  • לבדוק התנהגות RSS וחדשות רצות.
  • האם האתר יוצר קישורים מטקסט המוכנס ע"י משתמשים? אם כן- לוודא עם פרוטוקולים שונים מ-http, כגון קישורי ftp או https, לוודא עם קישורים המכילים תווים מיוחדים (למשל פסיקים כמו שיש ב-urlים באתר ynet) או תווים עבריים (למשל קישורים לדפי ויקיפדיה העברית)- לוודא שלא נעשה escaping כפול!
  • התייחסות נכונה לשעות באתרים בינלאומיים - שזה מציג את הזמן שלי לפי זמן מחשב או זיהוי IP ולא זמן שרת.

עריכה בסיסית:
  • עריכת תוכן – לוודא שכל השדות הניתנים לעדכון מתעדכנים ונשמרים כראוי.
  • יישור טקסט לימין / שמאל בהתאם לקונטקסט. במיוחד: תצוגת מספרים + עברית + אנגלית מעורב – לוודא שלא משתבש בתצוגה לגולש.
  • בטקסט קבוע (לא פתוח לעורך התוכן) – לוודא שאין שגיאות כתיב.
  • האם האתר אמור לתמוך בשפות נוספות מלבד אנגלית ועברית? מה קורה עם קלט בשפות אחרות (למשל בתגובות משתמשים) כגון רוסית?
כללי:
  • כל מה שקשור לטיפול בשגיאות- לוודא שהן אכן נתפסות, שמועברת הודעה ידידותית למשתמש, ושלא נאבד מידע (למשל במילוי שגוי של טופס, שלא יתאפס כל הטופס).
  • בדיקת דף HTML עצמו, לראות שהוא ידידותי לגוגל (key words, description ועוד), שאין מידע שלא אמור להיות, יש סגירה של תאגים ועוד..
  • שהעלייה של הדף לא תותנה בקישורים חיצניים.
עוד חומר מעניין ניתן למצוא כאן.

יום שבת, 5 באפריל 2008

טרייסביליות

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

אביא כאן את העיקר:
  1. כל הדרישות חייבות לבוא משלב ה-MRD עם סעיפים, סעיף פר דרישה, ת-סעיף לתת-דרישה, וכל סעיף צריך להיות עם סמן ייחודי (נניח MRD-403-24-001, MRD זה המסמך, 403 זו הגרסה, 24 הסעיף ו-01 הוא תת-הסעיף). מומלץ לקפוץ בין מספרים בהפרש מסויים, למשל מ-01 ל-05, למקרה שמשהו ישכח.
  2. יש למפות כל דרישת השיווק (MRD) לדרישה של מהנדס המערכת (SysRD). לכן דרישות המערעת אמורות להיות:
    SysRD-403-24-01 בהתאמה. אם יש יותר סעיפים כאן אפשר להוסיף בסוף a, b וכד'.
  3. יש למפות כל דרישת מהנדס מערכת לדרישה של הפיתוח. שוב - אותו פורמט של מספרים.
  4. יש למפות כל דרישת מהנדס מערכת לדרישה של בדיקות. שוב - אותו פורמט של מספרים.
  5. מסמך הבדיקות יכלול קישור גם למהנדס המערכת וגם למסמכי הפיתוח.
  6. יש למפות את הבאגים למסמך הבדיקות.
מה יוצא לנו מזה?
  1. שום דרישה לאורך התהליך אינה הולכת לאיבוד.
  2. יש סטטוס עדכני לכל דרישה (בעיקר אם יש כלים שמגבים את זה): כמה באגים פתוחים, מה החומרה שלהם וכד'.
  3. אפשר לראות פר דרישה כמה באגים היו בה, האם זמני הבדיקות היו כפי שציפינו.
  4. יהיה אפשר לדעת בעתיד מה מצב כל דרישה (למסמך סיכום הבדיקות, או חקירה מהשטח).

יום חמישי, 3 באפריל 2008

מה מנהלים אוהבים?

קצת לצאת מענייני בדיקות פרופר.
מה שאכתוב נכון לדעתי בין אם אתה בתפקיד "זוטר" (במרכאות כי בתחום יחסית אין הרבה תפקידים זוטרים באמת) ובין אם אתה בתפקיד בכיר יותר. אלו הנחיות כלליות כמובן וכללי אצבע, ולכן לא תמיד נכונים וכמו תמיד, הכל במידה ובהתאם לנסיבות.
  1. כשיש בעייה: אתה יכול להתייעץ איתו, אפילו זה טוב - תגרום לו להרגיש נחוץ. אבל: לעולם אל תבוא למנהל שלך עם בעייה ללא הצעה לפתרון. תתייעץ איתו אם נראה לו, תתכננו איך להמשיך מכאן. אבל תמיד תבוא עם איזו שהיא הצעה.
  2. כשהיו שואלים אותי: אנחנו נגמור בזמן, למשל, הייתי אומר שאני מקווה שכן. זו תשובה נכונה כיוון שכידוע יש אינסוף סיבות שרובן אינן תלויות בך שאנו עלולים לאחר.
    אמרתי תשובה נכונה, אבל האם היא הנכונה לענות בה? ברור שלא. המנהל רוצה לשמוע תשובה אחת: כן, נגמור בזמן. גם הלקוח, אגב. אני לא אומר שאם יש לך צפי לבעייה קונקרטית תסתיר את זה. אבל כשהמנהל שואל שאלה כמו: האם נסיים בזמן, הכוונה היא: האם לפי מה שנראה כרגע אם הכל ילך יחסית חלק נגמור בזמן? יש לזה רק תשובה אחת: כן, נסיים בזמן. אח"כ אם וכאשר יהיו בעיות תעלה אותם. אף אחד לא יאמר לך "למה אמרת שנסיים בזמן" אם צצה בעייה לא צפוייה.
  3. אל תחשוש לתאם ציפיות. יכול להיות שאתה חושב ואלי עושה את התפקיד מצויין אבל למנהל חשוב משהו אחר שנראה לך בעל חשיבות פחותה. שב איתו, ותראה מהם הקריטריונים להצלחה בהם הוא שופט אותך.
  4. שלוט בכל האינפורמציה . תמיד תהייה מוכן כמו לפני מבחן. המנהל עשוי לקרוא לך לפתע לישיבה ולהתחיל לתחקר אותך בנושא א', ב' או ג'. תמיד תהייה מוכן עם מידע ופעולות מתוכננות.
  5. העבר אינפורמציה. אפילו אם המנהל שלך לא דורש את זה, שב איתו ועדכן אותו. שלא יצא מצב שישאלו אותו והא לא ידע לענות. זכור: גם אתה תצא מופסד, א. ממנהל מעוצבן שיפנה את זה אילך. ב. הוא מייצג את המחלקה שלך ואם הוא נראה רע - גם אתה תראה כך. אין כמו דוחות קבועים וברורים.
  6. הייה מדוייק ככל האפשר בענייני חלוקת תפקידים ומשימות. יש מנהלים שלא יאמרו לך: ה-open issue הזה עליך אנא תפתור על מחרותיים. ואז לא תמיד תדע אם הוא מצפה ממך או מאחר. אני יודע שהכי נח לא לשאול, אבל אח"כ אתה עלול למצוא את עצמך על כסא הנאשמים, לפעמים בלי שתדע כלל שהמשימה הייתה עליך.
  7. אחריות. אני מאלה שחושבים שתמיד אפשר לשפר. גם אם קורה משהו שלא הייתה לך לגמרי שליטה עליו, אפשר ללמוד ולהשתפר. למשל, עם נסעת בכביש ומישהו לא ציית ל"עצור" ופגע בך. ברור שהוא אשם, וכך יש להתייחס אליו. יחד עם זה, כשראית שהוא בא במהירות אולי היית צריך להאט ולהבין קושם מה קורה שם.
    לכן, כשטעית, קח אחריות, אבל לא "אני לא הייתי בסדר" אלא: למדתי את המקרה, ומעתה אנקוט בצעדים אלה: א', ב' וג' בכדי שהמקרה לא ישנה." ואם האחריות אינה שלך במלוא מובן המלה (הייתה לך זכות קדימה, לפי המשל שלנו) אל תיקח אחריות! אתה יכול וצריך לחשוב (עדיף לא לומר) איך לנקוט צעדים בכדי להבטיח את עצמך ממקרה דומה בעתיד, אם אפשר, אבל זה צריך להיות ברור שזה לא באחריותך. באחריותך להסביר למנהל ולודא שהוא השתכנע.
  8. תחניף לו מידי פעם. תאמר בישיבות (שהוא משתתף בהן) שההחלטה הסטופית היא של המנהל שלך, שהצלחת תודות לעמידה בקווים המנחים שלו וכו'. לא - לא מתבייש לומר זאת!

יום שלישי, 1 באפריל 2008

ניהול סיכוני גרסה

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

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

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

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

אבל אנחנו לא חיים בעולם כזה. כיוון שכך, עלינו להערך גם לדברים שעלולים להתרחש.

ניהול סיכונים הוא תמיד על פריטים (items) שליליים שיש סוכוי שיקרו אך אין וודאות לכך.

ברגע שסיכון הופך לבעייה אמיתית הוא עובר מ"ריסק" ל-open issue.

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

איך נראה כזה מסמך?
אקסל תמיד עדיף, המספרים להלן הם שמות העמודים, ה-columns

1. ה-ID של הסיכון. כאן אתם יכולים להתפרע :-)
-----------------------------------------

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

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

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

לאחר מכן מכפילים את התוצאה ויש לנו את עצמת הסיכון.
5. עצמת הסיכון.

-----------------------------------------
מה עושים?

צריך תוכנית פעולה למניעת התממשותו של הסיכון, לשון אחר:
6. Mitigation

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

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

-----------------------------------------

ובכל זאת זה קרה?
7. Contingency plan
או fallback plan.

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

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

8. Due date לישיבת מעקב אחר הנושא.
נראה ברור מאיליו.
-----------------------------------------

9. Due date שאחריו ברור שיש לנקוט אמצעים בפועל (כלומר ה-mitigations לא עזרו)
לפעמים באותו רגע אנו נוטים לומר "טוב אולי באמת זה יסתדר מחר כמו שהם מבטיחים" או ש"אולי הם יצליחו להפעיל את המעבדה". זהו זה: הגענו, לא קרה כלום: מפעילים את ה-contingency plan.
-----------------------------------------

10. אחראי.זה החלק הכי חשוב אולי. אם אין אחראי לא יקרה כלום.
-----------------------------------------

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

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