כידוע, באג'ייל אוהבים מוצר עובד על פני מסמכים מקיפים. כהצהרה זה נראה לי די מטומטם למען האמת, כי כל דבר ראוי להתייחסות ספציפית, ולפעמים מסמכים מקיפים הם הכרחיים. למשל אם רובוט מנתח אותך, אני מניח שהיית מעדיף שיהיו לו מסמכים מקיפים שהמפעיל קרא לעומק.
לדעתי אפילו אי-אפשר לומר שמסמך שאיש אינו קורא ואינו מתחזק אינו אלא בזבוז זמן, כיוון לפעמים זה "עושה" סדר למי שכתב אותו. אני זוכר שב"קומברס" מהנדסת המערכת ואני (בגלגולי כמנהל פרוייקט הבדיקות) כתבנו מסמך תכנון בדיקות בן 120 עמודים. לא יודע מי קרא אותו, אבל אני בטוח שרק אחריו באמת הבנתי בצורה מדויקת איך יתנהלו הבדיקות, ואני בטוח שהבדיקות היו טובות יותר אחריו.
בואו ננסה שוב: אם יש מסמכים שלא קוראים אותם ולא באמת עוזרים למי שכתב אותם, אין להם מקום. במקרה הזה באמת עדיף "מוצר עובד על פני מסמכים מקיפים". ואם כן כותבים משהו, כדאי לחשוב קודם על ההצדקה שלו.
יש שאלה אם כדאי לכתוב מסמך תכנון בדיקה בכל גרסה. שאלה לגיטימית ותלוית הקשר. אם מחליטים שלא, עדיין כדאי להוציא מספר מרכיבים ממסמך זה, מרכיבים שבד"כ לא משתנים, למסמך חיצוני. מה שנשאר הוא בעצם אסטרטגיית בדיקות כללית.
מה זה אומר? זה מדבר על התהליכים של הבדיקות, וגם לאן מדווחים ומתי, מהם רבדי הבדיקות וכו'.
האם יש הצדקה למסמך מעיין זה?
אני סבור שכן:
- באג'ייל יש ראש צוות (וצוות) שבד"כ אינו בודק (מה לעשות, לא כולם מושלמים). המסמך הזה "יעשה לו סדר" ויעזור לו להבין מה אנחנו עושים, מה הציפיות שלו מהבדיקות. אולי פתח לדיון.
- שקיפות מול גורמים חיצוניים.
- גם לבודקים זה עשוי לעזור ולמנוע הנחות שגויות של מה הם אמורים או לא אמורים לעשות.
- זה יכול אפילו לשמש כצ'ק ליסט למשל לפני שחרור גרסה.
- מסמך שעוזר לחניכה של בודק חדש.
הייתי רוצה שזה יהיה מסמך שתלוי על קיר כל קבוצת בדיקות, אג'ילית או לו.
מצ"ב הצעה למסמך אסטרטגיית בדיקה. "לפי הספר" אמורים להיות כאן גם קריטריוני האיכות, אבל זה יסבך את המסמך ללא צורך:
https://drive.google.com/file/d/0B1WL1k115uIiSWlJU0tsLURfOTg/view?pli=1
https://drive.google.com/file/d/0B1WL1k115uIiSWlJU0tsLURfOTg/view?pli=1
אין תגובות:
הוסף רשומת תגובה