אני עומד לתאר / להציע תהליך המתאים לסביבה מורכבת או למוצר מורכב או למוצר עם סובלנות מועטה לטעויות (רפואי, צבאי) או כזה שחייב לשמור מסמכים (איזו או סוג ביקורת אחרת). אבל כל אחר רשאי כמובן לגזור את מה שמתאים לסביבתו. בסביבת אג'ייל למשל מעדיפים את השיחה על פני המסמכים. לכן, בסביבה אג'ילית ניתן להתעלם מראשי התיבות שלמטה של שמות המסמכים, ובכל מקום שכתוב "לקרוא" החליפו ב"לשוחח" וכד'. במקרה הטוב ה-product owner יושב בחדר של צוות האג'ייל, במקרה הפחות טוב פשוט ניגשים אליו משוחחים. ואילו המפתחים כן נמצאים בחדר וגם הם צריכים להבין שמחובתם גם ליזום שיחות אתנו ברגע שהם מפתחים משהו שלא דיברנו עלייו או בצורה שונה, או כשיש להם תובנה בנוגע לבדיקות.
שלב ראשון: קריאת המסמכים הרלוונטיים. הקריאה צריכה להיות ביקורתית ולאתר טעויות. מניסיוני, רוב האנשים לא עושים את זה כמו שצריך. הקטע הביקורתי נקרא לפעמים static testing.
יש לקרוא את כל המסמכים כולל של השיווק (בכדי לראות שיש איזה שהוא דמיון לתוצאות), SysRS, SRS וכד', תכתובות במייל ועוד.
קריאת המסמכים צריכה להיות אקטיבית, ולא פאסיבית (פאסיבית במובן של לההשקיע אנרגיה בהבנה בלבד).
בזמן הקריאה יש לחשוב, מול כל דרישה / סעיף בדיזיין, על הדברים הבאים:
1. האם הדרישה כתובה בצורה ברורה? אם אתם מוצאים את עצמכם משלימים נקודות מתוך הנחות שאתם עושים, אולי זה כיף אבל assumption is the mother of all fuckups. אל תתביישו, תשאלו. סביר להניח שחלק גדול מהאנשים גם לא הבינו ואולי התביישו לשאול, או גרוע יותר , הניחו הנחות.
2. מה הסיבה / המוטיבציה לדרישה? האם הדרישה עונה עליה?
3. אם כבר אז ולידציה: בדיקה שהמוצר אכן תואם את ציפיות הלקוח ושהדרישות היו נכונות מלכתחילה.
4. האם יש user stories ברמה הנאותה?
5. האם יש case studies אם רלוונטי?
6. האם דרישה זו מסתדרת יפה עם המוצר הקיים? עם דרישות נוספות?
7. כלומר מישהו יכול לחשוב על פיצ'ר מדהים שבאופן עצמאי יעבוד מצויין, אבל זה לא מסתדר עם המוצר כפי שהוא היום. דוגמא? יש לך אתר קניות והדרישה היא להקל על תהליך הרכישה דרך העברה בנקאית. דא עקה שהאפשרות הזו בוטלה באתר לגמרי...
8. האם אכן נוח למשתמש - ה-flows, מיקום הכפתורים? לשון אחר: יוזביליתי.
9. האם לא חסר משהו שהמשתמש מצפה לו, או יקל עליו. אותה משפחה כמו סעיף 7.
10. אם ברור לכם שהטכנולוגיה לא קיימת ו/או שייקח זמן רב לפתח את זה.
11. האם לא חסר מידע? האם יש קפיצות בדרישה?
12. סתירות פנימיות: פעם כתובה דרך אחת ליצירת דבר מסויים, פעם דרך אחרת וכד'.
13. מילים דו משמעיות, TBD, אחרי האישור של <> ועוד.
14. האם יש מוקאפים?
אולי ממש הגדלת ראש, אבל אם יש זמן: איך המתחרים התמודדו עם בעיות דומות? האם הם הצליחו? האם יש משהו שאפשר ללמוד ממנו?
יש עוד כמה נקודות מועילות (כמו: בדיקת מתחרים, ציפיות הלקוח, איך זה עובד עם המוצר הקיים). כיוון שאני לא רוצה להמציא את הגלגל אני שולח אתכם למאמר של מייקל בולטון על הנושא. הוא מתאר היוריסטיקות של בדיקה בפועל, אנחנו נשתמש בהן גם בשלב איסוף המידע.
קראתם? יופי, אבל יש סיכוי טוב שבזבזתם את הזמן. כמו שמייקל בולטון אמר (במקום אחר): לא כדאי להתבלבל בין הדרישות למסמכי הדרישות. דברו עם מנהל המוצר, ועם כל מי שדעתו חשובה. בקשו ישיבת הבהרה. דברו עם הלקוחות אם יש לכם אפשרות. המטרה: לראות שהמוצר כפי שנהגה ע"י "האנשים החשובים", המסמכים ואנשי הביצוע (וזה כולל אותך!) מיושרים.
אג'ייל מול waterfall: דבר אחד צריך להיות ברור: אג'ייל או waterfall, מסמכים או שיחות, אנו הבודקים חייבים להבין בצורה מלאה מה מטרת המוצר, מה הוא אמור להכיל, איך עליו להיראות, איך יפתחו אותו (לאו דווקא ברמת הקוד) ועוד. ניתן להיעזר בתרשים שנתתי על מה בודקים בכדי לוודא שאנו יודעים ככל הניתן.
שלב שני: הבנת המסמכים. ישיבת review פנימית עם ראש הצוות והצוות ובו יסביר מהנדס הבדיקות על הפיצ'ר החדש. לאחר מכן הוא ייקיים את הישיבה הזו עם הפיתוח, מנהל המוצר, מהנדס מערכת וכד'.
למרות שהמטרה הרשמית היא לראות שהפיצ'ר הובן כראוי, ברוב הישיבות שאני השתתפתי יצא שהן היו מעיין ישיבות הכנה לתחילת / המשך פיתוח, כשהתברר שמהנדס המערכת לא חשב על היבטים מסויימים, או שהפיתוח לא הבין דברים כמו שהתכוון מנהל המוצר וכו'. זו סבה נוספת לחשיבות הישיבה.
אני יודע שבודקים עלולים לחוש מאויימים משלב זה, אבל הצד השני, שהם יתחילו לבדוק לפני שהם מבינים לגנרי את הדרישות, נראה לי בעייתי יותר.
כמובן שיש לתמוך בהם בדרך, ולכן הישיבה המוקדמת עם הצוות.
שלב שלישי: כתיבת עץ הבדיקות. גם זה צריך לעבור review מול הפיתוח, לראות אם חסרים TC (תסריטי בדיקות).
שלב רביעי: כתיבת הצעדים. גם זה צריך לעבור review מול הפיתוח. כאן עשוייות שאלות כמו: איך ניתן לדמות שהקו תפוס וכו'.
Jun 28, 2015
חבל שאין יותר פירוט
השבמחקמצער אפילו
מחקזו הייתה ביקורת בונה - ולדעתי במקום.
השבמחקאנונימי אחר.
בהחלט
מחק