בדיקות נסיגה

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

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

היקף הבדיקות המתבצעות במסגרת בדיקות נסיגה יכול לנוע מבדיקות יחידה המתמקדות ביחידת התוכנה בה בוצע השינוי ועד בדיקות המערכת בשלמותה.

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

הצורך בבדיקות נסיגה

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

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

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

דוגמה לבדיקות נסיגה

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

סוגי מקרי בדיקה

Regression test selection זוהי פעילות שכוללת בחירה מתוך קבוצת מבחנים קיימים, את מבחני הבדיקה הרצויים כדי לבדוק שהפונקציונליות הקיימת לא נפגעה.
בדרך כלל מחלקים את מקרה הבדיקה לפי החלוקה הבאה:

• Obsolete- מקרה בדיקה שלא ניתן להריץ על גרסה חדשה של המערכת, לא תקף בקונטקסט החדש. סיווג של מבחן ככזה, ידרוש שינוי של מקרה הבדיקה או הסרת המבחן מסט מבחני הרגרסיה.
• Retestable- בדיקות שעדיין רלוונטיות לקוד וצריך להריץ אותם מחדש כדי לוודא שהבדיקות רגרסיה תקינות.
• Reusable -בדיקות שעדיין רלוונטיות לקוד אבל אין צורך להריץ אותם מחדש בשביל בדיקת רגרסיה תקינה. לדוגמה,יכול להיות שהבדיקות כבר מכוסות על ידי בדיקות אחרות או שלא היה שינוי בקוד אותו הן בודקות.

סוגי בדיקות נסיגה

• Corrective Regression Testing-בדיקות רגרסיה שמופעלות בעקבות תיקונים שהתרחשו בגרסה קודמת. במקרה כזה ניתן לעשות שימוש מחדש לבדיקות הרגרסיה.
• Progressive Regression Testing-בדיקות רגרסיה שמופעלות בעקבות הוספת מאפיינים חדשים בגרסה קודמת. במקרה זה צריך לכתוב מבחני רגרסיה נוספים.

מתודולוגיות בחירה של מבחני נסיגה

• Test prioritization-בחירת מבחנים לפי סדר עדיפות. ניתן להריץ מבחנים שיותר חשובים או רלוונטיים קודם, מבחנים שמכסים כמה שיותר קטעי קוד,חלקים הכי שמישים בתוכנה
• The Retest-All Strategy-במקרה זו עושים שימוש מחדש לכל מבחני הרגרסיה הקודמים. הדבר יכול לגרום לבזבוז זמן ומשאבים משום שמריצים גם מבחנים לא נחוצים. טוב כאשר שינויים במערכת הם מועטים.
• The Selective Strategy-משתמשים בתת-קבוצה של מבחני רגרסיה קיימים. הרצה נקודתית של תרחישי בדיקה הקשורים ליישום שתוקן באופן ישיר. דבר זה עוזר להפחית את העלות הכספית ואת המאמץ הכרוך בהרצת סבב בדיקת מלא. הקושי הוא לזהות איזה מבחנים להריץ בגלל התלויות בין רכיבים.
  בחירת הבדיקות:
  Random- בחירה רנדומלית אחוז מסוים של מקרי בדיקה.
  Test minimization- סט מינימלי של בדיקות שיכסו את כל האלמנטים המושפעים או כל מסלולי הזרימה של המידע ובעיקר אלו שהשתנו.
  Safe- לקיחת כל המבחנים שמכסים רכיבים שהשתנו או שמושפעים מהשינויים.

יתרונות וחסרונות השימוש בבדיקות נסיגה

יתרונות:

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

חסרונות:

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

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

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

אופן הרצת בדיקות נסיגה

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

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

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

קביעת היקף הרגרסיה

תהליך קביעת היקף הרגרסיה, בהינתן תוכנה מקורית P שנבדקה על ידי קבוצת תסריטי בדיקה T, וגרסת תוכנה חדשה P', שנבדקה על ידי קבוצת תסריטי בדיקה T'

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

שיקולי בחירה ותעדוף

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

בחירה מינימאלית של סט בדיקות

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

קישורים חיצוניים

• What is Regression Testing?, באתר Exforsys (באנגלית)
• Regressions Tests, באתר Smartbear (באנגלית)
• System, Acceptance, and Regression Testing, באתר Docstoc (באנגלית)
• Regression Testing with Regression Testing Tools and methods, באתר Software Testing Help (באנגלית)