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.

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

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

השתמש בדיבאגרים שונים בכדי לעלות על באגים לא ויזואליים.

מהו המיקום של בדיקות האד הוק במחזור הבדיקה?

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

האם אפשר להפוך בדיקות אד הוק לאוטומאטיות?

אפשר לקרוא במאמר. בעיקרון – לא.

* עם ההסתייגויות הרגילות: זהו סיכום ולא תרגום, למטרות אישיות, ואינני אחראי למה שכל אחד יעשה איתו.

הבדיקות מול סביבות העבודה השונות: פיתוח, בדיקות ולקוח

בעיקרון יש שלש סביבות של עבודה הרלוונטיות לצוות הבדיקה:

סביבת הפיתוח;
סביבת הבדיקות (ידוע כ-staging);
סביבת לקוח (ידוע כ-production).


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

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

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

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

סביבת הבדיקותבין אם היו סבבי בדיקות בסביבת הפיתוח או בין אם לאו, יש לעבור סב מסודר של בדיקות בסביבת ה-staging. ייתכן שיהיו בעיות שכלל לא נתקלו בהן בסביבת הפיתוח ולא רק בשל הקונפיגורציה השונה. בסביבה זו מצופה רמת בשלות מצד המוצר (בין עם עזרנו לפיתוח ובין אם נתנו להם מסמך שאומר: X, Y ו-Z צריכים לעבוד אחרת אין לנו מה לעשות עם המוצר). כאן עושים סבב בעוד הפיתוח עסוק בתיקון הבאגים החדשים ושאריות של באגים קיימים אם יש. מידי פעם יש לעלות גרסה חדשה מסביבת הפיתוח לסביבת הבדיקות עם תיקונים. אם אכן המוצר בשל אין צורך בהעלאה יומית בכדי לחסוך את האריזה וה-sanity, שאותו יש לקיים על כל עלייה של build חדש.
אין חובה לבדוק את כל הבאגים שנסגרו בסביבת הפיתוח אלא את המשמעותיים. ההנחה היא שממילא תוכנית הבדיקה כוללת את כל התסריטים כולל אלו שיצרו את הבאג מלכתחילה, או שמדובר בבאג שיש רק סיכון נמוך שיחזור או שהשפעתו בטלה בשישים.
בדיקות קיט: בסוף תהליך הבדיקות יש לנקות את סביבת הבדיקות, לקחת את דיסק התקנת המוצר ולהתקין כמו כל לקוח לפי ההוראות ולוודא שה"דבר" עובד (כן, שוב sanity).

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

שיפור הבדיקות 3: סדרי עדיפויות

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

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

מה כן עושים?

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

דוגמא רק בכדי לסבר את האוזן:

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

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

מצ"ב דוגמא לקובץ אקסל המכיל טבלה של פירוק בעייה לגורמים עם דוגמא.

שיפור הבדיקות 2: ישיבת שיפורים

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

1. מהנדס מערכת (של הבדיקות או בכלל).
2. מנהל תחום הבדיקות.
3. נציגי צוותי הבדיקה (הזדמנות מצויינת לתת לבודקים מן השורה אחריות נוספת).
4. אפשר להביא "אורחים" יעודיים - אם מדובר במשהו שקשור לפיתוח אפשר לזמן נציג שלהם וכד'.

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

מנהל הישיבה:
מנהל תחום הבדיקות, אך יכול להיות גם כל אחד אחר.

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

וכעת לעיצות מעשיות יותר:

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

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

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

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

מצ"ב צ'ק ליסט לעקרונות בדיקת התקנות:
דיוק:

כמו בבכל TD - ההתקנה עובדת בהתאם לדרישות.
בהירות:

1.                  המונחים וראשי התיבות שמשתמשים בהם בתהליך ההתקנה מוסברים.

2.                  שפה ברורה ותמציתית.

3.                  הפעולות והתוצאות ברורות וחד משמעיות.

4.                  ישנן תמונות להמחשה כולל סימנים בתמונות שיבהורו בדיוק מה יש לעשות.

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

שלמות:

1.                  שום צעד אינו חסר.

2.                  הצעדים הם לפי הסדר (חשוב מאוד!)

3.                  דרישות הקדם מצויינות.

4.                  שגיאות אפשריות ופרוצדורות של recovery מצויינות במסמך.

5.                  ציון של כמה זמן אמור לקחת כל תהליך.

6.                  הסבר של שיטות ההתקנה (ידניות, הרצות של exe וכד')

קונסיסטנטיות

1.                  פנה את קהל היעד שלך כיאות (אם אלו אינם אנשים טכניים אל תצפה שיבינו מונחים כמו batch file לדוגמא).

2.                  הפעולות והתוצאות כתובות בצורה עקבית עם הפירוט המתאים, ובאותו פורמט.

3.                  התהליך והמעבר בין הנושאים הם לוגיים, אין קפיצות מנושא לנושא.

תצורה גראפית:

1.                  Toolbars , תפריטים, פקודות ואפשרויות פועלים בדיוק כמו במסמך.

2.                  ברירות המחדל במסמך וב-GUI זהות.

3.                  דוגמאות מתועדות נכון.

ארגון:

1.                  יש אזכור של מסמכים קשורים.

2.                  מטרות כל תהליך מוסברות.

3.                  יש overview של ההתקנה.

4.                  לא יותר מ-10 עד 15 צעדים בכל פרוצדורה.

5.                  הצעדים ממוספרים.

6.                  מינימום של פעולות ידניות.

7.                  יש מקום להערות וחתימה של הבודק.

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

9.                  המשך של #8: אפשר ורצוי גם לתת טיפים. את זה אפשר להשאיר ליד המקום הרלוונטי, אבל בקצרה ובפורמט וצבע שונים עם תיוג ברור.

סטייל:

1.                  נראה מקצועי.

2.                  משתמש במונחים מקצועיים.