כל בודק מתחיל יודע לדקלם מה זה בדיקות רגרסיה - הבדיקות שמבצעים אחרי שינויים בקוד.
אבל למה בדיוק צריך את הבדיקות האלה ? למה לא מספיק לעשות Sanity וזהו ? אילו בדיקות נכנסות לקטגוריה הזו ואילו לא ?
על כך נדון בפוסט הנ"ל.
המונח Regression פירושו נסיגה. המשמעות היא שמדובר בטסטים שמוודאים למעשה שאין נסיגה בקוד, או לחילופין, ביציבות המוצר.
במילים פשוטות, זה אומר שמחזור בדיקות של רגרסיה למעשה מוודא שטסטים שעברו (קיבלו Passed) על גירסה קודמת עדיין עוברים על הגירסה הנוכחית.
לא. ההגדרה של Retest היא חזרה על טסטים שנכשלו. במקרה של רגרסיה, מדובר על טסטים שעברו.
הדרישה יכולה לבוא במספר מקרים. למשל, כשבודקים קוד חדש - מתגלים באגים: חלקם קריטיים יותר, חלקם פחות. הבאגים נפתחים ל-R&D ומחזור הבדיקות מסתיים. לאחר זמן מה, הבאגים מתוקנים ע"י ה-R&D לפי סדר חשיבותם ונכנסים לקוד (מתבצע commit), שזה אומר שהקוד משתנה ויש גירסה חדשה מוכנה לבדיקות.
במקרים אחרים, מדובר בקוד שעבר שינוי כיון שהתווספה פונקציונאליות חדשה למוצר או שהתבצעה אופטימיזציה כלשהי למוצר בעקבות בדיקות ביצועים שלא הניבו תוצאות כמצופה.
בשלב זה, ניתן לחלק את הגירסה החדשה לשני חלקים: החלקים שעברו שינוי והחלקים שלא עברו שינוי.
ברור שיש לבדוק את החלקים שעברו שינוי, אבל מה עם החלקים שלא עברו שינוי ? סביר להניח שאם תשאלו איש R&D ממוצע הוא יענה לכם בביטול שאין בכך צורך. אבל למעשה, קיים בהחלט צורך כיון שקיימת הסתברות לא קטנה שגם חלקים שלא עברו שינוי, הושפעו כתוצאה מהשינויים שהתבצעו במקומות אחרים בקוד ולכן עלולים להיווצר באגים חדשים גם במקומות אלו.
מדובר בבעיה שכיחה. כמעט תמיד ה-QA פועל תחת לחץ כדי לסיים ולשלוח את הדו"ח שיכריע את ההחלטות שיתקבלו מאוחר יותר בהנהלה או ע"י הלקוח בעצמו.
אפשר להתמודד עם הבעיה במספר דרכים:
א. מחליטים לא לעשות רגרסיה ולוקחים את הסיכון.
ב. עושים רגרסיה רנדומלית - מבצעים רוטציה בין חלקים שונים בקוד שלא עברו שינוי, על בסיס הגרלה.
ג. עושים רגרסיה מושכלת - מבצעים רגרסיה על חלקים עם אינטגרציה גבוהה או חלקית לחלקים שעברו שינוי.
רגרסיה מושכלת, מן הסתם, לוקחת יותר זמן לביצוע ומרווח זמן לתכנן את הרגרסיה. המפתח הוא תיעדוף הטסטים וניתן לעשות זאת במגוון דרכים.
למשל, טסטים ל-core של המוצר, טסטים שבודקים נקודות אינטגרציה חשובות או טסטים שבודקים חלקים שחשופים למשתמש סביר שידורגו בעדיפות גבוהה יותר משאר הטסטים האחרים. ההחלטה תהיה תלויה בארגון, במשאבים שלו, בקריטיות של הפרויקט ובמורכבות של המוצר.
ע"פ ההצעה הבאה, ניתן לחלק את הטסטים לשלוש עדיפויות:
Priority 0 - טסטים ברמת ה-Acceptance בעלי החשיבות הקריטית לפרוייקט ולמוצר.
Priority 1 - טסטים בסיסיים בעלי ערך גבוה המכסים את הפונקציונאליות הבסיסית של המוצר.
Priority 2 - טסטים בעלי חשיבות בינונית למוצר ולפרוייקט.
עתה, ניקח בחשבון שלשה מצבים:
1. כאשר הבאגים שתוקנו וההשפעה של השינויים הם קריטיים.
2. כאשר הבאגים וההשפעה בינוניים.
3. כאשר הבאגים וההשפעה נמוכים.
במצב הראשון - נבצע את כל הטסטים שסומנו כ-P0 ו-P1 ונבחר חלק מהטסטים מ-P2 בצורה מושכלת.
במצב השני - נבצע גם את P0 ו-P1 אך מעט מאד מ-P2.
במצב השלישי - נבצע מעט מאד מכל אחד מהקבוצות.
להלן גרף שמתאר את מה שהסברתי:
ביצוע מחזור רגרסיה של בדיקות הוא חיוני בכל ארגון המכבד את עצמו ואת המוצר שלו. השאלה היא בד"כ כיצד לבצע את הטסטים ועל שאלה זו ניסינו לענות כאן בקצרה.
גם כשאין זמן, כדאי לכל הפחות לבצע רגרסיה רנדומלית מאשר לא לבצע רגרסיה כלל.
אבל למה בדיוק צריך את הבדיקות האלה ? למה לא מספיק לעשות Sanity וזהו ? אילו בדיקות נכנסות לקטגוריה הזו ואילו לא ?
על כך נדון בפוסט הנ"ל.
מה זה ?
מהי המשמעות מבחינת הבדיקות ?
האם זה Retesting ?
אז למה צריך את זה ?
במקרים אחרים, מדובר בקוד שעבר שינוי כיון שהתווספה פונקציונאליות חדשה למוצר או שהתבצעה אופטימיזציה כלשהי למוצר בעקבות בדיקות ביצועים שלא הניבו תוצאות כמצופה.
בשלב זה, ניתן לחלק את הגירסה החדשה לשני חלקים: החלקים שעברו שינוי והחלקים שלא עברו שינוי.
ברור שיש לבדוק את החלקים שעברו שינוי, אבל מה עם החלקים שלא עברו שינוי ? סביר להניח שאם תשאלו איש R&D ממוצע הוא יענה לכם בביטול שאין בכך צורך. אבל למעשה, קיים בהחלט צורך כיון שקיימת הסתברות לא קטנה שגם חלקים שלא עברו שינוי, הושפעו כתוצאה מהשינויים שהתבצעו במקומות אחרים בקוד ולכן עלולים להיווצר באגים חדשים גם במקומות אלו.
ומה עושים כשיש המון בדיקות לבצע ויש מעט זמן ?
אפשר להתמודד עם הבעיה במספר דרכים:
א. מחליטים לא לעשות רגרסיה ולוקחים את הסיכון.
ב. עושים רגרסיה רנדומלית - מבצעים רוטציה בין חלקים שונים בקוד שלא עברו שינוי, על בסיס הגרלה.
ג. עושים רגרסיה מושכלת - מבצעים רגרסיה על חלקים עם אינטגרציה גבוהה או חלקית לחלקים שעברו שינוי.
רגרסיה מושכלת, מן הסתם, לוקחת יותר זמן לביצוע ומרווח זמן לתכנן את הרגרסיה. המפתח הוא תיעדוף הטסטים וניתן לעשות זאת במגוון דרכים.
למשל, טסטים ל-core של המוצר, טסטים שבודקים נקודות אינטגרציה חשובות או טסטים שבודקים חלקים שחשופים למשתמש סביר שידורגו בעדיפות גבוהה יותר משאר הטסטים האחרים. ההחלטה תהיה תלויה בארגון, במשאבים שלו, בקריטיות של הפרויקט ובמורכבות של המוצר.
ע"פ ההצעה הבאה, ניתן לחלק את הטסטים לשלוש עדיפויות:
Priority 0 - טסטים ברמת ה-Acceptance בעלי החשיבות הקריטית לפרוייקט ולמוצר.
Priority 1 - טסטים בסיסיים בעלי ערך גבוה המכסים את הפונקציונאליות הבסיסית של המוצר.
Priority 2 - טסטים בעלי חשיבות בינונית למוצר ולפרוייקט.
 |
| הצעה לחלוקת הטסטים לפי עדיפויות |
1. כאשר הבאגים שתוקנו וההשפעה של השינויים הם קריטיים.
2. כאשר הבאגים וההשפעה בינוניים.
3. כאשר הבאגים וההשפעה נמוכים.
במצב הראשון - נבצע את כל הטסטים שסומנו כ-P0 ו-P1 ונבחר חלק מהטסטים מ-P2 בצורה מושכלת.
במצב השני - נבצע גם את P0 ו-P1 אך מעט מאד מ-P2.
במצב השלישי - נבצע מעט מאד מכל אחד מהקבוצות.
להלן גרף שמתאר את מה שהסברתי:
לסיכום
גם כשאין זמן, כדאי לכל הפחות לבצע רגרסיה רנדומלית מאשר לא לבצע רגרסיה כלל.
אין תגובות:
הוסף רשומת תגובה