סיכום מאמר:
זהו מאמר ראשון שלי מתוך כמה שיבואו בעתיד בנושא ה-exploratory testing. המאמר שאני מסכם יכול לשמש כמבוא טוב שייתן מושג מהן בדיקות אלה. זה אינו מאמר חדש, וחסרונותיו עמו:
שימו לב שהמילה "פרוגרסיה" אינה נזכרת בשום מקום.
האם באמת "אד הוק" שווה תמיד ל"חד פעמי"?
האם באמת זה עניין לבודקים מיומנים?
איך אפשר ללמד את צוות הבדיקה לעשות את זה?
האם בכ"ז ניתן לתת guidelines לבודקים שהוא יותר מפורט ממה שרשום כאן אך עדיין פתוח דיו?
הערות נוספות בגוף המאמר. כל מה שכחול – שלי.
המאמר אינו טוען שבדיקות אלו אמורות להחליף את הרגרסיות. אשתדל בהמשך להביא דעות שונות ואז את דעתי הנובעת מניסיון.
בגדול אני חושב שכל הנושא הזה הוא נושא חשוב ומרגש ויכול למלא את ייעודו (למצוא באגים, ללמד על התוכנה, לתת סטאטוס מהיר לגבי מצב הגרסה וכד') כמו גם להביא עניין חדש לצוותי הבדיקה.
הקדמה:
נשאלת השאלה מדוע לשים דגש על הרעיון של סט בדיקות ספציפי (מהסוג של אד הוק) שבסופו-של-דבר מבוצעות רק פעם אחת. התשובה היא שזה מבדיל את בדיקות האד-הוק מבדיקות אחרות פורמאליות ששמות את הדגש על החזרה עליהן, כמו רגרסיות ו-acceptance tests. הרעיון של הערך הקיים בבדיקות אד-הוק סותר לכאורה את ההיגיון ששם דגש על חזרה ובדיקות אוטומאטיות. רוב התעשייה מעדיפה את החזרה על בדיקות מאשר יצירת בדיקות חדשות. נשאלת השאלה מדוע להריץ שוב ושוב בדיקות ישנות כשיש לנו האפשרות להריץ בדיקות חדשות שלא הורצו מעולם?
למען ההגינות יש לציין שזה תלוי הקשר: במערכות שתלויים בהן חיי אדם יש לשים דגש חזק על בדיקות רגרסיה. מעבר לזאת אנחנו נרוויח אם נמצא שילוב מנצח של בדיקות חד-פעמיות ורגרסיות. נחזור לזה, אך כעת נראה מה נאמר כבר על הנושא.
בעצם ה-exploratory testing צמחו מבדיקות האד-הוק ואוזכרו לראשונה בשנת 1988 על-ידי קאנר (ניתן לראות מקור במאמר עצמו). שם נאמר שבזמנים "מתים" אפשר ורצוי להמשיך בבדיקות, מבלי לבזבז זמן על הכנתן או הסברתן. כל מה שצריך זה לסמוך כל האינסטינקטים שלכם.
שזירה של תכנון וביצוע בדיקות בניגוד לתכנון קודם, ביצוע אח"כ.
הרעיון שבודקי התוכנה לומדים עליה בזמן הבדיקות.
דגש על יצירתיות וספונטאניות.
ציפייה לעתים שה-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.
בודק אד הוק טוב צריך להבין את המטרות והדרישות של הדיזיין לפונקציות אלה. אילו בחירות עשה צוות הפיתוח ומה החסרונות שלהן? –כבודקים אנו פחות מודאגים מהבחירות הנכונות של הפיתוח. בדיקות האד הוק יכולות להיות בדיקות קופסה שחורה. אבל זה אומר שעלייך לבדוק את כל תבניות הדיזין בהן השתמשו. עבודה עם הפיתוח בכדי להבין את הבחירות שלהם מביא אותך קרוב יותר לבדיקות קופסא לבנה. זה עוזר לך בצמצום הבדיקות.
קרא את דיווחי הבאגים גם מפרויקטים אחרים. זה אולי יעלה לך רעיונות חדשים לבדיקה.
השתמש בדיבאגרים שונים בכדי לעלות על באגים לא ויזואליים.
מהו המיקום של בדיקות האד הוק במחזור הבדיקה?
לכל האורך. בתחילת הפרויקט זה נותן לבודק הבנה על המוצר (זה בדיוק פרוגרסיה), באמצע הפרויקט זה עוזר לעשות פריוריטיזציה נכונה ולוחות זמנים. קרוב לסוף הפרויקט זה עוזר לבדיקות עמוקות יותר של תיקוני באגים.
האם אפשר להפוך בדיקות אד הוק לאוטומאטיות?
אפשר לקרוא במאמר. בעיקרון – לא.
* עם ההסתייגויות הרגילות: זהו סיכום ולא תרגום, למטרות אישיות, ואינני אחראי למה שכל אחד יעשה איתו.
