תמיד יש סבבי תיקונים - אז למה לא נערכים לכך מלכתחילה?
זה קצת מצחיק - או אולי עצוב, אך למרות שהדבר ידוע מראש - במרבית הארגונים לא עושים דבר בכדי להתמודד עם התופעה.
תמיד יש סבבי תיקונים - אז למה לא נערכים לכך מלכתחילה?
האם בכלל הגיוני לתכנן זמן בדיקות לכיסוי מלא של תכונה?
הרי רוב הסיכויים שלא באמת נעבוד כך - כי כפי שציינת יש לא מעט סיבות להיכנס ולצאת מהבדיקות בהמתנה לתיקונים, +++ ומה הבודק/ת עושה בזמן הזה אם לא תכננו אותו מראש????
אז עכשיו מתחילים לאלתר מה עושים ב"חורים"?
בזמנו בשילוב של שיטות עבודה בתדיראן וב-ECI הגדרנו תהליך שקראנו לו ABCD Approach -
בשלב A - מלכתחילה מתכננים רק >> דגימה << רוחבית של התכונה
(שימי לב כי אם לא נארגן הבדיקות כראוי - מרבית הבודקים יתייחסו לתכנית הבדיקות כמו לספר - יתחילו בעמוד מס 1 ואולי אף פעם לא יגיעו לבדוק את מה שמופיע בעמוד 100 כי ייתקעו באמצע - ומי אומר שבדף #1 יש את הדברים החשובים ביותר?
האם לא עדיף להחזיר לתכנתים משוב רוחבי ככל הניתן כל עוד הם זוכרים מה כתבו?)
בשלב B שמבוצע מייד בצמוד ל- A, מנסים לבחון אספקטים לא פונקציונאליים של המערכת כבר בשלב מוקדם (עד כמה שניתן בהתאם ליציבותה - מעט עומס, אינטגרציה עם חלקים אחרים... - לרוב אלו הבאגים שבדרך הרגילה נמצאים מאוחר מידיי ותוקעים את שיחרור הגירסה)
#### בנקודה הזו מתכננים מראש שהבודק/ת עובר לתכונה הבאה בזמן שהתכנתים חוזרים לתקן את זו (אין מה להמתין באבטלה סמויה) - אז עושים A+B לתכונה או שתיים נוספות - כן קצת דורש שינוי קונטקסט מהיר - אבל עדיין יותר יעיל.
שלב C מתחיל לאחר שהתכנתים כבר תיקנו את מרבית הבאגים - עכשיו התכונה מוכנה כבר יחסית ובצורה רוחבית לסבב בדיקות "מלא" בו נרחיב את כל הבדיקות על הנושאים שקודם רק דגמנו - ההנחה היא שעכשיו הבדיקות ילכו קל יותר ללא באגים שעוצרים חלקים נרחבים מהבדיקות.
שלב D הוא הרגרסייה - שאותה נתאם לנקודה המתאימה בזמן ורק לתכונות שאחריהן נעשו הרבה שינויים בתכונות אחרות.
בכדי לתמוך בשיטה זו - מסמכי הבדיקות צריכים להכתב מראש בראש זה - ולהגדיר אילו בדיקות ואילו ערכים מייצגים לכל מקרה יהיו חלק מ-A (שלרוב גם דיי דומה לתכולת - D)
זה אומר שהרווחנו גם מחשבה מראש של הבודקים על סיכונים וקדימויות.
אם תסתכלו על התמונה המצורפת תראו שכעת לא רק שחסכנו בזמני ביצוע לא יעילים וזמני המתנה - בכל נקודת זמן אנו גם יודעים יותר על התכונה הנבדקת והמוצר ככלל מאשר בצורת העבודה הרגילה....
ייעלנו את המשוב לתכנתים, והוצאנו אותם פחות מנושאי העבודה הבאים שלהם - כלומר צימצמנו גם להם את מה שנקרא "Bad Multitasking"
עכשיו יקפוץ עמית ויגיד שזה מתאים רק לתכנון בדיקות מקיף... ווטרפולי וכלל לא אג'ילי - אז לא!! - בדיוק באותה מידה ניתן לתכנן לבדיקות הכתובות בראשי פרקים בלבד, ולשנות ולהתאים ע"פ הצורך בזמן הכניסה לבדיקה.
המעברים בין השלבים הינם תזכורת מצויינת לנקודות בהן רצוי להסתנכרן שוב מול התכנתים, להבין מה השתנה, מה תוקן בינתיים, להכניס רעיונות בדיקה חדשים ולסדר מחדש את סדר הבדיקות אם נדרש פה ושם.
) זמן בדיקות, לצורך העניין של פיטשר חדש, כאשר בהערכה ריאלית יש לקחת בחשבון בנוסף לזמן איתור הבאגים גם את זמן תיקונם. הרי אינני יודעת מראש לצפות אילו באגים אמצע, כמה זמן יקח למפתח להתפנות לטפל בהם, כמה זמן יקח לו למצוא פיתרון וליישם אותו, כמה זמן יעבור עד שאקבל בילד חדש, בקיצור - כל התהליך. נוסף לכך כמובן שכל השרשרת חוזרת על עצמה כמה וכמה פעמים, בהתאם לכמות הבאים. אם כן, איך מעריכים זמן ריאלי ומתמודדים עם השאלה מתי נסיים לבדוק את המודול עד למצב שהוא מוכן ל deployment. תודה
