בדיקות נסיגה

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

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

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

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

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

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

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

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

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